3 ms·

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

> 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
  > You don't have to like this state of affairs, This attitude is part of why I have given up on Java – despite having spent so much of my career on it – and nowadays avoid it as much as I can. In my own mind it is a legacy language - if I have some existing code base in Java, extending/enhancing it might be the path of least resistance, but for a greenfield project it would be far from my first choice.
  - pron 2y ago
    Any philosophy, let alone policy, isn't for everyone, and we want to make our policies clear so that the people who align with them will choose the platform, while those who do not -- won't. It is due to this careful philosophy and policy that places an emphasis on integrity (safety) and specification that has made Java the #1 chosen language for new important server-side applications today; i.e. it is more people's first choice than any other language for this domain (despite others who have considered it a legacy language since 2006). Java says that an application can monkey-patch whatever it likes but that a library needs to be given that permission by the application. If that's not what you need, then Java isn't for you and you should consider it a legacy language for your needs. Like some other languages and unlike others we will continue placing an emphasis on safety, as that appeals to most of our users and hopefully to future users, too. Those who want to easily monkey-patch anything from any code without controls -- which is also a valid requirement -- also have a selection of languages to choose from.
    - skissane 2y ago
      > Java the #1 chosen language for new important server-side applications today What is the evidence for that claim?
      - pjmlp 2y ago
        Any real world market analysis survey that shows what languages are used across the industry, not only SV startups, when performance matters. Plus the whole development toolchain for the mobile OS with 80% of the world market, even if Kotlin is favoured, there is plenty of Java on Android Studio, Gradle, Bazel, AOSP, and Maven Central.

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
> You don't have to like this state of affairs, This attitude is part of why I have given up on Java – despite having spent so much of my career on it – and nowadays avoid it as much as I can. In my own mind it is a legacy language - if I have some existing code base in Java, extending/enhancing it might be the path of least resistance, but for a greenfield project it would be far from my first choice.
- pron 2y ago
  Any philosophy, let alone policy, isn't for everyone, and we want to make our policies clear so that the people who align with them will choose the platform, while those who do not -- won't. It is due to this careful philosophy and policy that places an emphasis on integrity (safety) and specification that has made Java the #1 chosen language for new important server-side applications today; i.e. it is more people's first choice than any other language for this domain (despite others who have considered it a legacy language since 2006). Java says that an application can monkey-patch whatever it likes but that a library needs to be given that permission by the application. If that's not what you need, then Java isn't for you and you should consider it a legacy language for your needs. Like some other languages and unlike others we will continue placing an emphasis on safety, as that appeals to most of our users and hopefully to future users, too. Those who want to easily monkey-patch anything from any code without controls -- which is also a valid requirement -- also have a selection of languages to choose from.
  - skissane 2y ago
    > Java the #1 chosen language for new important server-side applications today What is the evidence for that claim?
    - pjmlp 2y ago
      Any real world market analysis survey that shows what languages are used across the industry, not only SV startups, when performance matters. Plus the whole development toolchain for the mobile OS with 80% of the world market, even if Kotlin is favoured, there is plenty of Java on Android Studio, Gradle, Bazel, AOSP, and Maven Central.