Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Java IBM Oracle Red Hat Software

Red Hat And IBM Will Vote Against Java's Next Release ( 57

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."
This discussion has been archived. No new comments can be posted.

Red Hat And IBM Will Vote Against Java's Next Release

Comments Filter:
  • Honestly, the whole Jigsaw thing, while interesting, didn't require all the internal replumbing they're doing. As for J9EE not running on Jigsaw, great! Does anyone still use EE for anything new? Pieces of it, sure, but EE as a whole? Who'd want that?

    To be honest, simplifying the Java system into a solid core is great, but Jigsaw seems to break far too many things.

    • by davecb ( 6526 )
      Oracle loves EE: my team at Sun detested it (:-))
      • Detested it? Weren't Sun people supposed to add tests for Java rather then remove them?
        • by davecb ( 6526 )
          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.
  • Java... sucks... (Score:2, Interesting)

    I would love for older versions of Java to go away. The majority of the 80,000+ workstations I'm responsible for has the current version of Java installed. Some of these workstations have legacy applications that requires an older version of Java 6 by itself or with the current Java installed. Accidentally deleting an older version of Java can cause a blizzard of emails. Whenever I come across an older version of Java, I create a ticket for the local tech to evaluate.

    And then there is Adobe Flash...

    • by rtb61 ( 674572 )

      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

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

      • by mikael ( 484 )

        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 libr

  • People need to stop using Java for everything, not because of personal preference but because of Oracle's incessant bullshit. Honestly, if OpenJDK hadn't originated from SUN then Java programmers would shit out of luck as Oracle would have had to crush them just to get to Google.

    Stop supporting Oracle's eternal war and move to different languages!

    • by mikael ( 484 )

      The choice of high level language is more to avoid the debugging time having to deal with pointers, and matching memory allocation and deallocation. Even with C++, the use of smart pointers is preferred because then time doesn't have to be spent looking for memory leaks. To make things even more complex, these can differ from OS to OS and even compiler version. Plus they don't want to be dominated by Microsoft at any cost.

      • by 0123456 ( 636235 )

        "Even with C++, the use of smart pointers is preferred because then time doesn't have to be spent looking for memory leaks"

        People who believe that tend to be the same people who write Java code with horrendous memory leaks. Or with essential objects that get garbage collected because they forgot to keep a pointer to them.

  • by fahrbot-bot ( 874524 ) on Saturday May 06, 2017 @06:15PM (#54369061)

    "JDK 9 might be held up by this,"

    Write once, wait everywhere. :-)

    [ Disclaimer: I like Java. ]

  • by kiviQr ( 3443687 ) on Saturday May 06, 2017 @06:24PM (#54369077)
    Let me guess IBM/Websphere is not ready so everyone has to wait for them??? How about we stick with EJB3 and ESB?
  • by Snotnose ( 212196 ) on Saturday May 06, 2017 @08:44PM (#54369415)
    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.
  • IBM and Red Hat are correct:

    The project seems to have slipped backwards, as this slide from 2014 indicates the implementation of version requirements. []

    Whereas the 2016 documentation stipulates:

    "A module's declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications."

    The State of the Module System []

    Anything less than Node's package requirements is going to be useless. There should be absolutely no wildcards in major version numbers, with warnings in medium. They are the curse of Node!

  • I've not looked into Jigsaw / JSR 376 in any detail, so I can't comment on it's virtues or problems.

    But I wonder if the bigger picture isn't being missed here - part of the reason why other languages are taking off is a lack of progress with Java. Although, I've always seen the calls for modularity a bit misguided - the classloader provides separation within a JVM when it is required. An "interpreted" mode (e.g. watches .java files for changes, and compiles / replaces the class behind the scenes) would be a

  • If you actually read TFA [], Stark isn't vetoing Jigsaw so much as calling for a delay so they can add the features needed for read-world applications, before they finalize it and it causes a world of hurt. Originally I was like "I want my Jigsaw now, why is this guy making trouble?", but after reading his well-presented blog post I think Oracle and the Java community should be taking these concerns very seriously.
  • I also vote against Java.

"America is a stronger nation for the ACLU's uncompromising effort." -- President John F. Kennedy