> 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?
> 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
> 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.
> 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.
> 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.
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.
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.
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.
Out of curiosity, though, what language would you imagine is now chosen more frequently than Java for important server-side applications? (you can test your guess against some publicly-available jobs data such as https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...)
It is a vague claim. How do you decide what is “important”?
And if the backing is a non-public market analyst report, different such reports can reach different conclusions.
> you can test your guess against some publicly-available jobs data such as
Which I note has both JavaScript/TypeScript and Python ahead of Java. Both of which are being used for a lot of server-side applications-whether or not you consider them important is rather subjective. (JS/TS is obviously including a lot of front-end stuff, and that site doesn’t disaggregate front-end from back-end; but Python is almost all back-end.)
> It is a vague claim. How do you decide what is “important”?
Java is so clearly ahead and by so much that it doesn't really matter, but generally, "important" can mean size, expected lifetime, criticality for business or some combination of them.
> Which I note has both JavaScript/TypeScript and Python ahead of Java.
Python is about on par or slightly ahead but given that the vast majority of the uses of Java are for server side applications, while the vast majority of Python uses are for data analysis etc., so clearly Java is much more favoured for serious applications (not to mention Python's serious scaling issue). JS is indeed significantly ahead, but again, clearly the vast majority of JS use is for web client programming. Node.js was very big for a while, but it isn't as big anymore. Again, ask any market analyst. Perhaps in 2035 some new language is going to show up and unseat Java, but in 2024, Java is the language of choice for serious server-side apps -- not the majority choice (i.e. all other languages combined may make up more than 50%), perhaps, but the first choice nonetheless.
I’ve been spending the last few months reimplementing Java backend code in Python. I’m sure I’m not the only one. It actually wasn’t originally my idea - I fought the decision and was initially upset about it, but now I’ve been living with it I’m actually glad they forced it on me :)
Yes it is true that Python can have limitations with high scale. But there are solutions to that (multi-process Python app servers for example). And the Python core performance story is improving (GIL removal is finally happening, JIT is moving into the core.) Plus there are a massive number of Java/Spring/etc business apps/microservices which aren’t actually high scale (I’ve written some myself) and could just as easily be done in Django/Flask/etc
The thing with saying that most Python is for data analysis, is what starts out as some ad hoc data analysis or data science prototype sooner or later morphs into a production service. And maintaining the same language from prototype to production makes life a lot easier-especially when the data science team decides they have to fundamentally change algorithms to improve performance leading them to rewrite half of it in the middle of the project. It is much easier to teach a backend developer Python (many of whom already know it anyway) than try to get a data scientist to learn Java.
Python is the de facto standard language of AI, and AI initiatives are driving a lot of Python adoption. But once you are using it for AI, why not consider it for non-AI use cases too? There isn’t a hard boundary between the two anyway - a lot of the Python code I’ve been writing recently has been related to getting OAuth tokens to talk to various pre-existing microservices (mostly Java with some node.js) and although I wrote that code for AI use cases it is obviously very applicable to non-AI use cases too.
> our monolith was built on old versions of Python 2 and Django, which were rapidly entering end-of-life for security support
That doesn't seem to be an issue with Python scalability per se. There are massive creaking monolithic Java apps out there, stuck on old versions of the JDK and various Java libraries, which are just as brittle.
Also, if the discussion is about defending the design choices of the Java language, this blog post doesn't really support that defence, given that while they did choose the JVM as a platform, they also selected Kotlin over Java
I think you're selectively reading that to fit your narrative. The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it:
> CPU-efficient and scalable to multiple cores
> Easy to monitor
> Supported by a strong library ecosystem, allowing us to focus on business problems
> Able to ensure good developer productivity
> Reliable at scale
> Future-proofed, able to support our business growth
> I think you're selectively reading that to fit your narrative.
Please don’t tell people they are selectively reading things, because if you are going to do that, I can do the same right back to you. You will note up-thread I’m complaining about gaps in the Java language (not platform) which are why Lombok exists, and the Java language maintainers’ unwillingness to provide official solutions within the language to address that - which is something Kotlin handles much better (it has some Lombok-like features, plus its DSL support). So, just as you accuse me of selectively reading that blog post to fit my narrative, I can accuse you of selectively reading this thread to fit yours - but mutual accusations of “selective reading” aren’t really adding anything useful to the conversation, are they?
> The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it:
No. As I said, the design choices of the Java language not to provide many Lombok-style features, whereas Kotlin does, has nothing to do with the JVM as a platform
You realize that conversations can evolve right? I merely pointed out that your anecdotal evidence of you rewriting from Java -> Python could be shown in the reverse direction of people moving away from Python. You then claimed this was not for scalability issues, which in fact it was if you didn't selectively read the article to fit your anecdotal evidence. I _never claimed this was about language features_.
> You then claimed this was not for scalability issues, which in fact it was if you didn't selectively read the article to fit your anecdotal evidence
They said at the start of the article that the primary motivation for finding a new technology stack was they were running on Python 2 and old versions of Django, and they also had the kind of issues which commonly happen with monolithic apps (slow bisection).
They then said they wanted to look for a new platform. And some of the reasons why they decided to pick Kotlin/JVM over CPython3 because they viewed the former as having likely better scalability and manageability.
If anyone here is "reading selectively", it is you, not me – you are mixing up (1) their original reasons for looking for a new platform (2) the reasons they chose for picking the new platform they did. If you read the blog post carefully, the reason they chose Kotlin/JVM was because they expected it would scale more easily in the future – which might be true – but the present day scalability issues they were having were due to an outdated stack and a monolithic architecture (problems which can occur on any technology stack), not those future expectations.
I particularly like the current stewards. They've done a great job and have been consistently putting Java and the JVMs best interest at the forefront.
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".
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?
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.
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
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.
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.
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?