• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

JDK backward comparability put into question...plus Oracle JDK vs OpenJDK issues...

Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is anecdotal, but I worked on a large JSF based project and we used Oracle JDK 8 on Eclipse, with project compatibility set to 7. One day, I decided to use a newer Oracle JDK on eclipse (I think it was 9 or 10, but set to compatibility for 7 to support the project) - the project simply wouldn't run. Disappointed, switched back to JDK 8.

Then, later, on a completely different project, we were told to use OpenJDK, and told that Oracle JDK will not work properly.

What's the story on this? The first scenario I mentioned shouldn't even exist, because a Java developer is taught from the get-go that "Java is backward compatible." Yet... here I am... seeing that it's not?

And then we're told that OpenJDK version x,y,z should support Oracle version x,y,z - but that doesn't seem to be the case either...

Is it a fair statement that "in the wild" you can expect abberant results?
Posts: 892
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been banging around the industry for the better part of 3 decades now, and about all i can say there is that Oracle is NOT Sun. Sun had a rigid policy of backward compatibility except the those features marked as deprecated in each version with a warning they would eventually drop out of the language all together.  I don't see that same level of commitment from Oracle in anything.. especially now with the accelerated release of new versions.  I do not believe they intend, nor are capable of keeping the level of commitment once available and assured from Sun.

Open JDK is another matter altogether... Oracle doesn't not control it, the community does and compatibility between versions is more of a promise and practice than with the Oracle version--IMO.
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aside from what Les Morgan already stated, Oracle took over some time between Java6 and Java7 - I remember that Java6 was still from Sun and even the very first early access version for Java7 came from Oracle. So, a lot has changed between those two versions.
As for "anything newer than Java8": Project Jigsaw in fact did broke a lot of stuff, but I honestly don't know for how long its JSR was already around to it got finally implemented. So the overall transition from Java8 and anything older to Java9 or anything newer can have the issue of breaking at all places.
As for Sun/Oracle vs openJDK: One has to keep this in mind: The language itself and its sepcification were always opensource and public and anyone could implement their own VM - in fact, Microsoft did it, IBM still does it today, and there were a couple of others over the decades. I can't remember the exact point in time and version - but if memory serves correctly on this one, at some point I started reading this line: "OpenJDK is the official reference implementation". So, by this line, unless you use some features specific to the VM vendor and version you currently use your code should run accross all VMs, at least of the same major version.

This brings me back around to ask: "What broke?". I guess there wasn't just the magic "it didn't worked no more" but actually a lot of exception stacktraces and such one sure could had at least tried to figure out what exactly gone wrong. Same for the "oh, uhm, yea, Oracle VM won'T work": There has to be some very specific uses of code one shouldn't use to create that specific dependency. So, to add to your "a java dev learns from the get go": Never use anything beyond the limits of the SE API like sun.* com.sun.* and such. The million dollar question starts when you do comply to this but it still breaks due to implementation specific differences.

So, thanks for sharing the story, but, at least for me and please, don't feel offended by it, in this way it doesn't really have any value. It would had been interesting to dive into the code and stacktraces to see were it breaks to analyse what's causing it. Just "yea, broke when migrated from 8 to 9 / oracle <-> open" is, at least to me, a bit like: "yea, heared it too much - can'T take it anymore".
Don'T get me wrong - sure, this has to be addressed within the community to either stick to the mantra - or get rid of it as it doesn't seem to get followed anymore. Yes, something marked as deprecated always had the line "may get removed in future versions" - but never actually really did before Java9. So something for sure has changed. And who knows, maybe we all stuck in limbo like about any database example still uses Class.forName although JDBC4 and ServiceLoader is around since Java7 back from 2010.
sunglasses are a type of coolness prosthetic. Check out the sunglasses on this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic