Add module-info.java #2970

hrchu · 2017-10-18T07:52:24Z

So that projects depend on this can be published to a public artifact repository.
Note that this is not breaking backward compatibility. All codes except this file can be still compiled in Java 6.

jbduncan · 2017-10-18T08:36:22Z

Guava has an Automatic-Module-Name in its MANIFEST.MF now, so I believe this is not quite as important as it may seem. But if I'm mistaken, then I'd be more than happy to be proven wrong.

(BTW, I think I might have misunderstood something, because module-info.java is Java 9 specific, right? Would a Java 8 compiler (which I believe is what is used to compile guava-jre) or an Android compiler (for guava-android) happily process it or otherwise ignore it?)

cpovirk · 2017-10-18T11:50:28Z

Our current thinking is that we'll look into this next quarter. We have seen some problems from module-info files in third-party jars, since they're Java 9 .class files and not everyone uses Java 9 yet. So, if we can get away with Automatic-Module-Name, we'll continue to do so, possibly even beyond next quarter. But if there are cases in which Automatic-Module-Name isn't good enough, that would be good to know.

hrchu · 2017-10-18T12:21:44Z

It is possible to only compile modile-info.java in Java 9, so the jar file is still compatible to users who uses earlier Java version.

A maven example:
https://github.com/twonote/radosgw-admin4j/blob/java9/pom.xml#L127

cpovirk · 2017-10-18T14:54:05Z

Right, thanks. We've seen problems even when the main .class files are compiled for an older version but the module-info.class is present. As I understand it, various tools try to process all .class files, and they need to be updated to ignore module-info.class.

hrchu · 2017-10-19T01:56:14Z

@cpovirk could you tell me more about this problem?

cpovirk · 2017-10-19T11:16:24Z

I wasn't personally involved in fixing the problems, but the basic idea seems to be that people scan the whole classpath (using something like ClassPath.getTopLevelClasses -- which might be an example of something that needs updated to ignore module-info.class :)) and then try to examine/load the classes with a tool that understands only, say, Java 8.

orionll · 2018-02-20T05:17:21Z

It's worth mentioning that if we add module-info.java, all packages will not be open anymore.

jbduncan · 2018-02-20T15:30:41Z

@orionll Am I right to think/remember that in the JPMS, open packages are packages whose internal classes can be inspected with reflection?

orionll · 2018-02-20T16:29:38Z

@jbduncat Yes, exactly. And also private members of public classes.

jbduncan · 2018-02-20T16:37:27Z

@orionll Cool, thanks for confirming things for me. :)

I personally wonder how important it would be for Guava's packages to be open when used on the module path. I struggle to imagine that reflectively calling Guava's internals is a common thing to do, especially considering Guava's (IMO) pretty durn good API. 🤔

HoldYourWaffle · 2018-02-20T16:38:55Z

Are there any reasons for it not being open? Even if it's uncommon it might still be done by some people.

jbduncan · 2018-02-20T16:44:47Z

@HoldYourWaffle I think the main reason is it prevents people from using reflection to depend on internals which may change or disappear in future releases of Guava without warning.

jbduncan · 2018-02-20T16:45:27Z

...which by my understanding makes things easier for everyone in the long-run.

jbduncan · 2018-02-20T16:47:55Z

The only reason I can currently think of to have Guava's packages open in the module-info.java is if frameworks like Spring need to reflectively access its internals to do important stuff, but I don't know how important or common that is.

orionll · 2018-02-20T16:59:37Z

All Guava packages should be closed because as @jbduncan said the dependence on class internals is a bad practice. If someone really wants to access the internals, they can use --add-opens command line option which forces the specified package to be open.

HoldYourWaffle · 2018-02-20T17:06:40Z

