[FEATURE] Make Lombok compatible with JDK 16

ilgrosso commented 3 years ago

After JDK 16 has started the rampdown phase, we could not get Lombok working any more.

The exception reported by Maven compiler is:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project syncope-wa-starter: Fatal error compiling: java.lang.IllegalAccessError: 
class lombok.javac.apt.LombokProcessor (in unnamed module @0x3af91e7e) cannot access class
com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler
does not export com.sun.tools.javac.processing to unnamed module @0x3af91e7e -> [Help 1]

No issues with earlier JDK 16 releases.

Rawi01 commented 3 years ago

I think the reason why it doesn't work anymore is that they added JEP 396. Adding --illegal-access=permit should fix the problem.

randakar commented 3 years ago

We're going to need a better fix for the long term though. They are removing the option to access these classes for a reason, and at some point it may stop working entirely.

On Tue, Dec 15, 2020, 16:36 Rawi01 notifications@github.com wrote:

I think the reason why it doesn't work anymore is that they added JEP 396 https://openjdk.java.net/jeps/396. Adding --illegal-access=permit should fix the problem.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rzwitserloot/lombok/issues/2681#issuecomment-745371095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABIERMCDDFPWDOHLDIEGL3SU567BANCNFSM4U4HKVVQ .

rspilker commented 3 years ago

We probably need to document all the add-opens the users need to add.

https://github.com/rzwitserloot/lombok/blob/f17dd036384242971546bc443749ad527b8cd21c/docker/ant/files/jdk-13/classpath/build.xml#L13-L23

JornVernee commented 3 years ago

For anyone using Maven, I was able to make it work with the following compiler plugin configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
        <source>16</source>
        <target>16</target>
        <fork>true</fork>
        <compilerArgs>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED</arg>
        </compilerArgs>
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>1.18.16</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

Note that <fork>true</fork> is needed, otherwise Maven seems to (silently) ignore the -J options when invoking the compiler. Looks like jdk.compiler/com.sun.tools.javac.jvm also needs to be exported on top of what @rspilker linked.

rzwitserloot commented 3 years ago

Reproduced with jdk16ea on x64 mac.

rzwitserloot commented 3 years ago

We've found a solution that does not require all million users to add all these add-opens to their build scripts. We'll release it in time for the OpenJDK 16 release (In March 2021).

namannigam commented 3 years ago

@rzwitserloot that's good news. just curious though, if there is an open pull request for these changes?

rspilker commented 3 years ago

@namannigam No, there isn't. We'll explain the reasons in this issue once jdk16 has been officially released. Please don't speculate.

pruidong commented 3 years ago

Is there a solution to this problem?

I have a maven project on IntelliJ IDEA that needs to be run through tomcat. But when I run it, a similar error is prompted:

java: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0xddf172a) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0xddf172a

The environment I use:

Java JDK 16
IntelliJ IDEA 2020.3.2
Apache Maven 3.6.3
Lombok 1.18.19

thanks.

namannigam commented 3 years ago

@pruidong the temporary solution is mentioned under https://github.com/rzwitserloot/lombok/issues/2681#issuecomment-748616687

pruidong commented 3 years ago

@namannigam thanks.

I found a better way to add to the Windows system environment variables:

Name:

_JAVA_OPTIONS

value:

--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add- opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk. compiler/com.sun.tools.javac.model=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com. sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools. javac.util=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

drmaniac commented 3 years ago

We've found a solution that does not require all million users to add all these add-opens to their build scripts. We'll release it in time for the OpenJDK 16 release (In March 2021).

I'm very excited to see what this solution looks like. I wonder why this is why such a secret is made.

rzwitserloot commented 3 years ago

@pruidong Our fix for jdk16 should also take care of that.

We held it back just in case us publishing this causes a chain of events that ends up removing this convenient workaround from the GA of JDK16. Given that GA is in about 10 days, I think we're good to go and will soon commit our patch to master publicly.

pron commented 3 years ago

As an OpenJDK developer, let me explain that we’ve intentionally decided (after a lot of debate) to leave some well-known loopholes in to give libraries more time to gradually prepare for the new reality, and explain it, and why it is absolutely essential, to their users. Those loopholes are scheduled for gradual removal, one at a time, starting with JDK 17, as 16 already has the first step of encapsulation. Publishing exploits won’t make them stay or be removed any sooner or later; their removal will not be hastened or postponed. They are being removed according to schedule, and there will be a few months’ notice before each. I would recommended library authors use that time to prepare themselves and their users for this better but different environment.

