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."
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 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.