I'll freely admit that I'm not a developer, but as someone that has to work
around enterprise apps, despite their language developed in, I tend to see
their faults in unique ways. Often as some developer blaming my network,
or a firewall for their app not working, or crashing regularly, or
whatever, it's just always someone unable to fix their software through
conventional development and want a band-aid. Whether it's Java, .Net,
whatever, a lot of it comes down to folks not understanding how to network,
performance-tune, and secure their applications as that is someone else's
problem. I have met really good devs across the years, but I meet far more
hacks.
When I think Java, I think of usually multiple experiences involving some
"integrator", usually offshore, usually still huge budgets, throwing a lot
of clueless people at the effort that we later find have no idea how the
products even work. They end up over budget, over deadline,
under-featured, and generally indefinitely incomplete. I could start
naming names, but the companies, integrators or customers, might not
appreciate it. Few companies want to invest in proper internal dev teams,
thinking they'll save in contracting/outsourcing, but never do - the
outsources never go away, they tend to just hang on like a leach and bleed
them in perpetuity.
I run into a lot of crap networks too, small and large, which I take
offense to as my thing, but make a career of cleaning them up/migrating
anyways. I don't always get the time or budget to do right either, end up
polishing an already sold turd, and running in the other direction when
done. I'm certain inheriting code this comes up a lot too.
And yes, JBidwatcher I tend to feel is crap. I'm no one to judge their
code, but as a regular user, it literally acts randomly at times, often
corrupting its own database, behaving poorly across multiple monitors,
etc. Perhaps a bad standard, but it's the only thing I use that is java
anymore, purposely. There literally is no replacement for it I know of
that is linux-friendly, or not a (paid subscription) web service.
Perhaps you java gurus should refactor or clone JBidwatcher - I'd pay for
it to see it just work properly, and hasn't been updated in forever. I
tend to use it to buy lab gear like $40k arista switches for a few hundred
bucks when they come off-lease in auctions, or other technology bits I
search for like firewalls or 40/100gb nics to test. No profit for me,
other than keeping skills fresh or random customer testing of platforms,
and I don't always need it, so I really don't like subscription services.
I'm sure there are ebay flippers buying low, selling high all day that use
something like it, if not it, and hating it all day too.
-mb
On Tue, May 5, 2020 at 6:08 PM Joseph Sinclair via PLUG-discuss <
plug-discuss@lists.phxlinux.org> wrote:
> 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@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@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@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@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@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@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@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@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@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@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)