In a few words, the strategy is this: use of JDK internals by libraries is tolerated as long as they notify the user that they’re doing so with add-opens. This is because such libraries become tied to JDK versions, and so must be vigilant when updating, and their users need to be aware of maintenance issues libraries might impose on them (there are also security issues when it comes to libraries that do this at runtime). So, you can do what you like, but if you impose a potential maintenance burden on your users, you must let them know about it. When all loopholes are closed, libraries will need to decide whether to not use internals or acclimate their users to add-opens. In some months there will be no way — using Unsafe, attach, native code etc. — to hack JDK internals without express approval of the application.

Of course, this is not an issue for applications, that should embed their own runtime and launcher with whatever flags they like (or, when it comes to build time tools, you can create a Maven plugin that does that). The point is that introducing maintenance (and/or security) burden will not be possible without the user knowing about it and taking some action to explicitly allow it — by using a specific executable, a specific plugin, or adding flags. When users understand that this is necessary, they tend to be very accommodating.

rzwitserloot commented 3 years ago

there are also security issues when it comes to libraries that do this at runtime

@Pron This keeps being said. It doesn't make any sense. I've asked for clarification before, but never got an answer, so let me take this opportunity to ask again: What are you on about? How does mandatory --add-opens address security concerns?

It makes sense to deny plugins (a.k.a. code you might not fully trust) the ability to just call and interact with private API. However, this add-opens restriction does not accomplish that goal: If there is no security manager, then the code you don't trust can call private API (as long as they do so in opened packages). They can also invoke C:\windows\format.exe and wipe out a user's home dir while they are at it. It makes no sense to me to make any claims about 'this is more secure in environments where no security manager is set'. That's like installing a vault in the middle of an area fenced off by velvet ropes and saying: There! Now nobody can enter! Whilst everybody just hops over the rope.

Clearly you must be talking about some other sense of 'more secure', but I'm not sure what, precisely, you mean.

as long as they notify the user that they’re doing so with add-opens.

This just isn't workable advice.

Until very recently, this was impossible on maven, because command line args to the VM were stored by maven in a hashmap, thus preventing the ability of using the same argument more than once, and --add-opens needs to be applied more than once.
The amount of --add-opens that is required here is enormous, the syntax is unwieldy and just looking at the full list of command line args required is unlikely to really make anything particularly clear to your casual java user. They have no idea what they are looking at - just 'uh, this site told me to copy/paste this gigantic batch of stuff into my script. No idea why or what it does, but, CMD+C CMD+V I guess'.

When suggesting new language features, generally the inclination of the JEP process is to do some research: What is the impact of this change? This impact analysis should presumably take into account how common various libraries are (in other words, the 'assert' debacle where 1.4 added assert as a keyword should never have happened, given that junit was, at the time, the single most commonly used library in the entire eco-system, and 1.4 broke it by introducing a backwards incompatible change: That was a mistake, and lessons were learned).

But evidently that yardstick is not being applied here. I'd love to see the OpenJDK team take a closer look at this suggested upgrade path, using similar ideas as what is often requested for language changes: Instead of thumping specs, consider actual impact.

Note that, even today, java8 is vastly more popular than java11. I'm pretty sure the attitude of the OpenJDK team in regards to the detrimental impact that the jigsaw project has had on compatibility between java8 and java11 is the primary cause of this.

In light of all these things, I implore you, take this to the OpenJDK team and reconsider the plans for --add-opens and the suggested upgrade path. Your stated aims are not going to be accomplished with your plans, and haven't for a while now. All you're doing is making it worse:

Java11 adoption has been set back by a decade because of your plans.
We just keep working around it, and I rather doubt that will change. We can always just make maven and gradle plugins, which may fit your stated technical upgrade path option (essentially, we are now an 'application'), but does not accomplish the goal of making more clear that internal API is being used at all; if anything, it makes it harder to figure that out, not easier, and it makes it more likely that java programmers get the headache of incompatibilities.

In your mission to ensure the java ecosystem has fewer issues with backwards incompatibilities, you're aggressively introducing them instead. You're adding to the problem instead of solving them!

rzwitserloot commented 3 years ago