Good point I forgot about --add-opens. Imho you should always be able to hack into internals (maybe you want to do something the developers didn't think of but it's too 'personal' that it's not worthy of a PR), with the risk of it breaking in new versions. --add-opens allows for this so it'd indeed be better to close the guava packages.

SamCarlberg · 2018-08-17T21:56:15Z

Guava has an Automatic-Module-Name in its MANIFEST.MF now, so I believe this is not quite as important as it may seem. But if I'm mistaken, then I'd be more than happy to be proven wrong.

It does mean that jlink will not work, since the tool requires a module name to be specified in the module-info.java file; automatic module names will not be accepted.

hannes-transentials · 2018-12-09T11:23:28Z

As much as I love Guava and appreciate Google's efforts, it is somehow embarrassing that a company like Google is not able to adopt Java modules within one year.

Either Google does not use Guava internally or they keep using JDK 8 and won't adopt Jigsaw.

jbduncan · 2018-12-09T12:05:26Z

@hannes-transentials I think it's most likely that Google have not migrated to JDK 11 and adopted modules yet simply because their internal codebase is so mind-bogglingly humongous. ;)

I say this because I remember reading somewhere (or I inferred) that they use Guava or an superset internally, and I also remember they announced a few years ago that they'd finally migrated to JDK 8 after a lot of effort. So I'm sure that they'll announce support for JDK 11 or a later LTS version (and, by extension, modules) when they fully migrate away from Java 8 and when they feel that most of us non-Googlers have moved away from Java 8 too. (I know that my company hasn't done so yet simply because Java 9 was such a freaking big, backwards-incompatible change!)

orionll · 2018-12-09T12:13:04Z

It's worth mentioning that adding module-info.java can break some existing tools. For example, I know that IDEA's Osmorc plugin does not work when both module-info.java exists and the library is an OSGi bundle (Guava is). So, while the tools are not ready yet, I would abstain from adding module-info.java to Guava.

hannes-transentials · 2018-12-09T14:02:52Z

So I either do without modularized applications or stay away from Guava (and many other popular applications)? I somehow hoped that there was some middle ground.

jbduncan · 2018-12-09T14:24:16Z

Well... you can use Guava as a module in a vanilla-Java modular application. But since Guava only includes an Automatic-Module-Name in its manifest, rather than going further and including amodule.info (out of necessity to stay Java-8-compatible), you won't be able to use it with jlink to create minimised modular Java applications.

Furthermore, frameworks built on top of Java that have their own programming models, like Spring, may have not fully migrated to be Java-11-compatible yet, so if you use such frameworks a lot, you may have to wait a bit longer.

That being said, if you do use a framework such a Spring, please check for yourself if Java 11 and modules work with it, since my knowledge of Spring and other frameworks is limited. :)

overheadhunter · 2018-12-10T15:27:23Z

out of necessity to stay Java-8-compatible

Well you can create multi-release jars, where the module-info.class file only gets included inside META-INF/versions/9 and is therefore invisible for old¹ class loaders.

¹ As long as no fancy custom class loaders eagerly load everything they find in a jar without reading the manifest entries.

talios · 2018-12-11T02:59:18Z

@hannes-transentials You could make use of something like https://github.com/moditect/moditect to adapt guava and add a module-info.java/.class at your applications side of things as a transitionary work around.

If module-info.java was to be added to guava, hopefully it'd be done so as a modular jar so we don't break java 8< versions.

This changeset adds full support for modular Java builds in Guava, and in libraries which depend on Guava. The Guava JAR for JRE now structures as a Multi-Release JAR, with a module definition situated in `META-INF/versions/9/`. Guava remains compatible with JDK 8. - feat: add `module-info.java` to `guava` module - chore: update `guava` to build MRJAR - chore: adjust dev version → `1.0-HEAD-[jre|android]-SNAPSHOT` - chore: upgrade maven compiler plugin → `3.12.1` Fixes and closes google#2970 Relates-To: elide-dev/jpms#1 Signed-off-by: Sam Gammon <[email protected]>

ben-manes · 2024-03-12T02:07:43Z

There are probably PRs that we could accept, and I'd probably be willing to mess around to make sure that any patches work ... internally. But this is another case in which I don't want to give people the green light and then discover (only after people have done the work) that the changes are more disruptive than I'd expected.

@sgammon Please be aware of this comment and Guava's general stance on contributions. A lot of necessary work, but also racing well ahead of the maintainers and their priorities. It is often best to think of Google OSS as shared with the community, rather than driven by it, so as to realize it closely follows Google's internal needs rather than external ones. Your PRs are interesting and good work, but also quite large with Caliper to JMH migration, Java clean up, and lots of CI & build additions. Yet, most Googlers are only intimately familiar with Google's internal stack (Bazel, TAP) which also builds Guava for its usage. Therefore much of your work has to replicated into their internal stack and given a lack of a Google champion, that seems like a high bar.

