Slashdot Mirror
Red Hat And IBM Will Vote Against Java's Next Release (infoworld.com)
An anonymous reader quotes InfoWorld:
The next edition of standard Java had been proceeding toward its planned July 27 release after earlier bumps in the road over modularity. But now Red Hat and IBM have opposed the module plan. "JDK 9 might be held up by this," Oracle's Georges Saab, vice president of development for the Java platform, said late Wednesday afternoon. "As is the case for all major Java SE releases, feedback from the Java Community Process may affect the timeline..."
Red Hat's Scott Stark, vice president of architecture for the company's JBoss group, expressed a number of concerns about how applications would work with the module system and its potential impact on the planned Java Enterprise Edition 9. Stark also said the module system, which is featured in Java Specification Request 376 and Project Jigsaw, could result in two worlds of Java: one for Jigsaw and one for everything else, including Java SE classloaders and OSGI. Stark's analysis received input from others in the Java community, including Sonatype.
"The result will be a weakened Java ecosystem at a time when rapid change is occurring in the server space with increasing use of languages like Go," Stark wrote, also predicting major challenges for applications dealing with services and reflection. His critique adds that "In some cases the implementation...contradicts years of modular application deployment best practices that are already commonly employed by the ecosystem as a whole." And he ultimately concludes that this effort to modularize Java has limitations which "almost certainly prevent the possibility of Java EE 9 from being based on Jigsaw, as to do so would require existing Java EE vendors to completely throw out compatibility, interoperability, and feature parity with past versions of the Java EE specification."
Red Hat's Scott Stark, vice president of architecture for the company's JBoss group, expressed a number of concerns about how applications would work with the module system and its potential impact on the planned Java Enterprise Edition 9. Stark also said the module system, which is featured in Java Specification Request 376 and Project Jigsaw, could result in two worlds of Java: one for Jigsaw and one for everything else, including Java SE classloaders and OSGI. Stark's analysis received input from others in the Java community, including Sonatype.
"The result will be a weakened Java ecosystem at a time when rapid change is occurring in the server space with increasing use of languages like Go," Stark wrote, also predicting major challenges for applications dealing with services and reflection. His critique adds that "In some cases the implementation...contradicts years of modular application deployment best practices that are already commonly employed by the ecosystem as a whole." And he ultimately concludes that this effort to modularize Java has limitations which "almost certainly prevent the possibility of Java EE 9 from being based on Jigsaw, as to do so would require existing Java EE vendors to completely throw out compatibility, interoperability, and feature parity with past versions of the Java EE specification."
Oracle loves EE: my team at Sun detested it (:-))
davecb@spamcop.net
"JDK 9 might be held up by this,"
Write once, wait everywhere. :-)
[ Disclaimer: I like Java. ]
It must have been something you assimilated. . . .
Let me guess IBM/Websphere is not ready so everyone has to wait for them??? How about we stick with EJB3 and ESB?
http://www.androidauthority.co...
While C is faster in some cases, java is faster in other cases starting with Android 6.0.
Personally, I think Java is the way to go until we invent another language which is clearly better and can easily and automatically be converted to from Java.
I saw the value of Java when it first came out. And I've seen many other languages come and go since which are less mature and frequently lose support after you commit to them. I know of more than one multi-million dollar application written in hot new languages which were subsequently end of life'd.
In one case, it also failed to replace the java application successfully and was tossed. The millions of dollars spent on the new application could have been spent polishing the java application- but our arcane tax rules favor new development over maintenance. In any case, 7 years later the java application is still being used.
Like Cobol, java is well suited for a wide range of applications but not all applications. And we have the potential to use the same code and programs 30 years from now without rewriting them again and again.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
I've written a couple apps in Java, run them weekly. That said, no way in hell will I allow a web browser to run Java (nor Javascript, and I know they are completely different). Don't see how either of my apps are security issues as neither touches the network. They scratch an itch, they do what I need them to do, I'm happy with them.
Technically speaking nothing what so ever requires older versions of anything in the digital world. More accurately, they have no economic desire to invest in port programs and converting data in order to make the transition. The cost is large and problems will occur but it most definitely is not impossible, or even all that difficult, just quite expensive. What I have learned, is the longer you put it off, the more expensive it becomes, flip side early conversions often lead to choosing the wrong direction requiring another conversion decision. In conjunction those two issues keep legacy stuff hanging on far longer than they should.
Chaos - everything, everywhere, everywhen
I vote against Java as well. Can we vote that it gets deleted from existence? That's my vote.
Java can't be deleted. Instead, you have to try to break all strong references to it, then hope that it gets garbage collected.
In conjunction those two issues keep legacy stuff hanging on far longer than they should.
The only legacy applications that get off the network in a hurry are those tied to specific version of Windows Server at end of life. Server owners have 18 months to move their server to a current image of Windows Server. If they don't do so six months after the deadline, the server team will yank their physical server out of the data center and drop it on their desk. By drop I mean two feet above the desk and a 50/50 chance that the server might not work again.
Known as "bit-rot" due to third party API's. Write your own software layers and there is no problem. Use a third-party API, and suddenly those simple menu widgets that you used happily for many years, suddenly disappear or get reformurgulated into some new document design pattern requiring base, derived parent and children classes with additional callback event handlers, simply because the developers thought those old widgets didn't provide enough flexibility. They could of course provided an emulation library built on top of their new release, but of course, that would have been too simple.
With kernel stuff, function calls suddenly start needing new pointers to return result codes, a data structure that used to bound inside a particular object is now passed by pointer because increased flexibility requires that the called makes the choice. Maybe a function call disappears because of the use of internal dependency tracking or new setup functions have appeared.
You just need to look at the evolution of the 3D API's to see how this works out; The evolution of OpenGL from the 1990's to the present day has about 60 different combinations of draw calls to render a simple 3D model.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Oracle loved complexity and magic incantations in xml. Sun liked simplicity and elegance, thus the comment about ee. I don't think testing came into the discussion at that time.
davecb@spamcop.net