For the lombok users following this thread: We have some less well known loopholes we can use to bridge a few gaps. We'll start work on gradle and maven plugins in the mean time, which will be a long-term fix.

pron commented 3 years ago

Encapsulation of internal implementation details is the mechanism by which OpenJDK will ensure conformance to the spec, which has been Java's strategy for backward compatibility since its inception; use of implementation details is not portable pretty much by definition, and has been found to be the main hurdle to backward compatibility and the overwhelming cause of the difficulty to upgrade from 8. Moreover, the platform's security will become increasingly reliant on the integrity of encapsulation. Libraries will have the option of either targeting the spec or requesting the application for permission to rely on internals via add-opens. As this is not the OpenJDK mailing list, I'm merely informing you of the strategic decisions that have been made. If you'd like to appeal them, feel free to contact the mailing lists.

rzwitserloot commented 3 years ago

@pron wrote:

the overwhelming cause of the difficulty to upgrade from 8

That's a misleading statement.

JDK11 broke a bunch public API, such as moving javax.annotation.Generated around, in order to fix split packages. I think it was the right call, but it is disingenuous to suggest that 'libraries that do not automatically just work in JDK11, well, they messed up'. No, the compatibility differences between 8 and 11 are, relative to any other java version update, an order of magnitude or two larger, and that's not the fault of libraries. The responsibility lies with the OpenJDK. The vast majority of actual 'library X worked in 8 and no longer works in 11, and it is because they used internal APIs' cases are broken because --add-opens exists, and not because said internal API actually changed. That, too, is a situation where the blame falls at least partly on OpenJDK. Team OpenJDK made the active decision to cause these incompatibilities. It's incompatible only because OpenJDK11 broke .setAccessible. The goals for both of these breaks are perhaps defensible, but I take offense at your strong insinuation that the blame falls squarely on libraries who either used @Generated or other stuff that disappeared from core java in 11, or on those who used internal API. No, it doesn't. They shoulder part, maybe. But only a part, the rest falls on OpenJDK's shoulders.

Moreover, the platform's security will become increasingly reliant on the integrity of encapsulation.

In security analysis, a threat model is often the starting point. More or less a movie script: Spin a story about how a hacker may get access to stuff they shouldn't have gotten access to. Armed with a few of these movie scripts, you can actually 'test' security measures: Which script(s) does it stop, if any. How reasonable are the scripts that it stops.

I have absolutely no idea what you're talking about. Can you paint me a picture of a security compromise that --add-opens will mitigate?

Which mailing list would you suggest is the best vehicle to raise these points with the OpenJDK project?

pron commented 3 years ago

That's a misleading statement.

No, it is not. The overwhelming cause of migration difficulty, without a doubt, has been reliance on internal implementation details. There have also been changes to the spec, but those caused a very small percentage of the issues.

The vast majority of actual 'library X worked in 8 and no longer works in 11, and it is because they used internal APIs' cases are broken because --add-opens exists, and not because said internal API actually changed.

That is false, not to mention that module encapsulation has only been turned on in 16. In any event, I'm not here to debate decisions, merely to inform about them.

Which mailing list would you suggest is the best vehicle to raise these points with the OpenJDK project?

jigsaw-dev.

siziyman commented 3 years ago

@pron

The overwhelming cause of migration difficulty, without a doubt, has been reliance on internal implementation details

To be quite honest, phrase "without a doubt" sounds a little bit weird here. Is there public/private research (be it polls or anything else) that substantiates that, or is it just an educated guess of some sorts?

Thanks!

filiphr commented 3 years ago

For the lombok users following this thread: We have some less well known loopholes we can use to bridge a few gaps. We'll start work on gradle and maven plugins in the mean time, which will be a long-term fix.

As an annotation processor maintainer it would be interesting to see how an approach such as using maven / gradle plugins.

Some other general question, has there been an initiative to add the things that Lombok needs to the Java compiler, perhaps an additional APIs that would make it possible for Lombok to do what it does. There were some discussions in https://twitter.com/gunnarmorling/status/1370687166553161732.

I have no idea of the Lombok internals, but if the Java Compiler allows plugging into the AST creation and modifying it then I guess Lombok will not need to depend on Java internals anymore.

pron commented 3 years ago