I really like your ideas and direction but as a former Googler its hard for me to get bug fixes in from the outside. I'd recommend after proving it all out to split your work down into into small PRs with clear objectives, which could then be phased in incrementally as the Guava team has time. And certainly don't get demotivated by what I say, just be realistic that your work might be a PoC that guides them to support once that becomes a necessity.

sgammon · 2024-03-12T03:12:55Z

Hey @ben-manes,

Firstly, big fan of your work... Gradle Versions, Caffeine, so many libraries. I built an entire company (partly) on Caffeine. Shameless plug for Buildless, which soon will be fully free forever for open source.

I hope you will allow me to respond out-of-order here.

Your PRs are interesting and good work [...] I really like your ideas and direction

Want to say ahead of the rest of this that I will frame this in my mind. You're a giant and that's very kind. Thank you!

It is often best to think of Google OSS as shared with the community, rather than driven by it, so as to realize it closely follows Google's internal needs rather than external ones

You could not be more correct and that is a very healthy way to think about it.

Please be aware of this comment and Guava's general stance on contributions. A lot of necessary work, but also racing well ahead of the maintainers and their priorities

I am aware, and I know that JPMS is arguably a new feature, even though it maybe shouldn't be considered as such. I could argue that we're not that ahead of the maintainers here, given that the Guava team has had this under consideration for some time (speaking about just JPMS here for a moment). Your point stands, though, regardless of those arguments, that JPMS is not a priority inside Google, at least for OSS, and @cpovirk has been clear and honest about that, to his great credit.

Luckily, I've contributed to libraries at Google before (though nothing as widely used as Guava), so this is not a surprise at all and I totally understand that Googlers straddle several (sometimes diverging) priorities. The first few of these PRs are already merged on Error Prone, J2ObJC, and on Guava.

but also quite large with Caliper to JMH migration, Java clean up, and lots of CI & build additions

This was and remains my fear as well, and so I have split off the JDK 21 and CI stuff entirely. Each stands on its own, and the CI stuff is entirely optional. If the Guava team chooses not to merge these, no worries, we can rebase the JPMS pull cleanly and move on.

That said, I think you're right about Caliper vs. JMH. During that work I actually did figure out that the benchmarks were running from Maven, though probably not... reporting anywhere or doing anything. In any case, they should probably be left alone so that internal Google tooling stays working. At the very least this should be another split point in the PR.

The bench changes, thankfully, were made very late in the PR and stand alone, so those can be split away cleanly.

And certainly don't get demotivated by what I say, just be realistic that your work might be a PoC that guides them to support once that becomes a necessity

This is excellent feedback and I deeply appreciate you taking the time to share it. I don't find it demotivating at all. In fact, I am only further motivated because the feedback that has poured in so far has been great, including yours. Some of it positive, some of it not, but all really really useful and helpful and engaged.

I am consuming these artifacts myself for my own projects from the JPMS attic repo, and they are working fine after a few tweaks, so my code is not blocked by this, and others have an option to try it out early, too. I think, all of the above considered, the Guava project can take their time and we (the group of people who care about this, in this issue) can test, refine, and eventually get a very clear plan going that minimizes breakage downstream.

Anyway, thank you for sharing your thoughts. Honesty is an expensive gift.

jbduncan · 2024-03-12T09:58:16Z

@sgammon I'm in awe of your realistic and professional yet persistent approach to getting JPMS support and a better CI setup into Guava, as I'm acutely aware how Guava is more of a "throw over the fence" project than a community project, so well done and I wish you all the best moving things forward! 👍

sgammon · 2024-03-12T20:22:22Z

@jbduncan Thank you! That's very kind of you, but I'm standing on the shoulders of giants here. This issue was filed nearly 10 years ago. We should make custom jackets.

Update: Taking orders

Front	Back

bowbahdoe · 2024-03-13T00:05:21Z

@sgammon I'll take one, but maybe just GUAVA 2970 on the front. I don't actually want anyone to ask me questions

This changeset adds full support for modular Java builds in Guava, and in libraries which depend on Guava. The Guava JAR for JRE now structures as a Multi-Release JAR, with a module definition situated in `META-INF/versions/9/`. Guava remains compatible with JDK 8. - feat: add `module-info.java` to `guava` module - chore: update `guava` to build MRJAR - chore: adjust dev version → `1.0-HEAD-[jre|android]-SNAPSHOT` - chore: upgrade maven compiler plugin → `3.12.1` Fixes and closes google#2970 Relates-To: elide-dev/jpms#1 Signed-off-by: Sam Gammon <[email protected]>

