question about Java
Joseph Sinclair
plug-discussion at stcaz.net
Tue May 5 18:08:05 MST 2020
Ed, thanks for correcting me. OpenJDK is GPLv2 with classpath, not GPLv3 as I had asserted earlier.
TL;DR: The technology isn't what makes (most) systems good or bad, the engineering is.
I like, and work with, Java, Javascript, Python, Go (granted, the style guide there is unpleasant), and C++. I've even held my nose and worked on .net code a couple times.
I am familiar with several other options and toolsets (and really like some that just aren't quite popular enough for enterprise use, like Scala).
I've seen good engineering in most technologies, and bad engineering in all of them.
I've been creating systems with Java for a rather long time. The only versions of OpenJDK I ever had issues with were 5 and 6, which lacked a couple of items that were closed-source and had to be replaced (in version 7 they were replaced with open re-implementations).
I've seen some code, written objectively incorrectly, that depends on internal API's of the JVM and, technically, violates the license terms as those classes are specifically called out as not licensed for use. That software won't move from version to version well, or at all, because it's using internal details instead of published APIs.
I've also excoriated more than a few lazy-bum (I'm being extremely kind here) "programmers" who insist on using those internal API's because they cannot be bothered to take 10 minutes and look up the standard API equivalent (or bring in a common library for that functionality).
I've worked on a LOT of Java code, and while it's far from the only language I use (I currently work with 3 *regularly* at work), it's one of the most productive for me and most of my teams.
For modern cloud-native systems it's one of the best options in many situations. (although, please don't mention the abomination called Springboot; that's the real zombie godzilla that needs to die).
None of this is to say Java is somehow superior to all comers. More this highlights that good engineering is far more important than the language or platform in most cases, and that even for the same language bad engineering or a bad platform choice can make a huge difference.
BTW, lest you think compatibility only works in demonstrations, I ran a test, just for funsies, on all 18 microservices we have in production to run these Java 8 or 11 systems on Java 14 (pipeline builds help here) and loaded them in dev containers to check compatibility. None had any issues at all. If we didn't have policy limitations to LTS versions, I'd probably upgrade them all to 14 in production, as it does improve several performance metrics by a bit.
Yes, there is a lot of lousy engineering in enterprise, but it doesn't matter what platform you pick. Bad engineering happens, and tends to stick around a long time because it costs too much to redo. That doesn't mean the foundational technologies are good or bad, only that the use of them was.
P.S.
I just took a quick look at JBidwatcher, I've seen worse code, but only in contests to write bad code. That thing may meet a valuable need for people, but it is truly terrible from an engineering design standpoint, I'm not even a little surprised it is tied to very specific VM builds.
It uses internal JVM classes all over the place, even when there are better choices in the standard library. It's almost like they designed it deliberately to prevent portability.
On 2020-05-05 08:01 AM, Michael Butash via PLUG-discuss wrote:
> I'll stand corrected with the versions of java, it's obviously not my
> thing, but simply put, I've never *ever* had openjdk work properly for
> anything Java that wasn't specifically built in openjdk. I just don't
> bother with it usually as most everything is typically built/tested around
> Oracle and Oracle only.
>
> This proved itself true last week firing up JBidwatcher on this system,
> only had openjdk, and wouldn't even launch with it. I had to put oracle
> java on it to work still.
>
> Most enterprise java apps I have seen in use in businesses require
> specific, usually outdated/insecure versions, never get updates because
> they break the apps, and rarely work on anything but the platforms they
> were built on, so I call bullocks on the compatibility play. It sounds
> great in theory, but every practical application I've seen in use in
> enterprise ended up a bloody mess.
>
> Much like Flash now, it's just a zombie that won't die, but should imho.
>
> -mb
>
>
> On Mon, May 4, 2020 at 10:33 PM Joseph Sinclair via PLUG-discuss <
> plug-discuss at lists.phxlinux.org> wrote:
>
>> Sorry, Michael, but this is complete bunk.
>>
>> On 2020-05-04 11:29 AM, Michael Butash via PLUG-discuss wrote:
>>> Again OpenJDK and OracleJRE are totally different - including version
>>> numbers. If someone says "works with Java 8", they 99.9% of the time
>> mean
>>> OracleJRE and their versions, and theirs only.
>>
>> Oracle JRE or JDK is a repackaged OpenJDK build, and nothing more. The
>> version numbers are identical. The code is identical. The build process
>> is identical. The only thing you get with Oracle builds is the *option* to
>> pay for Oracle commercial support.
>> In fact, any package in any Linux distro labeled OpenJDK is generally a
>> packaging of the Oracle build, which is why OpenJDK 8 builds are no longer
>> available easily, as Oracle pulled Java 8 to commercial-only support last
>> year.
>>
>>>
>>> OpenJDK is only ever used with, well, I don't even know anymore, as
>>> everyone Open Source moved on to hate Java, Oracle, Larry Ellison, etc.
>> OpenJDK is, and has always been Open under GPL3
>> If you want fully open and community (or commercial from not-Oracle)
>> builds of any recent Java version (8+) you can get those from
>> adoptopenjdk.org, which is a consortium of large and small companies that
>> are supporting continued open access to the GPL3 source code and builds of
>> the Java system.
>> A huge amount of the internet is running OpenJDK, and a vast array of
>> systems are transitioning to the adoptopenjdk builds simply to ensure
>> continued access to support from multiple vendors.
>>
>>> You can pretty safely remove/forget OpenJDK as an end-user at this point
>> I
>>> think, unless something specifically mentions needing it.
>> If you're running Linux, and you need Java, you should be installing the
>> OpenJDK package from your distribution, if nothing else to ensure continued
>> and frequent updates along with the rest of the system.
>> If there is an option for adoptopenjdk for those packages, that's a good
>> choice, but the builds from the distribution for Java are made from the
>> official codebase that underpins all builds, including Oracle's.
>>
>>>
>>> -mb
>>>
>>
>> Joseph Sinclair
>>
>>>
>>> On Mon, May 4, 2020 at 11:24 AM Michael <bmike1 at gmail.com> wrote:
>>>
>>>> Thanks for the tip!
>>>> So then looking at it it looks as if I have Java 11 installed. Is that
>>>> correct?
>>>>
>>>> apt search oracle jre
>>>> ...
>>>> i openjdk-11-jre - OpenJDK
>>>> Java runtime, using Hotspot JIT
>>>> p openjdk-11-jre:i386 - OpenJDK
>>>> Java runtime, using Hotspot JIT
>>>> p openjdk-11-jre-dcevm - Alternative
>>>> VM for OpenJDK 11 with enhanced class redefinition
>>>> p openjdk-11-jre-dcevm:i386 - Alternative
>>>> VM for OpenJDK 11 with enhanced class redefinition
>>>> i openjdk-11-jre-headless - OpenJDK
>>>> Java runtime, using Hotspot JIT (headless)
>>>> p openjdk-11-jre-headless:i386 - OpenJDK
>>>> Java runtime, using Hotspot JIT (headless)
>>>> p openjdk-11-jre-zero - Alternative
>>>> JVM for OpenJDK, using Zero
>>>> p openjdk-11-jre-zero:i386 - Alternative
>>>> JVM for OpenJDK, using Zero
>>>> p openjdk-8-jre - OpenJDK
>>>> Java runtime, using Hotspot JIT
>>>> p openjdk-8-jre:i386 - OpenJDK
>>>> Java runtime, using Hotspot JIT
>>>> p openjdk-8-jre-dcevm - Alternative
>>>> VM for OpenJDK 8 with enhanced class redefinition
>>>> p openjdk-8-jre-dcevm:i386 - Alternative
>>>> VM for OpenJDK 8 with enhanced class redefinition
>>>> p openjdk-8-jre-headless - OpenJDK
>>>> Java runtime, using Hotspot JIT (headless)
>>>> p openjdk-8-jre-headless:i386 - OpenJDK
>>>> Java runtime, using Hotspot JIT (headless)
>>>> p openjdk-8-jre-zero - Alternative
>>>> JVM for OpenJDK, using Zero/Shark
>>>> p openjdk-8-jre-zero:i386 - Alternative
>>>> JVM for OpenJDK, using Zero/Shark
>>>> p spamoracle - statistical
>>>> analysis spam filter based on Bayes' formula
>>>> p spamoracle:i386 - statistical
>>>> analysis spam filter based on Bayes' formula
>>>> v spamoracle-byte -
>>>> v spamoracle-byte:i386 -
>>>>
>>>> On Mon, May 4, 2020 at 2:12 PM Michael Butash <michael at butash.net>
>> wrote:
>>>>>
>>>>> OpenJDK and Oracle JRE are two very different beasts. Most java
>>>> software is developed against Oracle Java, and if so, rarely I find they
>>>> ever work on OpenJDK.
>>>>>
>>>>> Look up switching to "oracle jre" on your system, Java 8 as they want.
>>>> I had to figure this out on my arch system recently, ubuntu should just
>>>> have to install it, and switch the system to use it, just forget how
>> now.
>>>> If nothing else, start with "apt search oracle jre".
>>>>>
>>>>> Nothing Java ever amounts to any good I've found after ~20 years of it,
>>>> I try to use Java as little as possible, scorning any software and
>> hardware
>>>> (ahem, Cisco) that uses it still. Anything Java behaves badly under
>> linux
>>>> for me, and the only thing java app I suffer is JBidwatcher for ebay
>>>> sniping deals. It behaves badly, randomly, but still the only darn
>> thing I
>>>> can find like it free.
>>>>>
>>>>> -mb
>>>>>
>>>>>
>>>>> On Mon, May 4, 2020 at 9:50 AM Michael via PLUG-discuss <
>>>> plug-discuss at lists.phxlinux.org> wrote:
>>>>>>
>>>>>> I want to download a program, ImageJ. I went to the download page and
>>>> see:
>>>>>>
>>>>>> Unfortunately, due to the ongoing transition from Java 6 to Java 8,
>>>>>> this download of "plain ImageJ2" cannot currently be updated to the
>>>>>> latest Java-8-compatible version. See the Java 8 page for details. For
>>>>>> the time being, we recommend using the Fiji distribution of ImageJ to
>>>>>> stay current with updates.
>>>>>>
>>>>>> Curious as to what version of Java I have....
>>>>>>
>>>>>> ~$ java -version
>>>>>> openjdk version "11.0.7" 2020-04-14
>>>>>> OpenJDK Runtime Environment (build
>> 11.0.7+10-post-Ubuntu-2ubuntu218.04)
>>>>>> OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-2ubuntu218.04,
>>>>>> mixed mode, sharing)
>>>>>>
>>>>>> So they are a bit behind?
>>>>>> --
>>>>>> :-)~MIKE~(-:
>>>>>> ---------------------------------------------------
>>>>>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>>>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>>
>>>>
>>>>
>>>> --
>>>> :-)~MIKE~(-:
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20200505/328d5bae/attachment.sig>
More information about the PLUG-discuss
mailing list