@siziyman It is based on an internal analysis by Oracle on the hurdles various companies faced when upgrading. If and when we ever take the time to write a post-mortem, we'll discuss this in greater detail. But I shouldn't have gone into that at all, and for that I apologise, because this is an inappropriate venue for debating a completely different project, and I shouldn't interfere with someone venting frustrations, however misdirected, on their own project's site.

To turn in a more constructive direction, users need not be bothered with lots of add-opens. The relatively few libraries that need internals at all, need very few, while applications, which overall might need many, control the launch and need not bother their users with the command line at all. Lombok can, for example, ship as an application, lomboc, which breaks encapsulation as much or as little as it wishes to.

filiphr commented 3 years ago

@pron the problem that you are saying for Lombok to ship as an application is not that easy. From my understanding Lombok does not need any internals during the runtime of an application. It needs to access certain internals during the compilation phase, since the Annotation Processing API does not provide a way for them to do what they are doing.

pron commented 3 years ago

@filiphr That is precisely why it can ship as an application, just like javac. But that's just a suggestion. Build tool plugins are another.

rspilker commented 3 years ago

I agree that this might not be the place to discuss javac development, there are a few things that I would like to mention.

We decided to not create another executable, because the current ones are fine and well supported in build tools and IDE's.

Regarding the suggestion to create a binary like javac, I think no-one would benefit from that. The command line parameters of javac are not specified nor stable.

Lombok is compatible with all JDKs starting from 1.6. If we would release a new version of lombok, what javac version would we enforce on our users?

We chose use hook in as an annotation processor to make it as easy on our users as possible. We've taken on the burden to be compatible with 11 javac version, OpenJ9 and also several ecj-s. We support a wide range of build tools like ant, Maven, Gradle and Bazel, as well as IDE's like Eclipse, NetBeans, IntelliJ and Visual Studio Code.

What we offer is that our users download a jar that is smaller than 2 MB, put it on their classpath, optionally explicitly point to the annotation processor, and it just works.

It would be great if there was a way so we can express in the manifest what API's to open if we're running as an annotation processor. So far, I was not able to make this work, but possibly I missed something.

I personally would also think that "compiling an application" and "running an application in production at the customer" have different security concerns. And there are a lot of good arguments to give developers an easy way to get rid of these warnings during compilation.

Regarding the use of "private API's", as already mentioned, it would have been very nice if there had been a public AST manipulation API. Both Reinier and I have been talking about this already 10 years ago with the persons responsible for the compiler and annotation processor. The response from those in charge was: "Horrible, we're never going to do that. It would prevent the creation of new language features, and annotation processors are never going to be allowed to change the behavior of the program."

Regarding the "prevent creation of new language features", the idea was that adding methods to visitor interfaces would be backwards incompatible change. And while technically correct, the same arguments can be made regarding JDBC. And also the same "defense" applies: There are only a limited number of JDBC vendors. Well, there are only a limited number of compiler integrations.

Regarding annotations changing the behavior, this is also not longer as black and white.

Possibly, the ideas regarding public APIs and allowing annotation processors to modify the resulting bytecode has changed in past decade. Honestly, Reinier and I have given up that hope, but we're very willing to collaborate with those in charge of the compiler to see how we can improve the java ecosystem.

pron commented 3 years ago

It would be great if there was a way so we can express in the manifest what API's to open if we're running as an annotation processor.

The rule is that the library doesn't decide on encapsulation but that the application has the final say (and the defaults are provided by the target code). That principle is core to encapsulation. Internal implementation details can change at any time, even in patches, and the consumer of a library needs to know that the library is tied to a specific release.

Regarding the use of "private API's", as already mentioned, it would have been very nice if there had been a public AST manipulation API.

That's a whole other discussion, and a good one to have, but I am certain there would be some debate. I am not involved with that area of the platform at all, but I believe that annotation processors were intentionally limited, just as Java agents are (and there are libraries that don't like that, either). The Java platform and the Java language should be free to define the scope of their features and to disallow or not support certain uses. Those still have an avenue through the mechanism I described, even if it means more work.

Anyway, the plan for encapsulation was finalized three years ago but encapsulation wasn't turned on but just emitted warnings precisely to have time for such discussions. But, better late than never, and while I doubt new APIs will be added before the loopholes are closed, if you have some small suggestion, perhaps it could be done. compiler-dev is probably the right place to take this.

A248 commented 3 years ago