cpovirk · 2024-07-26T20:15:23Z

The toolchain setup of #7333 may lay the groundwork for continuing to run tests under JDK 8 even after we requires JDK 9 to build (at least if you want module-info). It may well be duplicative of existing work in #7094, which I still need to get back to :(

sgammon · 2024-07-26T20:20:08Z

@cpovirk Thank you for the ping; no worries, I'm happy to rebase or construct it again from scratch if needed.

…ault` annotations. This is the first step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). At the end of that path, we'll be able to [remove our dependency on JSR-305](#2960) (and on the Checker Framework's annotations), and we'll have one less blocker to [providing a `module-info`](#2970). `@NullMarked` allows tools like kotlinc to produce errors for code like `ImmutableList<String?>`. (Before releasing this change, I'll conduct some further testing to more fully characterize the effects, both under Kotlin 2.1 and prior.) As we make further changes, it will allow kotlinc to detect even more nullness problems. We will make these changes in a series of incremental releases so that users can pick them up gradually, as we did inside Google. In simple cases, users may wish to pick up all the changes at once instead by upgrading straight from Guava 33.4.0 (or an earlier version) to Guava 33.4.4 (or whatever the version to make the final changes ends up being). RELNOTES=Replaced our custom `@ElementTypesAreNonnullByDefault` annotations with the JSpecify `@NullMarked` annotation. PiperOrigin-RevId: 707134516

…ault` annotations. This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). At the end of that path, we'll be able to [remove our dependency on JSR-305](#2960) (and on the Checker Framework's annotations), and we'll have one less blocker to [providing a `module-info`](#2970). `@NullMarked` allows tools like kotlinc to produce errors for code like `ImmutableList<String?>`. (Before releasing this change, I'll conduct some further testing to more fully characterize the effects, both under Kotlin 2.1 and prior.) As we make further changes, it will allow kotlinc to detect even more nullness problems. We will make these changes in a series of incremental releases so that users can pick them up gradually, as we did inside Google. In simple cases, users may wish to pick up all the changes at once instead by upgrading straight from Guava 33.4.0 (or an earlier version) to Guava 33.4.4 (or whatever the version to make the final changes ends up being). RELNOTES=Replaced our custom `@ElementTypesAreNonnullByDefault` annotations with the JSpecify `@NullMarked` annotation. PiperOrigin-RevId: 707134516

