65 patches later and Java STILL breaks stuff Software tool vendors are complaining that recent updates to Java are breaking their environments. The problem seems to be in JVM's bytecode verification, in Java 8, Update 11 and Java 7, Update 65. According to InfoQ, developers running into the bug include JRebel (from ZeroTurnaround), the Groovy programming language, the …
It's unfair to call this a "java [sic] problem". Oracle made the JVM enforce one of the rules documented in the specification. They fixed a bug; it just turns out that a lot of code relied on the old, broken behavior.
This of course comes as no surprise to anyone with substantial knowledge of, say, C, where this sort of thing happens all the time. The majority of programmers cannot be bothered to look at language specifications, and their metric is "if I don't see a problem, there is no problem".
I can sympathise with the third pary tools which are broken by the Oracle update. But the spec (and JDK compilers) have always enforced the superclass constructor must be the first call. The third party tools are broken by generating incorrect Java byte code and should be fixed.
Of course we then get into the whole realm of what's the true specification: What's written or what's implemented?
Found the article, there's madness in their method...
http://www.theregister.co.uk/2013/05/15/oracle_new_versioning_scheme/
I always get resentful when I find a machine that needs Java. Just know it's going to be one long string of updates, errors, and regressions.
Of all the runtimes you come across in the field, JVM Seems to be the one that gets the most updates, and causes the most headaches, to the point where most of our shops prefer to avoid software that uses it - Heck even Adobe Flash has a streamlined updater that seems to do it's job in 2014.
I don't know enough about Java programming to understand why it's such an aggravation to update, keep older apps working with it, or generally just work without whining, but I wish they'd fix it - I mean, they finally got a version that works with User Account Control out of the door, so who knows what's possible?
I don't know enough about Java programming to understand why it's such an aggravation to update, keep older apps working with it, or generally just work
It's usually down to sheer incompetence on the part of the programmer. Java lowered the bar to programming in "enterprise" environments, so despite a lot of work on making Java idiot proof a bad programmer can still bugger things up. The classic example is using non-public APIs (stuff in the com.sun packages), which can render your application non-portable between versions. In the case of this article, it's third party libraries working at a low level and not conforming to the language specification. They relied on behaviour that wasn't guaranteed by the spec, and have now come unstuck as the previous behaviour changed.
Java lowered the bar to programming in "enterprise" environments, so despite a lot of work on making Java idiot proof a bad programmer can still bugger things up.
There are good java programmers, of course. But my first reaction when I hear "java programmer" is to mentally replace the word "java" with the word "sloppy."
They draw in pretty good salaries, though. Maybe I'm just jealous.
I've been a Java developer for more years than I care to remember and from day one the installation and management of the JVM has been a painful experience. I have to give Sun and now Oracle some credit as I've not run into many regressions over the years but when they have cropped up they have been seriously painful to find and work around.
The thing that really bugs me is the way machines seem to just magically acquire versions of the JVM over time. I've seen production machines with a dozen different versions of the same major release of the JVM. It's often then a matter of tracking down every possible piece of Java software and setting it to use the correct version before removing the old versions manually, urghh.
I don't think the JVM gets any more patches than, lets say, Windows. I think the JVM just handles the process in a really bad way that makes it stick out like a sore thumb.
As for the guys in the article, I struggle to have a lot of sympathy. I'd rather it enforced the spec.
If you are going out of your way to manually generate bytecode that does not conform to the specification but just happens to work, I'm not sure how much sympathy I have.
I know it might be indirectly via some tool or another and those doing it might not know it was happening, but someone somewhere was doing it and it sounds like an all round bad idea that would obviously byte(geddit) them in the arse at some point.
A/C "Uh..." is a stupid Troll.
This issue is not Oracles' fault, rather it is cowboy alternative JVM language developers breaking the class constructor rules and temporary getting away with it because the class byte code validator (security code) wasn't as strict as the Java language compiler javac; this check is done by javac because this broken class constructor code could cause race condition bugs and even become a separate security issue, which is also not Oracles' fault now.
What should happen is the offending alternative JVM language providers should be told tough by Oracle and told that it is their responsibility to fix their already broken class constructor code if they want to run their language to run on a JVM. This is also important because their code maybe called by Java code and break it too!
At least Java is not as horrible to fix as dotNet installs, because when they fail, it can get real nasty!
If anything Java can be easier to update than Flash (which I wish would die everywhere), because I've had several occasions when it wouldn't update without a reboot; unacceptable! Browser Javascript is getting nearly as painful as Flash due to the growing bloat of client side Javascript and AJAX which can even make browsers freeze, even on powerful PCs!
8.8.7. Constructor Body
"The first statement of a constructor body may be an explicit invocation of another constructor of the same class or of the direct superclass."
From http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.8.7
Sounds like the patch changed the enforced behavior from "may" to "must". An "explicit" invocation of a constructor probably means arguments are used since a no arg constructor will be inserted by the compiler *if not provided by the programmer), and that inserted constructor will have an invocation to the no arg constructor of the superclass.
Cause the devil is in the details.
I downloaded the "Windows Offline" binary yesterday, and was a bit perturbed to see that it was provided as a .com file. I just downloaded it again today, and it's now a .exe. A binary comparison shows that it's exactly the same file, except for the name.
I've slowly gotten rid of functions that require it, and recently returned a Trendnet IP Camera that can only be viewed using either an ActiveX control or a Java applet - no HTML only interface provided. I can see the video stream on my phone and tablet using any number of viewers, and a quick search online gave me a URL that I can use to access the stream from a web browser on my PC, but I contacted their support and told them that I'm returning it and buying a Foscam instead because I'm not installing Java just to access their webcam.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