The question I have is, what is lombok's long-term strategy for easing away from reliance on JDK internals? Will it continue to implement additional workarounds and hacks to break into javac? Shipping as a maven plugin seems like another way of working around the strengthening of encapsulation brought by recent JDK updates. There will come a point when these JDK internals are no longer accessible, and the hacks will fail. Either that, or lombok will have to continue to use a mechanism such as add-opens to keep prying open internals.

Does lombok really plan to rely on JDK internals indefinitely?

swaranga commented 3 years ago

@pron philosophical differences about where and what such a tool should be allowed to do aside, at the end of the day users use Lombok to solve a very well known issue with Java's verbosity. It is not just about generating some immutable data classes. It is understandable that the Open JDK folks do not want to fund a "boilerplate reduction" project and instead will focus on things like Records, Valhalla and pattern matching which only very partially address the boilerplate problem. These features are much more ambitious and interesting so no wonder this is what gets picked up but it is easy to see how a "boilerplate reduction" project would be 10x more productive for developers for the next 10 years than almost anything else. This is what Lombok tries to address else people are moving to Kotlin. Hopefully OpenJDK folks realize this is a real problem and offers a supported way for tools like Lombok to do its work when the language and the standard tools fall short. I love Java and don’t want to move to Kotlin but if I am forced to write and maintain this boilerplate again after having successfully avoided for so long then Kotlin is much more attractive to me.

@rspilker @rzwitserloot at some point Lombok will need to decide if it wants to continue to be in the business of reducing Java boilerplate and if so may be it is time to think about an alternative approach that comes before javac is executed instead of a plugin in the compilation phase which the OpenJDK folks seem to be unwilling to accommodate.

orionll commented 3 years ago

@namannigam thanks.

I found a better way to add to the Windows system environment variables:

Name:

_JAVA_OPTIONS

value:

--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add- opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk. compiler/com.sun.tools.javac.model=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com. sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools. javac.util=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

You can just set JAVA_TOOL_OPTIONS=--illegal-access=permit

krzyk commented 3 years ago

--illegal-access option will go away soon (it is deprecated), --add-opens will not (maybe some day, but not soon). There is already https://openjdk.java.net/jeps/403 that will make illegal-access a no-op (it is not targeted yet).

orionll commented 3 years ago

Sure, but JAVA_TOOL_OPTIONS is a temporary hack anyway

rspilker commented 3 years ago

@A248 Lombok will always rely on jdk internals, since we need to be participating in the compilation process. We cannot change the code before compilation or after compilation.

@pron The reason I suggested allowing libraries to declare their add-opens in the manifest is that the tool/library maintainers know what they need. I do understand that they want to be open about using non-public APIs. But they can do that by declaring it in the manifest.

How about a java/javac command line parameter that allows users to tell the jvm that they trust a certain library?

Like: java --module-path x.jar --trust x.jar ...

The text below is not meant as an attack, complaint, or anything offensive, but only as an explanation why we are a bit sensitive regarding giving our users the best experience possible.

For the record, both Reinier and I are all for allowing breaking some APIs to improve the platform. We sometimes disagree with the choices of the powers that be, and are especially sensitive to inconsistent reasoning in favor of the opinions of the powers that be. Like: We have to change this API because WE think it is a good idea and it only breaks <1% of existing programs, but we will not support pull requests on your favorite topic because that might break backwards compatibility, even if it is <0.1%.

Or: We're going to no longer allow X, because that makes it more secure for unlikely scenario Y, but fixing vulnerability Z, that's is a very likely scenario, we're not going to do that, because some of our customers depend on that behavior. Yes, security is a trade-off. We accept that, we appreciate that. We want the users to be in control of that trade-off. Inform them, and give them the tools to execute on their decisions.

pron commented 3 years ago

But they can do that by declaring it in the manifest.

You'd need a tool to collect those permissions that various transitive dependencies graciously give themselves. But I'll say yet again that this isn't the place to have that discussion, and I'm not the right person to have it with, anyway.

How about a java/javac command line parameter that allows users to tell the jvm that they trust a certain library?

Yes. It's called add-opens.

For the record...

I'm sorry that you find OpenJDK's governance annoying, but the stewards cannot and need not always explain their decisions fully to everyone, let alone do so until every single person is convinced. It is also possible that, like all people, they can be inconsistent, but the governance places decisions with them.

