Earlier quoted context omitted.
> I would rather use Go, which seems to have all that Java has to offer Really ? What is the Go equivalent of J2EE ? Do Go appservers exist that offer all the features that something like Payara (Glassfish), JBoss or WebSphere does ?
What is the Go equivalent of J2EE? 無
Oracle’s Java 11 trap
211–220 of 244 posts
Re: Oracle’s Java 11 trap
#212Earlier quoted context omitted.
I get your point, but npm has the same issue even if you didn't accept the license. I mean, if you didn't accept the license that it comes with, then what license gives you a right to use it at all?
IMO, there's an argument that you implicitly license others in making your code available in a package manager such as NPM which requires no authentication or license clickthrough to incorporate code in your project, unlike the .net or other PMs where license terms are presented and require click-through agreement. Not saying anyone should stake any bets on that argument winning, just that it wouldn't likely be summa…
Re: Oracle’s Java 11 trap
#213Earlier quoted context omitted.
go ahead and try building a sufficiently large project written in java 6 on the java 9 jdk and tell me how backward compatible it is. Go ahead, I'll wait.
Maybe you can point us towards which parts would break compatibility. Go ahead, I'll wait.
Back in college, I created a small desktop app that played a WAV file when any key was pressed, but could be closed silently with the mouse. (Its purpose, along with a recording of me screaming, was to train my cats not to sleep on my laptop.) It would have been written in Java 1.4 or maybe 1.3. The applet library was a pretty standard way to open and play an audio file, because it was simple.
Fast forward a few years, I came across the app again and decided to see if it still worked. It didn't work with the existing JRE on my box. So I rebuilt it with a more recent JDK (1.6, I think). It built, but it still didn't work.
See, Java 1.5 AKA "Java 2" had a new memory model, deprecated a lot of things (like applets), and started modernizing heavily. They attempted to maintain backward compatibility, giving us things like the awful erasure-based generics, but it really wasn't fully BC. They really should have just done what Python did with Python 3 and make Java 2.0 non-BC.
This isn't an isolated incident, either. A major project I worked on updated from Java 1.6 to 1.7 and it broke several things. They were fixed pretty quickly, but it still wasn't truly backwards compatible. It's just like the Java claim that you can write once and run anywhere, which is only half-jokingly referred to by devs as "write once, debug everywhere".
Re: Oracle’s Java 11 trap
#214This is going to come off sounding a bit like victim blaming, but seriously, any business large or small must have a person or people whose responsibility it is to audit all installed software so that nobody gets into a situation such as described in the article. A business cant afford to let devs just install software willy-nilly like.
Yet "willy-nilly" installations happen. It remains to be seen whether they'll "go after" the whales who can actually afford compliance staff (but screwed up anyway), or after the small-fish companies that just stood up a web-app to get started, or businesses in between.
I aware they're often the same folks (DevOps), but your senior engineer and/or project manager should be watching what's going out.
Re: Oracle’s Java 11 trap
#215Currently happy about Azul OpenJDK.
'Zulu', right? What's their angle?
I guess they later figured it could be more generally useful and they could sell support for it.
Re: Oracle’s Java 11 trap
#216Earlier quoted context omitted.
And that's good that package managers ship only openjdk. When I migrated to Linux I didn't know better but as "openjdk" was easier to install than Oracle JDK I used "openjdk". It turns out it works very well, actually I can't tell the difference.
Unfortunately, many people add a repository with Oracle JDK to their package managers and install the JDK from there, due to some perceived better compatibility and/or extra bug fixes. (And in my experience, this is true for the Java plugin; the "official" plugin seems to work better than the IcedTea plugin.)
It is a reason why we moved to .net core entirely. I have nothing running Java anymore. Shame as I liked Clojure somewhat.
Re: Oracle’s Java 11 trap
#217Earlier quoted context omitted.
Modified openjdk with high perf. GC, JIT, tooling etc. It is very nice.
Zing and Zulu are not the same. Zing is a commercial JVM that has no open source equivalent, and has a completely bespoke design from my understanding -- calling Zing a "modified openjdk" is a stretch, from what I understand (especially considering OpenJDK is GPLv2.) Zulu is Azul's build of open-source OpenJDK, and no different than any other OpenJDK such as one from jdk.net or AdoptOpenJDK -- it doesn't have a speci…
Re: Oracle’s Java 11 trap
#218Earlier quoted context omitted.
And that's good that package managers ship only openjdk. When I migrated to Linux I didn't know better but as "openjdk" was easier to install than Oracle JDK I used "openjdk". It turns out it works very well, actually I can't tell the difference.
OpenJDK is the reference implementation now so if you did find a functional difference, Oracle is in error.
Re: Oracle’s Java 11 trap
#219Earlier quoted context omitted.
Confluence is an example of a piece of software that wouldn't run correctly at all under OpenJDK. Even today on the Atlasian docs, they provide a Docker image of Confluence to evaluate, but if you buy a production license, you are required to build an OracleJRE Docker container (they provide instructions) for production. It's been years and they still can't support OpenJDK ... it makes me wonder what weird proprietar…
Last time I tried to run Jira with OpenJDK, I stumbled upon some encryption algorithm not supported in OpenJDK. I didn't research further. But that was a long time ago, nowadays I bet that OpenJDK will work just as well.
Re: Oracle’s Java 11 trap
#220Earlier quoted context omitted.
We used the same argument a decade ago with Perl, look where that got us. Java in 2018 is Perl in 2008, roughly.
Actually I never used this argument for Perl. Perl was not really used for things like big data or high performance backend applications. You can use this reasoning for C++ or C# on the other hand and it stands. Many "big data" things re in C++ and a lot of high performance projects out there. If you want to compare nifty scripting languages than you can compare Perl with Ruby or Python. In 2008 I was happily using R…
Perhaps even compare with Perl 6 :-)