4 ms·

> 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 su

by 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".
  - sixcorners 2y ago
    You could do a lot of the lombok things as a runtime agent. I think @ToString, @EqualsAndHashCode, @Synchronized, @Getter(lazy=true), @UtilityClass, @Delegate, and @Cleanup could all be implemented in a runtime agent. Most of the rest could work as a runtime agent too as long as you were willing to type out the method signature (plus maybe a native keyword) for the things you actually want to link against at build time. I think this would end up being way more difficult to use though and I think it would be perceived to have way more risk compared to lombok as it is now. What do you think? Also is something wrong with paralleluniverse.co? The root domain seems to go to a gambling site?
skissane 2y ago
> 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. There are many other languages for which nobody would make the argument you just made, because the language has some kind of macro system (or equivalent thereof). Lombok is trying to plug some major gaps in Java’s feature set, and the fact that it exists and is so popular is testament to the fact that the gaps are real. And the “public API” I am talking about would essentially be the missing macro system (or the foundations of one) > If Lombok were used like all other Java platform languages it would experience no friction. Because Lombok is trying to be a minimalist extension to Java not a completely different language with very different syntax and semantics.
- pron 2y ago
  > because the language has some kind of macro system Sure, but Java currently does not offer a macro system (which brings many downsides in addition to upsides) and that's by choice. Offering what amounts to a macro system via an API would be a decision with big ramification that is not to be taken lightly. Even then the language needs to decide the extent of the powers of such a system. You don't have to like this state of affairs, but you can't pretend it isn't what it is. Every language gets to choose what guarantees it offers its users. > Because Lombok is trying to be a minimalist extension to Java not a completely different language with very different syntax and semantics. And that's perfectly fine, but the Java specification, by current choice, does not allow making either small or large changes to it. Any language that does not conform to the specification of the Java language is, by definition, not Java regardless of how similar it is. Consequently, the Java compiler does allow code implementing another language to change the compiler's inner workings to compile that new language by configuring it in a certain way, but it does not allow code to do that without special configuration while masquerading as a Java library that appears to conform to the specification.
  - skissane 2y ago

by pron 2y ago

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".
- sixcorners 2y ago
  You could do a lot of the lombok things as a runtime agent. I think @ToString, @EqualsAndHashCode, @Synchronized, @Getter(lazy=true), @UtilityClass, @Delegate, and @Cleanup could all be implemented in a runtime agent. Most of the rest could work as a runtime agent too as long as you were willing to type out the method signature (plus maybe a native keyword) for the things you actually want to link against at build time. I think this would end up being way more difficult to use though and I think it would be perceived to have way more risk compared to lombok as it is now. What do you think? Also is something wrong with paralleluniverse.co? The root domain seems to go to a gambling site?

skissane 2y ago

> 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. There are many other languages for which nobody would make the argument you just made, because the language has some kind of macro system (or equivalent thereof). Lombok is trying to plug some major gaps in Java’s feature set, and the fact that it exists and is so popular is testament to the fact that the gaps are real. And the “public API” I am talking about would essentially be the missing macro system (or the foundations of one) > If Lombok were used like all other Java platform languages it would experience no friction. Because Lombok is trying to be a minimalist extension to Java not a completely different language with very different syntax and semantics.

pron 2y ago
> because the language has some kind of macro system Sure, but Java currently does not offer a macro system (which brings many downsides in addition to upsides) and that's by choice. Offering what amounts to a macro system via an API would be a decision with big ramification that is not to be taken lightly. Even then the language needs to decide the extent of the powers of such a system. You don't have to like this state of affairs, but you can't pretend it isn't what it is. Every language gets to choose what guarantees it offers its users. > Because Lombok is trying to be a minimalist extension to Java not a completely different language with very different syntax and semantics. And that's perfectly fine, but the Java specification, by current choice, does not allow making either small or large changes to it. Any language that does not conform to the specification of the Java language is, by definition, not Java regardless of how similar it is. Consequently, the Java compiler does allow code implementing another language to change the compiler's inner workings to compile that new language by configuring it in a certain way, but it does not allow code to do that without special configuration while masquerading as a Java library that appears to conform to the specification.
- skissane 2y ago