In any event, it doesn't matter why you rely on internal implementation details; the fact is that those details can change at any time (including patch releases), which means that you're committing to changing your library as frequently as necessary, and that your users need to expressly acknowledge that they understand the potential maintenance burden and accept it.

We want the users to be in control of that trade-off. Inform them, and give them the tools to execute on their decisions.

Yep, that's what add-opens is for.

sblantipodi commented 3 years ago

is there someone who made it to work with IntelliJ ?

krzyk commented 3 years ago

@sblantipodi not yet, I reported a bug for IntelliJ, but they insited on waiting for lombok release. Apparently --add-opens somehow doesn't work correctly in IntelliJ.

jgolubenko commented 3 years ago

So JDK16 is out, but latest 1.18.18 and edge-SNAPSHOT still has issues with maven:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) on project xyz-xyz-abc: Fatal error compiling: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x527dd738) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0x527dd738 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.

Can someone provide info as far as what should be done? I don't think that solution with 25 different compiler arguments can be considered.

rspilker commented 3 years ago

We expect to release a new version of lombok within 24 hours.

rspilker commented 3 years ago

We did a lot of work, and are very close to a release. There will be an updated edge release available with our latest changes, probable within hours.

rzwitserloot commented 3 years ago

In case it wasn't clear, a few minutes after @rspilker posted that, edge was updated with full JDK16 support (with the caveat we have some work to do on records). There are some Pull Requests we want to integrate, and then 1.18.20 will be released; we're aiming at this weekend.

filiphr commented 3 years ago

@rspilker and @rzwitserloot not sure what work you have for Records, but in any case I want to give you a heads up about JDK-8258535, seems like there is a bug in the javac compiler and the API is not returning everything correctly when the records are in different jars. I have no idea whether you are even affected by this or not, but I wanted to let you know in case you hit such a problem

jactor-rises commented 3 years ago

what is the status for 1.18.20?

rspilker commented 3 years ago

1) We are awaiting feedback of the edge release. Can people confirm that it works on java16? 2) We're still working on fully supporting records. The basic support is there, but we're also including @NonNull on record fields. The javac code is done, ecj/Eclipse is still not finished.

ginkel commented 3 years ago

We are awaiting feedback of the edge release. Can people confirm that it works on java16?

For me, it is working fine using edge-SNAPSHOT (not using records, though).

Heatmanofurioso commented 3 years ago

Got 4 microservices working fine with it. With various integrations with Spring JPA and other things, all with JDK 16.

Currently adding it to our beta SDK version at work which serves 50ish microservices, since we are putting the beta branch onto supporting JDK 16, and it's passing all our tests at least.

skotsj commented 3 years ago

edge works on j16 for me

Heatmanofurioso commented 3 years ago

Also to mention that with Edge, IDEA's Project build is working again. It wasn't with the --add-opens added into Maven's compiler plugin

krzyk commented 3 years ago

@Heatmanofurioso For IntelliJ you need/needed to change something else, see comments in https://youtrack.jetbrains.com/issue/IDEA-263241

This will be eventually needed when JDK blocks all the holes.

iksnalybok commented 3 years ago

[Edit]: actually not a lombok issue (more details in my other comment below).

For my part, I still have one --add-opens option to keep in order to compile successfully with the edge-SNAPSHOT version (gradle 6.8.3, openjdk build 16+36 from AdoptOpenJDK):

  tasks.withType<JavaCompile> {
      options.isFork = true
      options.forkOptions.jvmArgs!!.add("--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED")

Without this, it fails with > java.lang.IllegalAccessError: class org.gradle.internal.compiler.java.ClassNameCollector (in unnamed module @0x14d45694) cannot access class com.sun.tools.javac.code.Symbol$TypeSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module @0x14d45694

Heatmanofurioso commented 3 years ago

@krzyk With Edge I don’t. At least for now with JDK 16

I confirm that I don’t have any and everything’s working with JDK16, both building with Maven 3.6.3, and building using IDEAs Build command on IDEA 2021.1 Beta 3, and on the latest stable release

sblantipodi commented 3 years ago

Using edge, maven, intellij and JDK 16.

this is the error I have: java: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x4894d8bd) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0x4894d8bd

projectlombok / lombok

[FEATURE] Make Lombok compatible with JDK 16 #2681