Revisiting Java in 2021 – Part II
avanwyk.comThe comments about Scala resonated. I've been working in a a large Scala codebase for the past few months. I've become a partial fan of the language, however: there have been multiple conversations like : (in screen share with colleague) "See that double right arrow there? What's that mean? (after attempts to find answer in books, SO, etc, and trying to guess based on the three/four other uses the language makes of double right arrow that I've already grokked). Colleague: "Uhh, dunno, beats me".
On reflection, I think if the Scala creators had been a bit less obsessed with symbology and had either a) used keywords rather than symbols more often or b) consistently only ever used a symbol for the same one purpose; the outcome would have been significantly better.
There are just too many symbols to cover them all in a short book or cheat sheet, and symbols are very SEO-unfriendly. And even if you do find the relevant medium article, it's not necessarily clear that you're looking at the same use case for that particular symbol.
I've been a Scala and FP developer since 2009ish and it suffered initially from over-enthusiasm to make it seem 'futuristic' as a rejection of the overly verbose reality of enterprise java codebases.
There's been a lot of sensible work in the core codebase since then to move towards more coherent idioms, unfortunately the 'we can make Scala into Haskell' crowd have since taken up the mantle and everyone has become obsessed with the idea that no boilerplate starter project is complete without cats or similar which perpetuates barely-legible and unnecessary confusion in situations that should be simple.
If you can't use an IDE to jump to the definition (or list all possible definitions) of a function, then aren't you missing one of the main benefits of a statically-typed language? If you can't use the static types for static analysis, what's the point?
You can indeed jump to the method definition in IDEA, although getting the IDE to a good point of dealing with implicits, typeclasses, and their ilk has been a long road.
Jump to definition is not some special benefit of static typing. Every Common Lisp IDE that I know of offers it, for example.
Jump to definition is only one part of static analysis. Typechecking is another, performance is a third one.
You can't jump to the definition of something that's essentially a keyword in the form of a symbol.
Compile time verification of correct syntax and spelling is important aspect
> I think if the Scala creators had been a bit less obsessed with symbology
This might not be something to pin on the language designers, if you're using certain third-party libraries. Indeed it is possible to name a method pretty much whatever you want, with some constraints[0]. Wanna call it "!^"? Go ahead! But, this is afoul of the naming convention in many cases[1]--acknowledging that the convention may have previously been a bit more lax in this regard.
OTOH the distinction between "::" and ":::", and the implications of stuff like "<:" often do require a refresher if they're not part of one's day-to-day.
[0] https://stackoverflow.com/questions/7656937/valid-identifier... [1] https://docs.scala-lang.org/style/naming-conventions.html
A house is leaking from the roof.
If the language designers allow methods named "!^", then someone will actually name a method "!^".
Most languages allow a variable called "i", but it is for the programmer to choose when that is appropriate.
!^ might be useful, if the code implements an algorithm which uses this notation in the literature.
A hoarder never throws anything away because it "might be useful". That is not a useful criteria for choosing language features.
I think variables names and infix operators/method names are very different.
> A house is leaking from the roof.
Should one prefer the case where an adult cannot order a steak, because a baby can't chew it? Like, there is a grammar for acceptable identifiers, and it is a little broader than most. To me it seems like a good thing that unicode/multibyte identifiers are allowed, and that not more than the necessary portion of the top keyboard row symbols is reserved.
Yes, I'd like to have a beer with the people who think it's smart to allow punctuation as identifiers. Hopefully by the third pint I could change their minds...
Not a scala programmer, but I searched for "scala cheatsheet" and got the answer:
https://docs.scala-lang.org/cheatsheets/
Double arrow seems to have multiple uses - for anonymous functions (like in js) and for pass-by-reference arguments (I guess scala is pass-by-value by default).
(Surprised at how Erlang-y it feels, especially WRT pattern matching)
As noted in the parent, I read the cheat sheet. It doesn't cover the use case for => I was trying to understand.
The best (but still not exhaustive) doc is : https://stackoverflow.com/questions/7888944/what-do-all-of-s...
Sure but the issue is that when a single symbol has multiple meanings that presents an obstacle to learning the language and understanding a code base.
How do you feel about = (assignment and equality check)? Or > which can be used for markup or less than or part of a function arrow? Or {} which can be used as a block or as an object? Or : which can be used for...so many things! Even the humble . can be used to dereference or as a decimal point. My point is that if "a symbol having multiple meanings" is a problem, then basically all languages have a problem.
Obviously that's a bad idea, which is why many languages don't overload = with two purposes.
{} always means "group of related stuff"
: always means : (sic) separator between a thing and something about the thing.
Well Java isn't too bad in that regard. It uses = for assignment and == for equality.
I wonder if clojure codebase found a right balance there. Hickey made it explicit to have short but very obvious nouns except a few macros)
I think it's more library authors that are to blame than the language author. He merely opens the gate for that kind of overloading, maybe too liberally.
I don't think symbols necessarily need to be SEO friendly. I think Google just doesn't treat them as well as they could?
They need to be google-friendly, or they need to exist in a world where code-friendly search tools exist.
Isn't that the same thing?
I think when Project Loom comes out that Kotlin on top of the JVM will be a tough combo to beat.
Kotlin is basically the language Java should be after 20 years of lessons learned, e.g. language-supported Optionals. The JVM is a battle tested platform. Once Project Loom comes out, you'll get the "best of both worlds" - the easier (i.e. "no functions 'colors'") programming model of multiple threads like in Java, but the scalability and performance of things like async in NodeJS.
The biggest real-world benefit of Kotlin is nullity prevention and immutables (of which Optional is a corollary).
It's not clear whether Loom will be a big hit. Personally, I think the Actor model is the best application level concurrency "primitive", and Loom is just about fibers & continuations, both of which are parts of Actors but aren't really Actors themselves.
No, but if your threads are basically 'free' then you can just model an actor as a thread+LinkedBlockingQueue or whatever channel abstraction you want to use.
I think for Kotlin that ship has sailed with the introduction of suspend functions.
I remember reading that you can plug any continuation model into the suspense mechanism?
Java seems to be heading for ML-like features while Kotlin is a "better Java". I think Kotlin lack a vision for the future, and might lose market share as Java itself gets better.
Since Java is now a neglected, second-class, incompatible elder citizen on Android, this is unlikely to happen.
I don't follow Android development at all, so thank you for the correction.
Thanks for article. Today I learned about Project Leyden, whose primary goal will be to address the long-term pain points of Java’s slow startup time, slow time to peak performance, and large footprint.
I just recently started to explore Quarkus, GraalVM to optimize Java microservices for cloud architecture. It's good to know that Java moves into that direction.
https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...
> to optimize Java microservices for cloud architecture
I'm kind of curious about this. What kind of lifetimes are you looking at for JVMs? Are you trying to use Java in lambdas on demand to user requests? What kind of warmup time are you seeing right now?
I'm personally interested in reducing RAM consumption. Right now Spring Boot application with very little functionality (like few REST endpoints, talking to database) easily eats few hundreds of megabytes RAM. Similar node.js application eats few dozens of megabytes RAM. Cost of using Java is high, when there are plenty of those services, especially when we're talking about resilient services and launching 2-3 instances of every service.
Fast startup time is just a good bonus.
That's for my use-case. Lambdas, obviously, demand fast start-up.
To be fair, that's spring boot. It's a bloated ecosystem. If you write using lean libraries (which you'd want to do for lambda anyway) then you're looking at 0.1-0.3s jvm startup times. If that's supposed to be serving a user then it may be taking too long, but in that case use an EC2 instance rather than trying to be serverless.
what woud be a lean alternative for microservices to spring boot?
The most lean and interesting alternative IMO is Helidon SE. It's backed by Oracle and uses very sane approach.
The most pragmatic alternative IMO is Quarkus. I don't really like it, but it seems to be the most popular alternative to Spring and probably will become standard de facto, unless Spring will jump ahead with some revolutionary changes. It's backed by Red Hat and seems to have the most momentum.
The best approach IMO is not here yet. Frameworks, mentioned above, rely heavily on reactive architecture. It's just not needed with Project Loom, so there's plenty of unnecessary complications. They even rewriting JDBC drivers.
I'm going with Quarkus for now, but I'm waiting for ideal framework to appear.
What's your opinion on vert.x vs quarkus? For more general purpose web stuff, it seemed to me vert.x had more libraries.
Also, as for database, I really got fed up with hibernate (all configuration and stuff), do you know any simpler asynchronous / reactive alternative that handles object mapping? (automatically serializing from / into SQL objects).
Quarkus uses vert.x for web. What it does is provides a standard way with instructions to build a native image (along with some added functionality). I don't know if it's easy to build a native image from just vert.x app.
About database, sorry, I have no idea. Check out JDBI, JOOQ, those are most popular ones, AFAIK.
Also Quarkus adds reactive API to hibernate and some API to simplify some mundane Hibernate API, so maybe you'll like it.
> Quarkus uses vert.x for web.
Thanks. I was thinking it's different because it used Mutiny APIs or something.
> Also Quarkus adds reactive API to hibernate and some API to simplify some mundane Hibernate API, so maybe you'll like it.
Thank you. I will check it out.
Micronaut is worth a look
Lambdas, commandline applications, everything which needs startup times in the range of a few milliseconds.
> There are ... many well-written books on how to program it effectively
Would anyone be able to recommend a good resource for quickly learning modern Java for experienced programmers that already know, let's say, one of {Python,Javascript} AND one of {Go,Rust,C,C++}, but have zero JVM experience?
(Ideally the resource would also teach some relevant things about the JVM itself rather than the Java language specifically.)
Hmm. Great question. I've always liked Josh Bloch's "Effective Java" because it's targeted toward experienced programmers, and he expressed (correct) opinions about things like immutability. But the book is very old (2001).
One way to get into it is to build something real, first on bare bones (e.g. 'javac Main.java; java Main'), then bare bones Maven, then finally pick a great starting project which itself curates some of the best techniques and libraries currently available for the platform. I am partial to Dropwizard. Do not skip the first two steps though, because if you dive immediately into Dropwizard you'll be disoriented.
I would also suggest avoiding IDEs at the beginning. They hinder more than help at the beginning. One fun thing to do is download the JDK and the docs and source (usually a separate download, alas) and then disconnect your laptop from the internet. See how far you can get with it! Sadly, File IO in Java has always been verbose, but it is probably useful for you to suffer through it.
The 3rd edition of Effective Java was published in 2017, it's been updated to java 9.
I would still recommend Effective Java, many of its items are still relevant. If you want to avoid being bitten by Java's gotchas, this is the book. Also Java Concurrency in Practice is a must in my opinion.
I'd be surprised if you found any dramas with the language.
What will keep you in the office to all hours is the ecosystem. Now the ecosystem is probably best in class so don't mistake this as a slight, but it's huge and complex.
Learning Gradle (or Maven), understanding how to make building java apps fast (because the default is slow package assembly times), learning some of the large frameworks (if you go down that route) can keep you occupied for years.
If you're fresh to java, i'd probably encourage you to try avoiding the incumbents like Spring and see how you go? Without Spring, Java is actually pretty efficient. A hello-world rest service with spring results in around 6,000 classes being loaded.
That said - spring, used idiomatically, is a productivity boosting powerhouse.
You can’t avoid spring unless you’re in a small shop. It’s basically mandated/standardized at most places since “everyone knows it”.
Sadly, Java and Spring are basically a package deal these days. Enterprise shops are likely to run on Spring.
I forgot where I read this, but I think it's true: With Gradle to do anything you have to understand everything.
(Not a fan of Gradle)
Thanks. I have to say, this sounds awful -- it sounds like it will be a huge time sink and an impediment to learning about areas of software engineering that transcend specific languages (say, service orchestration, distributed systems, system architecture patterns, workflows, etc)
It is awful.
However it’s not all accidental complexity. To pick a random example, there’s a reason typo squatting is a thing in npm or pypi but not in maven/gradle. The mitigation’s that prevent this are not free, they add complexity (e.g. signing before publication, dns records, immutable packages etc).
But there’s definitely some areas of accidental complexity remain. While gradle CAN be used well (e.g. <3 min build on large code base), the default in large teams seems to resemble a kind of tragedy of the commons. Full of sharp edges and >45 min builds.
Modern Java in Action is a fantastic book. It goes into Streams, Optionals, new Date Time API, basically the "big features".
More recent changes are relatively smaller and probably don't need a full book to cover.
Would recommend it after Effective Java (3rd edition).
I don't have an answer to your question, but I would suggest the following:
skim over Java 5 syntax. It should be very easy to understand for anyone with programming experience.
Explore Java 8, 11, 17 features, but try to map all the syntax to Java 5, because those features usually are just a syntax sugar and I think that it's easier to understand those features this way.
Do not dive into standard library too much. It's vast and you can spend a lot of time studying it, but that's not necessary to start.
It should take few days of learning and experimenting.
After that you have to choose a framework, because Java applications are very framework-heavy ones. And that's where most of complexity comes from. People usually use Spring these days, so that's probably would be the most reasonable choice. There's no easy path, you'll struggle a lot and that's unavoidable. Modern Java Frameworks are full of hard to grasp concepts, tricky magic code and 20-year old roots buried in the depths of stacktraces.
Stackoverflow a lot, and you'll eventually naturally learn most things you need to know.
At some point I'd recommend to prepare for Oracle Java Certification (Oracle Certified Professional). It's a very good exam with lots of core Java topics and with some gained experience you'll structurize everything in your brain and you'll learn few things that avoided your attention before. I don't suggest to actually pass the exam, as that would cost some money and effort, so it's up for you to decide, but preparing to exam is very worthwhile time investment.
> After that you have to choose a framework, because Java applications are very framework-heavy ones. And that's where most of complexity comes from. People usually use Spring these days, so that's probably would be the most reasonable choice. There's no easy path, you'll struggle a lot and that's unavoidable. Modern Java Frameworks are full of hard to grasp concepts, tricky magic code and 20-year old roots buried in the depths of stacktraces.
Honestly that does not sound like a culture/ecosystem it is pleasurable to work within. Why wouldn't people choose something more modern and lightweight than Spring?
One of the strongest points of using a framework is that it's easy to find other people who already know that framework. And that depends on framework popularity. It's like old motto "nobody was fired for choosing IBM".
Spring is not well suited for modern microservices running in the cloud. Its startup time is slow and its memory usage is high. There are other frameworks emerging, optimized for GraalVM native image, most notable ones are Quarkus, Micronaut, Helidon. But their popularity is nowhere near Spring. May be in 5 years things will change.
> Honestly that does not sound like a culture/ecosystem it is pleasurable to work within.
I agree. Of course I’ve heard people criticizing and making fun of java over the years, but I didn’t realize the (very helpful and thoughtful) answers to my question would be so depressing.
Spring is largely "Java: the missing parts", implemented in a very poor way. It's semi-standard, even though it's not part of the core language.
What's weird is that every app in Java uses a DI container, while just about no apps that I've encountered in the rest of the world worry about anything that heavy. Most apps just cheat and use a bit of global state or maybe roll their own service locator pattern and don't worry about it. From the outside it seems like Java's sweet spot is really massive applications where you can't just cheat in one or two well-known spots in the code and call it good.
The sad thing is that DI doesn't need to be heavy. I looked into this for some projects I was planning, and there are some lightweight (if technically off-putting, IMO - see Dagger 2 syntax) ways to achieve this. But everyone just reaches for the big frameworks in the first instance.
I'm currently reading Cay Horstmann's "Core Java for the Impatient" and like it a lot.
One point that the author fails to mention regarding Jetbrains is that they developed Kotlin and that Intellij at this point is largely implemented in it. Their whole strategy features a lot of Kotlin at this point. So, the best IDE for Java is built by the company that develops a drop in replacement for it. Not a minor point to make. The IDE that Oracle acquired along with Sun (Netbeans) is still there of course but it's rare that I meet someone who even knows what that is.
This is actually also a weakness because there is no good competition in terms of alternative Kotlin IDEs. Eclipse and VS Code have Kotlin plugins but they are nowhere near as good as their Java support. Nice in a pinch if you really can't be bothered to install Intellij.
Java undeniably has great alternative IDEs. I think it's still unrivaled in the wide variety of very decent IDEs and by pretty much every other language. And that has been the case for a long time. Eclipse and Netbeans are still around and both still do a fine job. If you use emacs or vi, there are decent plugins for those as well. VS Code of course has pretty decent support. Kotlin support for all of those is not at the same level.
But one positive thing that has come out of Kotlin (and Scala) keeping the pressure on Oracle is that they have rapidly rolled out a lot of new Java and JVM features in the last few years. JDK 17 is a nice piece of technology with lots of under the hood changes that benefit all JVM languages. So is Graal. I think the efforts to make Java more usable are also going to be nice for people with Java code bases.
Like the author though, Kotlin is my main language at this point.
Kotlin's dependency and relationship with IntelliJ is one of the largest reasons why I don't use it. I really dislike IntelliJ and Kotlin is mostly unusable without it.
I don't see why I should force my company into vendor lock-in (IntelliJ/Kotlin) on what is otherwise an open platform (Java/OpenJDK).
This is unfortunate indeed. I'm hoping the Kotlin language server for VS Code will get some love, it doesn't seem to be working at this point.
Yes, this was the main reason I chose Java instead of Kotlin when starting our last big project. Would have loved to use Kotlin, but the vendor lock-in was the deal breaker.
IDEA is 56% Java and 15% Kotlin.
Rider, their closed-source .NET IDE, is supposedly written in Kotlin though (except for the parts that are written in C#):
https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a...
Rider is pretty much IDEA customized for dotnet. Code analyzer/autocompletion backend is written in C# running on top of .NET (5 IIRC). I am not affiliated with JetBrains in any way and have no visibility into its internals, but am pretty sure that Rider and IDEA share most of the code (which is obvious to anyone who has spent significant amounts of time in both IDEs).
I'm not a huge fan of Java, but a lot of the improvements being worked on here are promising.
I'm 90% certain I would only really start working on a project if we could use Kotlin just because the ergonomics are vastly superior. If that requires the trial-by-error mentioned ITA to figure out the best practices of various approaches available I think I'd take that trade off.
I've been using Kotlin since 1.0 but I have to say the ergonomics of it are not vastly superior to Java.
As others have mentioned, with Kotlin you're pretty much limited to Jetbrains' IDE, you have a new runtime dependency, not just a compiler, which is rapidly changing and requires updates on the code base frequenly (one of my projects used Kotlin for testing with KotlinTest - which recently changed names to KTest I think - and it was horrible to have to re-write most of my hundreds of tests to be able to upgrade when they went from JUnit 4 to 5 and in the process re-wrote all of it, basically), the compiler is slower and it starts to feel very much once you have thousands of lines of code... not to mention that there's a fairly big overhead of not only having to have javac installed, but also the Kotlin compiler and standard library... also, you probably want to use Gradle with the Kotlin DSL which in my view is really, really slow and unpleasant to work with - though they've finally been improving this recently - in the last couple of years.
So, yeah, I like to write Kotlin code better than Java, but due to all of these factors and the fact that Java is now fairly close to Kotlin in functionality, if I had to start a big project today, I would pick Java for sure.
Have the ergonomics of Scala improved with version 3?
I‘m planning on revisiting Scala at some point
Yes, a large part of Scala 3 was explicitly about improving ergonomics and making language features clearer to use. Some examples of this are:
- Greatly improved error messages [1]
- Revamped implicit syntax that makes it more straightforward to declare type classes and extension methods. [2]
- Simplified support for macros [3]
[1] - https://www.scala-lang.org/blog/2020/05/05/scala-3-import-su...
[2] - https://dotty.epfl.ch/docs/reference/contextual/type-classes...
[3] - https://docs.scala-lang.org/scala3/guides/macros/index.html
optional braces if you are into that sort of thing. https://docs.scala-lang.org/scala3/reference/other-new-featu...
I use Java every day, but we're stuck with Java 8 because of the confusing and frankly scary licensing around later JDKs. I would love to move to 17 but I need something to show to the C-levels that gives them warm and fuzzies around the license. Does such a thing exist?
EDIT: I find it quite depressing that so many want to attack people for being confused around Java licensing. I submit that it is confusing on its face, but moreover insiders seems to understand how confusing it is, too:
https://softwareengineering.stackexchange.com/questions/1194...
https://medium.com/@javachampions/java-is-still-free-2-0-0-6...
I just don't buy this at all. Unless you're talking about a seed-round startup, where the C-levels are all 20-something year old frat bros straight out of college. No remotely competent CTO or CIO in any halfway respectable enterprise is still going to be confused about Java licensing in 2021.
The only people I EVER encounter with any confusion around Java licensing are students, entry-level devs, and people from other ecosystems who parrot things they hear on Internet forums.
OpenJDK is free and open source. It imposes no license restrictions on your server-side applications, and these days imposes virtually no limitations on retribution of the JDK itself with traditionally-shipped applications.
Oracle's own binary build of the OpenJDK source code is a commercially licensed thing, because it comes with some extra proprietary tools that people might care about when profiling applications in a large enterprise. But there are other OpenJDK builds with no cost or licensing restrictions whatsoever, from Azul, IBM, Amazon, and others. Outside of the largest and most conservative Oracle shops, virtually everyone uses one of these free JDK builds.
So much nonsense FUD is made from "lack of commercial support" for the non-Oracle JDK builds. Not "having someone to sue" if something goes wrong, etc. For one thing, who are you supposed to sue when you have a problem with Python or Node? If you want someone to be financially liable to you, then you have to financially pay someone to take on that liability. In practice though, have you ever even heard of a lawsuit over a JDK bug? This is nonsense.
Ignoring the ad hominem attacks, I appreciate your attempt to clarify the situation. However, you are factually wrong about Oracle's position, because they actually offer two different builds of Java - one that is GPL'd (with classpath exception) and one that is commercial[1]. I take the first claim seriously because it's downloadable as a tar.gz file without any license acceptance. However "GPL" is another thing that causes worry among the C-levels (and myself). A superficial reading might be that Oracle's JDK does not come with the GPL encumbrance. But this also raises the question: what differs between the various JDK builds? And again, what is the legal status of "OpenJDK" particularly WRT Oracle?
I personally don't think these are stupid or trivial questions. Nor do I think the answers are obvious. Nor are they nonsense FUD. I am certainly NOT an Oracle partisan - I saw first hand what they did with Sun.
> A superficial reading might be that Oracle's JDK does not come with the GPL encumbrance.
This is the whole point of the "classpath exception". You can run, build and distribute Java programs under any license you choose.
> But this also raises the question: what differs between the various JDK builds?
Very little typically. Some like RedHat or Amazon enable extra options, like the Shenandoah GC. The big difference is who you contact for support.
> what is the legal status of "OpenJDK" particularly WRT Oracle?
I'm not sure what this question even means, but frankly given Microsoft, IBM and Amazon are all building and distributing their own builds of OpenJDK I don't think there are any significant legal issues, these are all companies with teams of lawyers on retainer.
How about this: what is "OpenJDK"? It used to be an independent open-source clone of the Sun-then-Oracle implementation of the JVM/JLS/JSR specs under a liberal license. Now it seems to mean something different - like a working group that manages the specs, but no longer has a build of it's own. By convention, it seems that Oracle's "OpenJDK build" is the "default" OpenJDK build, but Oracle also provides a "commercial build", which is also, confusingly, an implementation of "OpenJDK".
Meanwhile other vendors have "OpenJDK" builds: Amazon (corretto), Red Hat, etc. This means that they offer binaries that implement the OpenJDK specs.
My mental model is currecntly: So there's a spec and an implementation, OpenJDK can refer to both, and a vendor can have multiple implementations of OpenJDK (spec), and some of impls can be closed/commercial, as in the case of Oracle (and maybe Red Hat?).
OpenJDK was never an independent clone. OpenJDK was started by Sun and was all of the JVM code they could relicense. Contributions to it were done either by Sun themselves, or by companies and individuals that signed a contributor agreement. This has continued under Oracle. Notably this includes Redhat, IBM, Microsoft, Azul, Apple and SAP. Originally the code didn't have enough components to produce a useful JVM, and Redhat put a lot of effort into producing builds that integrated with IcedTea to produce a fully Free Software JVM. Now though the OpenJDK has all of the components needed to produce a JVM.
OpenJDK is Oracle's reference implementation of Java, and provides a GPL+Classpath exception licensed build on their website. Additionally, Oracle provides a build a commercially supported build from their website. The commercial builds from Oracle have included other additions, but over the years the amount of closed sourced add-ons has decreased.
Other vendors provide builds of the OpenJDK, most include additional code, although for the most part the changes are minimal. All of these builds are based on the OpenJDK, and adhere to the GPL+Classpath exception.
There is also Azul Platform Prime/Zing. Which is there own JVM with an LLVM-based JIT, I'm not sure if they're using any OpenJDK code, but if so I assume they have a commercial agreement with Oracle.
> How about this: what is "OpenJDK"? It used to be an independent open-source clone
Please educate yourself before spreading misinformation on this forum.
OpenJDK is not a "clone", a "fork", or some other re-implementation of the Oracle JDK. It's the other way around. OpenJDK IS the source code for the Java Virtual Machine and standard library. All binary distributions are based on this source.
Some binary distributions are freely available. Others include additional proprietary tools, or commercial support or whatever, and require paid licensing. But these all derive from the some common upstream.
You are painting a picture that is equivalent to saying that the Linux source code is a "clone" of RedHat Enterprise Linux. That is not accurate whatsoever.
May you get down-voted into oblivion for your rudeness. It's not only unnecessary and uncalled for, but redundant.
If you'd like an example of how to correct someone's misunderstanding in a constructive manner, see sibling comments, which were posted prior to yours by an hour.
> what is "OpenJDK"?
It is an open source project, comprising a codebase, a set of contributors, and various mailing lists, processes, and so on, just like any other open source project.
The codebase is a continuation of the original Sun (later Oracle) JDK, now licensed under GPL 2 [1], with a linking exception that makes it fairly similar to the LGPL [2].
The contributors are mostly employees of big companies, with Oracle having by far the largest share.
The OpenJDK project releases source code, but does not itself distribute binary builds. In this respect, it is like numerous other open source projects, such as GNU coreutils.
Binary builds are made and distributed by operating system distributors (Red Hat, Debian, FreeBSD, etc), and also by various independent groups. As usual, each distributor may or may not add its own patches before building, and may or may not contribute these upstream. Eclipse Adoptium (formerly known as AdoptOpenJDK) [1] does not apply significant proprietary patches (just branding stuff), so it's a good place to get a plain vanilla OpenJDK build. Amazon's Corretto [4] in principle could contain whatever patches Amazon thinks are cool, but in practice usually just has a few backported bugfixes [5]. Azul's Core (formerly known as Zulu) has a bunch of patches (i couldn't find a list), and an option of commercial support) [6]. Oracle have a couple of builds, but you can ignore them. There are also builds from SAP, Bellsoft, and maybe others, but i have never really looked into them. Most people i know just use the AdoptOpenJDK / Adoptium builds, or whatever their distro gives them.
EDIT: I got the Adoptium thing slightly wrong. AdoptOpenJDK made builds; those builds are now called Eclipse Temurin. Eclipse Adoptium is some sort of 'marketplace' where different builds are validated and made available. To me, this sounds like one of those Apache grand ideas that won't go anywhere, but we'll see.
[1] https://github.com/openjdk/jdk/blob/master/LICENSE
[2] https://opensource.stackexchange.com/questions/1410/what-is-...
[3] https://adoptium.net/releases.html
[4] https://aws.amazon.com/corretto/
[5] https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...
Yes, that all seems so trivial a small child could understand it. So what's my problem?! /s
But seriously, you don't see how this might be confusing? And what you've described is really only the tip of the iceberg. Who defines the specs? Who writes the compliance tests with the specs? Who runs those and certifies that implementations are compatible? What limits are there on entities that make builds, either on the patches they can apply (and still call it "Java") or the licenses they can adopt? What does "GPL with classpath exception" mean in the real world, that JDK-itself changes must be upstreamed, but linked applications need not be? What are the limits there?
The point is, getting an open source JDK binary is not easy, especially if you want to understand what you're getting. "OpenJDK" may exist as an OSS project, but I wouldn't call it typical. Not because it doesn't release binaries (although I just discovered it does, provided by Oracle for Windows/Linux only), but because of the license, the owner, and the owner's relationship to binary builders. The binaries you can get in practice have unknown additions from the vendor, and possible adjustments to the license (or is only Oracle allowed to make alternative licenses for an OpenJDK build?)
Compare java distribution to, say, node or python. Is it really fair to accuse someone who is confused of being an idiot?
> What does "GPL with classpath exception" mean in the real world, that JDK-itself changes must be upstreamed, but linked applications need not be? What are the limits there?
The exception is very broad and fairly simple.
Azul has a good breakdown of it https://www.azul.com/blog/why-the-classpath-exception-is-so-...
The short answer though is if you link to a GPL+Classpath exception library you may distribute the results under any license you choose.
Hmm. Without Corretto, which is "recent", I don't see how your argument holds. "No" seed stage company is going to use something from Azul, and probably not from "regular" IBM either (that is, exempting RedHat).
Without Corretto, I think Oracle really has poisoned the well.
It's particularly confusing because "OpenJDK" used to be an independent group who's purpose was to build a fully open-source Java - and it was Apache licensed. Now, it seems that "OpenJDK" refers to a specification and/or working group which NO LONGER provides a build, instead relying on vendors to do so, and indeed the vendors have wide latitude about how they license it.
This is genuinely complicated, I'm not a lawyer or a software license expert, and I don't understand it. And honestly, based on some of the haughty and arrogant, but factually wrong, comments I've been seeing, I suspect that a lot of people think they understand it, but don't.
Which is exactly your point! The uncertainty/confusion is now super high due to Oracle's actions. It's literally fear, uncertainty, and doubt.
It's a bit like GPL and other open source licensing in the early days ("better not touch GPL code at all") rather than the now commonplace "Ahh, yes. No to AGPL, but GPL is fine since we won't distribute it. We'd prefer APL" practices.
I absolutely believe that experts in licensing understand the OpenJDK / Corretto / Microsoft's OpenJDK distro and so on. But it really did go from "yeah, openjdk is no problem" to "hmm, do we understand this?".
> "OpenJDK" used to be an independent group who's purpose was to build a fully open-source Java - and it was Apache licensed.
You've confused OpenJDK with Apache Harmony. The Harmony project dissolved in 2011, essentially being killed by IBM's decision to join the OpenJDK project instead.
OpenJDK: "Oracle’s free, GPL-licensed, production-ready OpenJDK" I don't know what could be more convincing than an explicit open license.
The Oracle License FAQ is scary and opaque.
https://www.oracle.com/za/java/technologies/javase/jdk-faqs....
This FAQ is about Java SE builds, not the OpenJDK builds.
Java is Still Free (2019) https://medium.com/@javachampions/java-is-still-free-2-0-0-6...
I don't know if there is a more recent version
It is, I definitely agree, but the statement I quoted is pretty darn straight-forward.
But it's also wrong. Is there any legal precedent establishing what the "GPL with classpath exception" even means? Does each build of the OpenJDK come with it's own license?
https://softwareengineering.stackexchange.com/questions/1194...
> OpenJDK: "Oracle’s free, GPL-licensed, production-ready OpenJDK" I don't know what could be more convincing than an explicit open license.
lack of enterprise support.
And also what javajosh said. Here's a(n arguably biased) corroboration: https://www.mondaq.com/unitedstates/corporate-and-company-la...
> lack of enterprise support.
You don't get that with Java 8 either, unless you are willing to pay for it. In that case, what's the difference between paying Oracle for support for Java 8 and newer releases?
what does enterprise support mean in context of a programming language?
It means having a service that you can contact with questions about the platform. For example, if you're having a weird GC problem you can pay Red Hat $300/hr to have a presumed expert (ideally a committer to OpenJDK) look at it with you and help you solve it. There may also be variants of this where you "subscribe" and get a certain number of support hours.
I'm curious if there is really a strong need for this service. What kinds of problems is a company solving and at what scale, that they need to have dedicated support with the language?
Suing Google for a billion dollars makes people irrationally nervous.
Just sign the license and agree to all the terms and conditions. Nothing will go wrong.
So when will Android Java be proper Java?
Java and the OpenJDK have become more free than it was before, just don't use the OracleJDK if you don't like their commercial license. Instead use the OpenJDK.
Exactly. There is zero technical reason to use the Oracle JDK. OpenJDK licensing is GPLv2 with the classpath exception. Nice and simple. If you want to get your arm twisted and pay more, Oracle indeed provides you that option. You can also get a nice linux distribution from them and a database. And companies actually exist that buy all those things from them.
But for the rest of the world, you can also get certified JDKs from Azul, Amazon, Red Hat and a few others. All fine choices. Pretty much the entire financial industry, including some of the most conservative companies on the planet, depends on Java and I doubt most of them are paying Oracle for that. Why would they?
Perhaps point out how many non-Oracle commercial JVM vendors exist? They might not trust Oracle to be sane, but Red Hat, Microsoft, SAP and Amazon are all very big names in the industry who offer their own JDK distributions, some of them also offer commercial support.
Do you know what the legal relationship is between Red Hat and Oracle is? I think Oracle v Google has sent shivers of fear through anyone wanting to rely on Java, including through an intermediate, because the strength of the relationship is only as strong as the weakest link in the chain. In other words, what is the risk that Red Hat will be sued by Oracle someday over their use and support of Java?
Sun and Oracle have only sued those that went out of their way to create their own Java flavours, namely J++ and Android Java.
The Java ecosystem is just like C and C++, full of alternative, compliant implementations.
Microsoft learnt their lesson and is now an OpenJDK contributor.
So when will Google stop cherry picking OpenJDK features and actually support proper Java on Android?
Let’s say Oracle sues Red Hat (now IBM), so what? Are android devs all totally screwed because Oracle sued Google?
I’m not going to defend Oracle’s business practices but this seems like FUD. You can use Red Hat, Amazon, or Azul’s jvm. If it’s too “scary” to do so for your company than you need better executives and/or lawyers.
> If it’s too “scary” to do so for your company than you need better executives and/or lawyers.
That is the point though. It's sort of obvious if you read through the terms. But if you're at a company that is already afraid of words like GPL, the JDK is "now" also scary.
At the same time, even if your legal department are scared of Oracle (and really just stories of "I heard Oracle sued Google"), I claim that the Corretto docs (and similar) are quite clear.
But if you're at a company that is already afraid of words like GPL, the JDK is "now" also scary.
These companies either only develop software peripherally to their business, in which case sticking with java 8 is probably going to be fine, if silly, or they are the walking dead.
Java is GPL2+Classpath Exception licensed.
Google perverted Java. That's what Oracle sued Google for. And that's what Sun sued Microsoft for decades ago. Red Hat is not trying to turn Java into something different, it just builds and supports existing OpenJDK codebase. It's absolutely different thing.
Yeah, where did all those from anti-J++ cheering crowd went?
The licensing around post-8 JVMs is neither confusing nor scary. If you're confused or scared by it, that is entirely on you, i'm afraid.
Great, then explain it.
It's GPL 2, with an exception which lets you distribute binaries containing your own code linked to the JDK without having to provide the source to your own code (see '"CLASSPATH" EXCEPTION TO THE GPL' at the end):
https://github.com/openjdk/jdk/blob/master/LICENSE
This is substantially the same as the GCC Runtime Library Exception, which lets you distribute GCC-compiled binaries linked to the GCC runtime without having to provide the source.
That's it.
Thanks. During this discussion I found the OpenJDK source code, cloned the repo, and build a fully-functional JDK [1]. Presumably the license forces me to share modifications to the JDK code itself, but not to any application I run on the JDK.
If I wanted to distribute my JDK (I don't, BTW) what limits are there? Do I need to get certified? Run compatibility tests? Pay a fee to Oracle? Or do I just need to plop a binary on Github or S3 and call it a day?
Changing companies led me from C# to Java. I feel so much less productive in Java, so much extra boilerplate everywhere. C# is just as mainstream as Java, so learning curves and nicheness arguments don't apply, it's just better.
I wonder if MSFT will ever make C# run on JVM.
> C# is just as mainstream as Java, so learning curves and nicheness arguments don't apply, it's just better.
Java has way more web framworks from what I've seen (could be a good or bad thing), and more alternative languages that you can pick from.
That's basically how C# came into being in the first place. Microsoft "bought" Anders Hejlsberg of Borland Delphi fame, and had him create a "better Java". And IMHO Visual J++ was a much superior Java, with a visual designer that was much more advanced than anything else available back then. The problem? It was very much Windows Only (tm) if you wanted to use the advanced features. Sun was not happy about this. And the end result of the legal struggle was that Microsoft used Visual J++ as a base for C# and scrapped Java compatibility.
Only if they want to cripple C#, as the JVM isn't able to support all the C++ like features from C#.
It would still make sense, as long as when coding in the "crippled" C# one can still take advantage of the entire Java ecosystem.
You already have IKVM for that, with various degrees of success depending on the library.
C# was designed in a way that makes it very hard to run on the JVM in a performant way. It has slightly different scope behaviors, slightly different asthmatics etc. Source: worked on a JVM running on C# which was hard, I think the reverse is even harder.
It might be easier these days with GraalVM/Truffle. You wouldn't run C# directly, you'd implement CIL in a Truffle interpreter, so you bypass JVM bytecode and its semantics entirely.
There’s IKVM for running Java libraries in .NET.
1 -
I just do some Clojure programming, and I'm not deep into JVM things - but why does Android not even make a mention? Isn't it the most widely used JVM platform..?
2 -
> This does come with some restrictions and caveats; for example, it's not as straightforward to use Reflection in your Java code.
Is GraalVM going to push Reflections out of Java/JVM?
I guess my angle is I'd like to use the JVM to make (desktop) apps. Last I did, using cljfx/JavaFX reflections were a huge sore point. Ever dependency would drag in the whole kitchen sink - and reflections are an ugly wart that prevent unused classes/namespaces from being pruned.
I know technically there is Proguard.. but it's clunky and ugly I've never gotten it to work with Clojure. Graal native looked like a sort of light at the end of the tunnel.
3-
Whats the story with WASM and the JVM? Both designs seem eerily similar - but I don't know if the gap between the two is too large to bridge
Well, dynamic languages like Clojure and static analysis like ProGuard will never mix that well. The module system helps though. You can get rid of the parts of the JDK you don't need.
I very much doubt reflection is going anywhere. For one, GraalVM native images support reflection, you just have to state ahead of time what you plan to reflect over.
WASM+JVM works. You can run WASM on top of the JVM. There's a Truffle interpreter for it, which means WASM code gets JITCd by the JVM itself and you can interop in and out. Check out GraalWASM.
Right, you can trim the JDK - that's true but I think the "problem" is a bit more general. I'll give you a more concrete example. I have some small application and it needed to do some basic image manipulation. So I bring in BoofCV and do the manipulation. However I then see that BoofCV drags in all sorts of crazy stuff to do with machine learning and whatnot - along with a sea of irrelevant dependencies
- I can keep around the bloat
- I can try to find an 3rd tier library with less eyeballs that's smaller and does less (If I later want to do more image manipulation I might find myself in a bind)
- I can try to manually go in and trim out the stuff I think I'm not using (not that I really understand the BoofCV internals..)
So the ecosystem is actively discourages me from using large mature libraries :( (I ended up using option 3 with trial and error)
Graal maybe sidesteps the issue. Yeah it has reflections, but as you say you need to be explicit about them. So the rest can be trimmed.
I guess my original loaded question was implying that maybe this will make library developers more keen on dropping reflections internally (it's honestly almost never a good design choice anyway)
That all being said.. I think 90% of people are writing some server-side web stuff and none of this matters to them :)
> GraalWASM
I'm kinda curious about the other way around. Running JVM byte code on WASM. Not in any serious way.. but it'd be cool you could run an uberjar in the browser. A quick search brings up a few ongoing projects :)
Right. If you're very sensitive to download time then you want to trim unused code as much as possible, or dynamically page it in.
Afaik, android has its own VM. It compiles Java the language into bytecode for that VM. Android didn't even include the standard Java library, instead providing its own.
Android is not a JVM platform. Android uses Dalvik as VM.
Dalvik was replaced by ART nearly seven years ago.
Sorry, just wanted to make the point that it is not JVM. Wasn't in Android dev since some years it seems ;)
This was a great read! Think I might pick up Kotlin
Boy JDK really accelerated their releases in recent years did they. 6 years ago when I've just graduated, Java 9 was around the corner.
Java is not expressive enough to do without reflection for some complex problems. I suppose you might resort to code generation instead?
> Build tools such as Maven and Gradle are fast, stable and effective
Exactly the opposite of what comes to mind when I think of these.
Gradle is not fast. I want to pull my teeth out every time IntelliJ decides to launch my application through Gradle rather than via the IDE directly because of the added boot time.
Maven is quite stable and effective - maven pom's can remain unchanged for years and still build. However it is not fast.
Alternative way to count the vowels in Kotlin:
val numVowels = countVowels(getDTO()?.string ?: "")Or alternatively, closer to the original, doing both null checks the same way the original does the first one:
val numVowels = getDTO()?.string?.let(::countVowels) ?: 0
Overall, good, but I quibble in favor of Kotlin with a couple of points:
> Building large teams (think hundreds or thousands of developers) requires talent, and talent is easier to find if more people know the language (although, if you want the absolute best people, you might be better off choosing a more niche language).
It's very easy to hire good Java devs and crosstrain them to Kotlin.
> Java also arguably has the best tooling in the business. I'd argue that IntelliJ IDEA (and family) is the best IDE out there, more so if you are coding Java. Even if you prefer VS Code, Java is well supported.
Jetbrains of course make Kotlin also, and theoretically their Kotlin IDE support will be better than Java's once they complete the mainlining of the Kotlin plugin into the IDE code base. (Right now the Kotlin plugin has recurrent stability issues.)