[NTLUG:Discuss] I hate IcedTea

[Stephen Davidson]

Hi Chris.

Responses inlined from a guy who has been making his living with Java
for over a decade now.

Regards,
Steve

On 06/06/2013 12:07 AM, Christopher Cox wrote:
> On 06/04/2013 12:57 AM, Leroy Tennison wrote:
>> <Rant> I understand the desire for open source alternatives to proprietary
>> technology but they have to work...  A recent OpenSuse update stopped a working
>> IcedTea configuration to my corporate network and I really need that connection
>> right now. </Rant>
> Java, even from Sunoracle is a HUGE roll of the die.
>
> In fact, just mentioning Oracle should send chills down your spine.  While I
> realize that there is a vast majority of people and systems out there that are
> Java dependent, that doesn't make the risk any less in my book.
More are Oracle DB dependent than Oracle/Sun JDK dependent.
>
> In fact, your example sort of proves the point.
>
> So, beware of anything Java.  It might not work tomorrow.  If you keep that in
> mind, you'll probably be ok.
I would be much more concerned about Oracle DB.  There is no Governing
Community on that -- just Oracle Engineers that don't need to publish
anything externally.
> Java never really delivered on the promise that arguably makes it so popular
> today.  The idea of a cross platform execution environment.  With Java, you
> can't even say that what you create today, using "official" classes will work
> with the next minor release of Java (and I'm talking about the sub-sub release
> level).... and that's on the SAME platform, much less across platforms.
I would be interested in knowing where you have had problems, this has
not been my experience.  Most teams I've dealt develop on some version
of MS (sometimes multiple), then deploy to a Unix or Linux server system
(often times w/o a recompile).
> Also, Java is a full execution environment (because of its desired goal of being
> truly cross platform) which means that it cannot benefit from OS and/or platform
> specifics in many circumstances, which means it's weighty because it has to
> reinvent many things that are commonplace on good OS's.
True in early versions (pre JDK 1.3, pre 2005).  Starting in 2000-2005
timeframe, the JVMs for individual platforms started getting platform
specific optimizations.  Today, a large chunk of that "overhead" in the
JVM includes some additional compilers, profilers, and runtime
optimizers.  Today, class files are compiled down to machine specific
machine code by the JVM.  This includes the use of machine specific
registers where appropriate.
> Thus when a major problem happens in a core OS library, there are times when
> there will have to be a major corresponding patch to Java as well.
>
> In a two OS world, which it's pretty much become... these problems with Java
> make it less and less desirable.  Arguably, on the more important server (e.g.
> services) side of the fence, it's pretty much a one horse show, and that horse
> is quasi-dead horse to Sunoracle (that is, any Linux distro besides their own
> proprietary twisted Red Hat fork).
Open JDK is in final stage debugging of workarounds and replacements for
the original proprietary technology that was not open sourced with the
initial or subsequent code drops.  IBM & Redhat are two major firms
assisting with this effort.
And then there is Dalvik.  http://en.wikipedia.org/wiki/Dalvik_(software)

