Blog archive

Notes on the Conference Formerly Known as JavaOne

What's in a name? Not much, apparently, as Oracle proved last week with its inaugural Code One event, which replaced the venerable JavaOne user conference, in name mostly. The event included a ton of Java content -- sessions, events, keynotes -- with some new tracks aimed at developers building databases-focused apps and MySQL developers. The program also includes sessions on such languages as Go, Rust, Python, JavaScript and R.

The conference included the all-important Java Technical Keynote on Monday evening, with presentations by Mark Reinhold, chief architect of the Java Platform Group, and Georges Saab, VP of Development, who talked about Java SE updates from the last 12 months, including Java 11, as well as future projects.

For his part of the keynote, Saab focused on the challenge of "preserving Java's virtues," by which he meant the free and open community in which Java has evolved. He also talked about Oracle's contributions to that community, including the open sourcing of such Java platform features as Application Class-Data Sharing, the Z Garbage Collector, Flight Recorder and Java Mission Control.

Matthew McCullough, VP of Field Services at GitHub, gave a presentation in which he talked about the importance of OpenJDK and discussed Project Skara, a prototype GitHub-based mirror of the official OpenJDK upstream Mercurial repositories.

But it was Reinhold's presentation that really brought the "JavaOne" to Code One. Everyone's favorite Java Uber Geek started with a discussion about the impact of the new rapid release cadence for Java SE and the JDK, through which Oracle is now "evolving the Java platform at a more rapid pace."

"We've broken a few things, and we will continue to do so," he said, "but in a careful measured way, in order to make Java a better fit for modern applications.'

Attendees got a real sense of the spirit of JavaOne as Reinhold dispelled five misconceptions about how Java is changing. His list included:

  1. Every feature release will be as disruptive as past releases: "No, that's not true. The rate of innovation hasn't changed. What's changed is the rate of innovation delivery."
  2. Non-LTS (long-term support) releases are just a fancy name for a beta: "No. The only difference with an LTS release is it has a longer support timeline. You can use a non-LTS release in production if you like, but know that you'll have to update it in six months, or find someone to support it, or perhaps support it yourself."
  3. To remove an old feature, it must be deprecated three years in advance: "False. To remove a deprecated feature requires a production-ready build that issues a suitable warning at either compile time or runtime -- because a working build, after all, is the ultimate release method."
  4. If you maintain an infrequently migrated system you can ignore the non-LTS releases: "That would be a bad plan ... If you test with each feature release, then you'll be ready to migrate to the next long-term support release."
  5. You can't get more than six months of support for any non-LTS release and never more than three years for any LTS release: "Not true. It all depends on what the non-Oracle members of the JDK community decide to do. They have a proven track record and are already discussing how best to support JDK 8 and JDK 11 for the long haul."

He also made his own strong case for Oracle's approach to open Java. "Oracle builds and OpenJDK builds are at this point functionally interchangeable," he added. "This means that you can switch from one to the other as you please. It also means that all of this code is available under the GPL for anyone to build, test, publish, update and support."

And he covered a number of OpenJDK projects Oracle is pursuing to enhance the language, including Project Valhalla (more efficient JVM memory usage), Project Panama (improving C APIs for interacting with the JVM), Project Amber (making Java more "terse" through the addition of features, such as switch expressions and raw string literals) and Project Loom (a lightweight alternative to threads called "fibers" designed to be more efficient for concurrent code).

All in all, a very Java conference, and with the language and platform evolving in so many directions, it's probably the best we can hope for.

Posted by John K. Waters on October 31, 2018