…ault` annotations. This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). At the end of that path, we'll be able to [remove our dependency on JSR-305](#2960) (and on the Checker Framework's annotations), and we'll have one less blocker to [providing a `module-info`](#2970). `@NullMarked` allows tools like kotlinc to produce errors for code like `ImmutableList<String?>`. (Before releasing this change, I'll conduct some further testing to more fully characterize the effects, both under Kotlin 2.1 and prior.) As we make further changes, it will allow kotlinc to detect even more nullness problems. We will make these changes in a series of incremental releases so that users can pick them up gradually, as we did inside Google. In simple cases, users may wish to pick up all the changes at once instead by upgrading straight from Guava 33.4.0 (or an earlier version) to Guava 33.4.4 (or whatever the version to make the final changes ends up being). RELNOTES=Replaced our custom `@ElementTypesAreNonnullByDefault` annotations with the JSpecify `@NullMarked` annotation. PiperOrigin-RevId: 708598410

cpovirk added P2 package=general status=research labels Oct 18, 2017

robinst mentioned this issue Mar 26, 2018

Add jlink-compatible Java9/Jigsaw module-info (not automatic modules) commonmark/commonmark-java#125

Closed

FibreFoX mentioned this issue Jun 25, 2018

Plugin-configuration when using JPMS / JDK9+ javafx-maven-plugin/javafx-maven-plugin#346

Closed

tlinkowski mentioned this issue Mar 21, 2019

Feature request: Separate compilation of module-info.java java9-modularity/gradle-modules-plugin#72

Closed

sgammon mentioned this issue Mar 12, 2024

Upstream: Build Upgrades apple/pkl#204

Closed

This was referenced Mar 13, 2024

Add a module-info.java protocolbuffers/protobuf#16133

Closed

Modular Java protocolbuffers/protobuf#16178

Closed

cpovirk mentioned this issue Mar 28, 2024

Is com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava really necessary? #7129

Closed

3 tasks

sgammon mentioned this issue Apr 15, 2024

Modular Java protocolbuffers/protobuf#16502

Open

cpovirk mentioned this issue May 24, 2024

class file for com.google.errorprone.annotations.CompatibleWith not found #7233

Closed

1 task

cpovirk mentioned this issue Jul 2, 2024

Adoption of JSpecify annotations in Guava jspecify/jspecify#239

Open

msgilligan mentioned this issue Aug 29, 2024

Java Module compatible dependencies for bitcoinj-core bitcoinj/bitcoinj#3461

Open

copybara-service bot mentioned this issue Dec 18, 2024

Use @NullMarked instead of our custom @ElementTypesAreNonnullByDefault annotations. #7556

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add module-info.java #2970

Add module-info.java #2970

hrchu commented Oct 18, 2017

jbduncan commented Oct 18, 2017 •

edited

Loading

cpovirk commented Oct 18, 2017

hrchu commented Oct 18, 2017 •

edited

Loading

cpovirk commented Oct 18, 2017

hrchu commented Oct 19, 2017

cpovirk commented Oct 19, 2017

orionll commented Feb 20, 2018

jbduncan commented Feb 20, 2018

orionll commented Feb 20, 2018

jbduncan commented Feb 20, 2018

HoldYourWaffle commented Feb 20, 2018

jbduncan commented Feb 20, 2018

jbduncan commented Feb 20, 2018

jbduncan commented Feb 20, 2018

orionll commented Feb 20, 2018

HoldYourWaffle commented Feb 20, 2018

SamCarlberg commented Aug 17, 2018

hannes-transentials commented Dec 9, 2018

jbduncan commented Dec 9, 2018

orionll commented Dec 9, 2018

hannes-transentials commented Dec 9, 2018

jbduncan commented Dec 9, 2018 •

edited

Loading

overheadhunter commented Dec 10, 2018

talios commented Dec 11, 2018

ben-manes commented Mar 12, 2024

sgammon commented Mar 12, 2024 •

edited

Loading

jbduncan commented Mar 12, 2024

sgammon commented Mar 12, 2024 •

edited

Loading

bowbahdoe commented Mar 13, 2024

cpovirk commented Jul 26, 2024

sgammon commented Jul 26, 2024

Add module-info.java #2970

Add module-info.java #2970

Comments

hrchu commented Oct 18, 2017

jbduncan commented Oct 18, 2017 • edited Loading

cpovirk commented Oct 18, 2017

hrchu commented Oct 18, 2017 • edited Loading

cpovirk commented Oct 18, 2017

hrchu commented Oct 19, 2017

cpovirk commented Oct 19, 2017

orionll commented Feb 20, 2018

jbduncan commented Feb 20, 2018

orionll commented Feb 20, 2018

jbduncan commented Feb 20, 2018

HoldYourWaffle commented Feb 20, 2018

jbduncan commented Feb 20, 2018

jbduncan commented Feb 20, 2018

jbduncan commented Feb 20, 2018

orionll commented Feb 20, 2018

HoldYourWaffle commented Feb 20, 2018

SamCarlberg commented Aug 17, 2018

hannes-transentials commented Dec 9, 2018

jbduncan commented Dec 9, 2018

orionll commented Dec 9, 2018

hannes-transentials commented Dec 9, 2018

jbduncan commented Dec 9, 2018 • edited Loading

overheadhunter commented Dec 10, 2018

talios commented Dec 11, 2018

ben-manes commented Mar 12, 2024

sgammon commented Mar 12, 2024 • edited Loading

jbduncan commented Mar 12, 2024

sgammon commented Mar 12, 2024 • edited Loading

bowbahdoe commented Mar 13, 2024

cpovirk commented Jul 26, 2024

sgammon commented Jul 26, 2024

jbduncan commented Oct 18, 2017 •

edited

Loading

hrchu commented Oct 18, 2017 •

edited

Loading

jbduncan commented Dec 9, 2018 •

edited

Loading

sgammon commented Mar 12, 2024 •

edited

Loading

sgammon commented Mar 12, 2024 •

edited

Loading