> With that said, in a server/services based world, nobody really cares what you
> are running underneath the covers.  And again, the idea that Java has to be at
> the core, becomes the "poor choice"... again, due to who owns the technology in
> particular.
Oracle is a bit upset to find out that you can't take back what has been
published to the public domain (one of the last things that Sun did with
Java before it was acquired by Oracle)
> Perhaps one the of the biggest reasons for it staying around is because of IBM.
>  I blame IBM for many of the technology lunacies around today.  Big blue is
> probably the direct opposite of what most people think.  Beware.
I sometimes need to deal with folks at IBM.
> HP got their wake up call when Oracle stabbed them in the back.  Not saying they
> don't still have a lot of Java investment, but when you get stabbed the way they
> did, you don't forget it...
Maybe also a demonstration why you should not use Oracle DB?  And/or PL/SQL?
> Now... what about Android.  Obviously at its hard is Google's bastard Java
> child.  So.. that's potentially a lot of installed Java badness.... but really
> it's a bastard "virtual machine (byte code engine)"... so maybe that's not that
> big of a deal.  We already know that Google has their own language thing
> going... so again, they probably saw the light without getting stabbed.
I haven't studied this technology in depth, so I don't have alot of
detail.  I do know that part of what Google did was to "Front load" the
machine specific compiler portion out of the VM.  I'm not sure where
they parked it (PlayStore maybe? Installer maybe), but again, they are
compiling the class files down to machine specific code -- unless the
Device Cpu's can run the byte codes directly (I know of at least three
lines of CPUs that can do this, btw - and one of them is an embedded CPU)
> Stuff to chew on.
>
> Many, if not most, people will disagree with me.  And that's fine.  Just
> remember, to love Java, you really have to place your whole trust in Sunoracle.
>  Just saying...  Or like Google, you end up creating something that's really
> outside of the eco-system...  because you don't necessarily care about anybody
> except yourself.
Once completely true.  Now, only if you use an Oracle JDK, or some of
the other vendors -- although most have been taking care area and using
it as part of the marketing.
> Oracle isn't that different from HP and Dell, etc... in that they obviously fear
> IBM greatly and believe that they only way to "win" is by acquiring a myriad of
> technologies that .. in all fairness... IBM sort of "wants" them to acquire (the
> burden of acquisitions).  In Oracle's situation you have no fewer than three
> internally competing products surround J2EE application servers (OAS, Weblogic
> and Glassfish).  Maybe it explains some of Oracle's insane behavior?  It's
> enough to make anyone go nuts!
Four, not three.  There are two (incompatible) versions of OAS last time
I checked (and that was after Oracle retired a third one).  And don't
get me started on Oracle's JDBC driver for accessing an Oracle DB from
Java -- we just found ANOTHER critical bug in it (so much for "We
support Java" - I'm still asking "When will Oracle properly support Java?").
>
> Arguably IBM has some similar internal competing problems...IBM's just a bit
> harsher internally.  Eventually, they do pick a winner and smash the loser...
> IBM is used to ticking people off... they get away with it daily... and ticking
> off their own is always preferable... which may be why they are "winning" (?)
>
> IBM banked on Java because they wanted to totally dominate it.  And if Sunoracle
> keeps going the direction they are going, this could simply be a long term bet
> on IBM's part.  Because they certainly could have purchased Sun.  So maybe they
> figured they could kill two birds with one stone and eventually "acquire"
> Oracle.... which will be easier and easier as Oracle gradually bleeds to death.
>  Only time will tell (and it's a very LONG term bet).
IBM is also a major contributor in OpenJDK -- so they may be looking to
undermine Oracle that way?
>
> With that said, one could easily argue that IBM has probably 100x more
> dependency on Java than anyone else in the world.. which means, if they can't
> wait for Oracle to die, they may simply force the issue if they perceive too
> much risk there... (remember IBM is a HUGE patent house).
Check out the cellphone manufacturers some time.  Their dependency
dwarf's IBMs.
>
> More stuff that might be entertaining:
> http://blogs.wsj.com/cio/2013/06/05/oracle-customers-must-consider-all-available-options/
>
> http://www.fool.com/investing/general/2013/06/05/dell-and-oracle-expand-alliance.aspx
>
> http://readwrite.com/2013/06/03/oracle-adds-more-jolt-to-java-security-procedures
>
> http://www.infoworld.com/t/java-programming/java-out-of-the-spotlight-still-spry-220129
>
> http://www.infoworld.com/d/the-industry-standard/computer-scientists-oppose-oracles-bid-copyright-java-apis-219728
>
> http://www.techweekeurope.co.uk/news/oracles-java-changes-too-little-too-late-118025?ModPagespeed=noscript
>
> http://www.zdnet.com/making-sure-your-java-isnt-a-load-of-old-rubbish-7000015462/
>
There are pro's and cons for everything.  I will agree with Chris that
one needs to do research (and especially with Java, make sure that the
research is current!) and chose technologies appropriate to the problem
or task to be dealt with.