5 ms·
I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape
by azalemeth 5y ago
I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape or form!
I am not a Java developer. I am one of those users who has a bad memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, and had example "Hello Worlds" that are reminiscent of Enterprise FizzBuzz [1]. At some point in the last 20 years, Java has gone the other way -- it has a reputation (I think) of being "boring", "performant" and used by businesses for doing server-side logic. Still, the only way I interact with it is with the occasional dependency install.
I've noticed:
-- There are a bunch of different JREs/JDKs, most famously Sun's/Oracle's own Java, OpenJDK, OpenJDK built by Other People™, and Random Other JDKs (Azul; Amazon Corretto).
-- People rail against Sun/Oracle and what happened to Java.
-- For a bloody long time I had to download the JDK separately and/or type in "agree" into a very un-friendly sounding license at the command line.
Can I therefore ask the HN meta-brain to either explain, or point me to a reference that explains:
-- What the ideological and practical differences are between the JDKs
-- Why there are different JDKs -- I get that that it's good to have different language implementations, but there are really quite a lot!
-- What Oracle did
-- And what was the beef with the whole open-source license was. Isn't opener-better?
Thank you!
[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- kjeetgill 5y agoFor the most part, the various JDKs not really different. They're builds of the same OpenJDK repo. They occasionally have a few small changes, maybe with a few extra bugfixes new or a backported. The one small difference between compiling it yourself is that Oracle does control the TCK, a test suite for the binaries that Azul and others might use but not open to you.
- slowmotiony 5y agoI've got a task at work to install Oracle WebLogic and migrate a legacy app from an older OAS instance. The Weblogic installer didn't even run on OpenJDK, it specifically checked for it and crashed with a "OpenJDK builds are not supported" error. No idea why that is since I read everywhere that they're essentially the same thing.
- rowland66 5y agoI believe that when you license Weblogic from Oracle, the Weblogic license includes a license for the Oracle JVM it runs on. So there is no reason to run Weblogic on another JDK/JVM. I assume that Oracle requires their JDK/JVM for Weblogic to keep support simpler.
- 20210911 5y agoJava is set of specs from https://jcp.org https://jcp.org, Implemented by various parties, IBM J9, Sun(Oracle) HotSpot, BEA Systems(Oracle) JRockit are I know of. Sun open source HotSpot as OpenJDK, Then Oracle merged some code from JRockit, IBM also joined some in to OpenJDK, after shit with https://harmony.apache.org https://harmony.apache.org , OpenJDK is GPL, Oracle provides compiled version, but there are issues with it's license and long term support, You have to pay for long term support to Oracle, Some product are there still running on JDK 1.4 Since OpenJDK is GPL Redhat provide compiled version for redhat linux called IcedTea, Eclipse foundation provide adoptium, and there are commercial support providers like Azul
- krzyk 5y agoopenjdk compik3d version is gpl eith classpath exception. so one can use it in production enterprise apps
- the8472 5y ago> What the ideological and practical differences are between the JDKs The builds may ship with different optional features enabled, such as various garbage collectors or I think support for the GraalVM stuff. Support terms differ. > Why there are different JDKs -- I get that that it's good to have different language implementations, but there are really quite a lot! Most of what you will get these days are just different builds of the OpenJDK class library + tools + Hotspot (JVM). Well, except for the android runtime, but we don't talk about that one. Historically there have been been more JVMs and class libraries but that has been consolidated a lot since oracle opensourced it. There still is OpenJ9 and some smaller, more specialized ones.
- whartung 5y agoFor a while, there were some nitty, edge case, "UFO" types of differences between OpenJDK and the Oracle JDK. But that's mostly been resolved. Oracle owns "Java", that is the name, the trademark, etc. In that sense, OpenJDK is "not" "Java". But operationally, this is moot. But it has impact in other areas. What was originally "Java Enterprise Edition" was transferred over to the Eclipse Foundation, but they couldn't take the "java" name with them. All of the JEE packages were "javax.enterprise.". Oracle wouldn't give up the "Java" part in order to not dilute its trademark, so now its the "Jakarta Enterprise Edition", and all of the packages are being renamed to "jakarta.enterprise.". I mention this just as an example of the hoops the community going through, even today, over what's happening with java. So, Oracle and the community have to dance a fine line over what is the language, compilers, tools, and libraries, and what is "java", what is trademarked, what is owned by Oracle. Oracle was kind enough to be an invested member in the Java community by not forking, closing, and going off its own way, and leaving the OpenJDK to fend for itself. This is essentially what happened to Solaris and OpenSolaris. The other JDKs (Zuul, AWS, etc.) were certainly a hedge against this. The industry has a lot invested in "java", and can't really afford to let it get out of hand. Having "official" builds, that were supported, and patched, and eyes on vs the latest release from OpenJDK gives companies a secure feeling. That's why other companies stepped up to support their own JDKs. To help assure clients that the technology is stable and still worth building on. So, the differences are not so much different languages, or even different implementations (though there is certainly some of that). Rather much of it is simply stability in the community. Also, the whole licensing issue with Oracle vs the others was a big deal also. We'll see what impact the new free license from Oracle has.
- sebazzz 5y ago> All of the JEE packages were "javax.enterprise.". Oracle wouldn't give up the "Java" part in order to not dilute its trademark, so now its the "Jakarta Enterprise Edition", and all of the packages are being renamed to "jakarta.enterprise.". I mention this just as an example of the hoops the community going through, even today, over what's happening with java. That is quite a change, and probably not very backwards compatible?
- 5y ago
- matsemann 5y ago> memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, Note that the horrible end user experience of running java programs (or java plug-ins in the browser) back in the day, never was indicative at all of how it's for running on servers and those kind of workloads. The stuff I've written in java for backends have been blazingly fast (compared to python for instance) and with much better tooling. So devs choose java/jvm because it works well, despite some shortcomings in some areas. Btw, I think you'd find today's java desktop apps to be snappier than you'd think (especially compared to electron for instance). Bundling the jvm removes the hassle of having to install something separate and version issues. And AOT compilation and the new modularity of the stdlib makes the files smaller and quicker to load.