6 ms·

> this is a silly update in OpenJDK's war against things like Project Lombok Project Lombok doesn’t use the normal annotation processing system, as that is del

by kaba0 2y ago

> this is a silly update in OpenJDK's war against things like Project Lombok Project Lombok doesn’t use the normal annotation processing system, as that is deliberately “add-only” - you can’t change a class’s implementation, unlike what lombok does. They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism (and prone to break with any javac update, which they don’t control) and I think it’s quite easy to see why it’s not loved (though this “war” bullshit is just propaganda from the creator’s ego or whatever). Also, default being strict is a good stance (both in case of the reflection restrictions) — you can access everything with just a few command line flags, so I don’t really see all the complaints. The point is, you have to know about whether some module in your system accesses another in a non-standard way. Like, are firewalls overly strict because they only allow traffic through port 22 when specified to do so? Should they start with allow-all?

vips7L 2y ago
He knows what Lombok does. He’s the author.
- xxs 2y ago
  Kind of - the point remains. Lombok requires to alter the compiler (hook into), not (just) the annotation processing, itself. I'd be okayish if Lombok was a mere post compilation/enhancement too, but it isn't. It's a per-compilation step
  - vips7L 2y ago
    I’m not refuting the point. Just giving kaba0 context that they are explaining how a library works to its author.
- kaba0 2y ago
  Well, then he just prefers telling lies. Annotation processors can’t modify classes, this is a fact. The primary purpose of Lombok is adding new methods like getX and setX to the same class based on fields. It’s pretty easy to conclude that Lombok is thus not an ordinary annotation processor, and actually uses sun.misc.unsafe to go into the private internals of javac to modify the AST, which has become possible only by specifying some additional arguments, notifying the end-user that some libraries on the class path might do something that can’t be promised to work ad eternity. This is a completely reasonable decision on the Java team’s part (and quite narcissistic to conclude that it is due to your lib..), as many of the breaking changes between 8 and 9 were actually due to libraries doing exactly that. These changes helps uphold Java’s strong backwards compatibility guarantees.
  - vips7L 2y ago
    I wasn’t refuting anything and in fact I’m onboard with these changes. I do not like Lombok and _in my opinion_ it’s for the laziest of devs. I just wanted to give you context that you are explaining how a library works to its author.
    - kaba0 2y ago
      Well, I was sort of explaining it to the wider audience, but fair enough, I wasn’t actually aware it was the author.
skissane 2y ago
> They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead
- pjmlp 2y ago
  Yet another reason not to complain when those things go away.
- pron 2y ago
  > They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java source. You are correct that the JDK does not currently wish to offer an API that would allow code, without any special configuration, to change the compiler so that it violates its own specification. If you want to change the behaviour of a JDK tool in a way that violates its specification, then you need to explicitly configure it to allow that. The Java platform, however, does support many alternative languages, and that is not a violation of the specification. The only reason Lombok is experiencing a technical challenge that, say, Clojure, Kotlin and Scala do not, is because it insists on being used in a way that hides its operation. If Lombok were used like all other Java platform languages it would experience no friction.
  - sixcorners 2y ago
    So would you suggest he change it to work like quasar?
    - pron 2y ago
      That's one option. Quasar was configured to run as a runtime agent while the Lombok compiler runs at compile-time, but the Lombok compiler could perhaps indeed be implemented as a Java agent of javac's. This, however, would also require a special configuration of javac, just like all other alternatives. A simpler option is to offer a separate launcher for that compiler (and/or a special build-tool plugin, which is also what Quasar did in its AOT mode). No matter what, code that wishes to break the guarantees that JDK programs want to make needs to configure that program in some special way so that there's some record, auditable by the application author, saying "this program has been modified in a way that may make it behave not in accordance with its specification".
lucumo 2y ago
Lombok uses the annotation processor to bootstrap itself. That particular part of Lombok is uncontroversial and is in fact well-documented and used by other tools. The parts of Lombok you have an issue with are not impacted by this change.

by kaba0 2y ago

vips7L 2y ago

He knows what Lombok does. He’s the author.

xxs 2y ago
Kind of - the point remains. Lombok requires to alter the compiler (hook into), not (just) the annotation processing, itself. I'd be okayish if Lombok was a mere post compilation/enhancement too, but it isn't. It's a per-compilation step
- vips7L 2y ago
  I’m not refuting the point. Just giving kaba0 context that they are explaining how a library works to its author.
kaba0 2y ago
Well, then he just prefers telling lies. Annotation processors can’t modify classes, this is a fact. The primary purpose of Lombok is adding new methods like getX and setX to the same class based on fields. It’s pretty easy to conclude that Lombok is thus not an ordinary annotation processor, and actually uses sun.misc.unsafe to go into the private internals of javac to modify the AST, which has become possible only by specifying some additional arguments, notifying the end-user that some libraries on the class path might do something that can’t be promised to work ad eternity. This is a completely reasonable decision on the Java team’s part (and quite narcissistic to conclude that it is due to your lib..), as many of the breaking changes between 8 and 9 were actually due to libraries doing exactly that. These changes helps uphold Java’s strong backwards compatibility guarantees.
- vips7L 2y ago
  I wasn’t refuting anything and in fact I’m onboard with these changes. I do not like Lombok and _in my opinion_ it’s for the laziest of devs. I just wanted to give you context that you are explaining how a library works to its author.
  - kaba0 2y ago
    Well, I was sort of explaining it to the wider audience, but fair enough, I wasn’t actually aware it was the author.

skissane 2y ago

> They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead

pjmlp 2y ago
Yet another reason not to complain when those things go away.
pron 2y ago
> They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java source. You are correct that the JDK does not currently wish to offer an API that would allow code, without any special configuration, to change the compiler so that it violates its own specification. If you want to change the behaviour of a JDK tool in a way that violates its specification, then you need to explicitly configure it to allow that. The Java platform, however, does support many alternative languages, and that is not a violation of the specification. The only reason Lombok is experiencing a technical challenge that, say, Clojure, Kotlin and Scala do not, is because it insists on being used in a way that hides its operation. If Lombok were used like all other Java platform languages it would experience no friction.
- sixcorners 2y ago
  So would you suggest he change it to work like quasar?
  - pron 2y ago
    That's one option. Quasar was configured to run as a runtime agent while the Lombok compiler runs at compile-time, but the Lombok compiler could perhaps indeed be implemented as a Java agent of javac's. This, however, would also require a special configuration of javac, just like all other alternatives. A simpler option is to offer a separate launcher for that compiler (and/or a special build-tool plugin, which is also what Quasar did in its AOT mode). No matter what, code that wishes to break the guarantees that JDK programs want to make needs to configure that program in some special way so that there's some record, auditable by the application author, saying "this program has been modified in a way that may make it behave not in accordance with its specification".

lucumo 2y ago

Lombok uses the annotation processor to bootstrap itself. That particular part of Lombok is uncontroversial and is in fact well-documented and used by other tools. The parts of Lombok you have an issue with are not impacted by this change.