Skip navigation
ANNOUNCEMENT: community.oracle.com is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

In the most recently completed Java.net poll, a majority of the voters indicated a preference for having major Java releases on a predictable schedule (either a fixed number of months, or a narrow range of months). A total of 683 votes were cast in the poll, and one comment was posted. The exact question and results were as follows:

Should Java have a timed release schedule (for example, a new major release every 18 months)?

  • 48% (331 votes) - Yes, that works best for the community
  • 12% (79 votes) - Timed releases, but with some flexibility (like 18-24 months), would be ideal
  • 2% (11 votes) - Maybe
  • 18% (126 votes) - No, a new release should happen only when significant enhancements are ready
  • 3% (18 votes) - I don't know
  • 17% (118 votes) - Other

So, 60% of the voters consider knowing that the next major release of Java will come out approximately N months after the previous major release to be most helpful for the community. A much smaller share (18%) would rather know that significant new features will be in the next major release, even if the date when the release will come out isn't readily predictable.

yukare commented: "Timed releases means incomplete or buggy realeases because of time."

A problem for Java, compared with, for example, Eclipse, is that the next major release can no longer simply be a bunch of cool new added features that are built on top of what's already there. Enhancements like Project Lambda andProject Jigsaw require overhauling a large existing code base that works.

For projects like Eclipse (which has annual major releases), this is not case: there, the enhancements are largely new or updated add-on modules, along with enhancements to the core application. You don't have to destroy what worked in the last version, and rewrite it so that it works under a new architectural schematic or paradigm.

But this is exactly what has to be done in the case of Lambda and JigSaw. With Lambda, I was surprised at last year's JavaOne to see the quite innovative approach that was being taken to minimize the time and effort to bring closures to Java. Still, there aren't many pieces of core Java that can just be left untouched -- or, at least, nearly every function in every core library has to be examined and tested to see if it's threadsafe. And if changes are needed, then the entire function has to be retested to make sure it still works as it did before under single-threaded operation, as well as when it's utilized by code that's within a closure running on a many-processor machine. That's a lot of work!

With JigSaw, the task sounds just as bad, or worse, since all kinds of internal dependencies have been interwoven into Java during two decades of active development by perhaps tens of thousands of different developers, with various skill sets and development practices, with few people having any reason to anticipate that some day there might be a need to unwind all of this into coherent, self-contained modules...

In his recent post Project Jigsaw: Late for the train: The Q&A", Mark Reinhold put it this way:

the JDK code base is deeply interconnected at both the API and the implementation levels, having been built over many years primarily in the style of a monolithic software system.

Click Mark's link for more interesting details on the monolithic nature of the JDK...

So, when you consider both Project Lambda and Project Jigsaw together, it really is like the originally planned Java 8 was basically going to blow up almost the entirety of existing core Java, and replace it with something very new and different -- while at the same time expecting Java 8 to maintain close to perfect backward compatibility! Daunting tasks...

I think it's very difficult for a development team to maintain scheduled releases when the primary enhancements fundamentally change the existing underlying architecture.

New poll: predict the future of JVM languages

Our new poll provides you with an opportunity to prognosticate! It asks: 10 years from now, which JVM language will be used most for new software development projects?. Voting will be open until Friday, September 7.


Java News

Here are the stories we've recently featured in our Java news section:


Spotlights

Our latest Java.net Spotlight is Jfokus 2013 Call for Papers:

Jfokus will consist of three full days 4-6 Feb 2013. The first day will be a university day with half-day presentations (3.5 hours) and 5-6 February will be regular conference days. Here you can propose a presentation for Jfokus 2013. We will get back to you as soon as we have decided which presentations will be accepted. Last day for submitting proposals is October 1...

Prior to that, we featured Heather Van Cura's JSR 355 Final Release, and moves JCP to version 2.9:

a href="http://jcp.org/en/jsr/detail?id=355" title="JSR 355">JSR 355, JCP EC Merge, passed the JCP EC Final Approval Ballot on 13 August 2012, with 14 Yes votes, 1 abstain (1 member did not vote) on the SE/EE EC, and 12 yes votes (2 members were not eligible to vote) on the ME EC. JSR 355 posted a Final Release this week, moving the JCP program version to JCP 2.9. The transition to a merged EC will happen after the 2012 EC Elections, as defined in the Appendix B of the JCP (pasted below)...

Articles

Our latest Java.net article is Default Constructors by Mala Gupta, author of the Manning Publications book OCA Java SE 7 Programmer I Certification Guide.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed.

-- Kevin Farnham (@kevin_farnham)

http://today.java.net/sites/default/files/OCAJavaSE7CH03_image002.jpgWe've just published a new article by Mala Gupta, Default Constructors. Mala is the author of the Manning Publications book OCA Java SE 7 Programmer I Certification Guide. Her Java.net article is based on materials from Chapter 3 of that book. As such, if you're considering getting the Java SE 7 Certification, Mala's article is a good place to start.

This is the second article Java.net has published in association with Manning Publications. Earlier we published Spring Roo and WebFlow by Ken Rimple, co-author of the Manning book Spring Roo in Action. And there are more to come!


Java.net Weblogs

Since my last blog post, Sanjay Dasgupta posted a new java.net blog:


Poll

Our current Java.net poll asks you to prognosticate: 10 years from now, which JVM language will be used most for new software development projects?. Voting will be open until Friday, September 7.


Java News

Here are the stories we've recently featured in our Java news section:


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed.

-- Kevin Farnham (@kevin_farnham)

The online training academy Udemy is offering their Scala for Java Developers course free to the first 50 members of the Java.net community who enroll. The course, which normally costs $29, includes 8 lectures (2.5 hours total) presented by Andreas Lauschke, business owner and passionate Java, Scala, C#, F#, Mathematica, and Perl programmer.

Andreas describes the course as follows:

This class shows you how to easily transition up from Java to Scala. Not only will you be shown the basics of Scala, but you will also see how you can integrate the Java -> Scala transition in your daily work-flow.

The eight lectures include introductions from the business and technical perspectives; Val vs. Var, basic types, and the REPL; functions as objects, and loops; higher-order functions, lists, maps, arrays; classes, objects, and traits; actors; and a concluding practical outlook.

Udemy's objective is to help students make moves in their professional careers: "Whether you want to get promoted, break into a new industry, start a company, further a passion, or just accelerate your life, Udemy helps you learn from the amazing instructors in the world, so that you can get there and get there faster."

If learning Scala seems like a good move for you, sign up for Udemy's Scala for Java Developers now. Remember, the course is free for the first 50 members of the Java.net community who enroll.


Java.net Weblogs

Since my last blog post, Kirk Pepperdine posted a new java.net blog:


Poll

Our current Java.net poll asks Should Java have a timed release schedule (for example, a new major release every 18 months)?. Voting will be open until Friday, August 24.


Java News

Here are the stories we've recently featured in our Java news section:


Spotlights

Our latest Java.net Spotlight is Roger Brinkley's Java Spotlight Episode 96: Johan Vos on Glassfish and JavaFX:

Interview with Java Champion Johan Vos, who started to work with Java in 1995. He was part of the Blackdown team helping port Java to Linux. With LodgON, the company he co-founded, he is mainly working on Java based solutions for social networking software. Because he can't make a choice between embedded development and enterprise development...

Before that, we featured Markus Eisele's The Heroes of Java: Sacha Labourey:

The "Heroes of Java" series has a run these days. Sacha took some of his precious time and joined as no. 19. Most of you know him from his JBoss time. He founded the European headquarters for JBoss and, as GM for Europe, led the strategy and partnerships. In 2005, he was appointed CTO of JBoss, Inc. and as such, oversaw all of the JBoss engineering activities...

Articles

Our latest Java.net article is Default Constructors by Mala Gupta, author of the Manning Publications book OCA Java SE 7 Programmer I Certification Guide.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed.

-- Kevin Farnham (@kevin_farnham)

Developers expressed disappointment regarding the proposed removal of Project Jigsaw from Java 8 in the most recently completed Java.net poll, and had mixed views on whether Java 8 should proceed without it. A total of 445 votes were cast, and four people posted comments. The exact poll question and results were:

What's your view of the proposed removal of Project Jigsaw from Java 8?

  • 23% (103 votes) - It's a good decision: the most important thing is to deliver Java 8 on schedule
  • 29% (131 votes) - Java 8 without Project Jigsaw is pretty useless; Java 8 should be delayed until Jigsaw can be included
  • 20% (87 votes) - Project Jigsaw is so late it's becoming irrelevant; developers should just use other modularity technologies like OSGi
  • 12% (53 votes) - I don't know
  • 16% (71 votes) - Other

The posted comments were effective elaborations on the poll options.

For example, rdohna commented: "I'm quite undecided... Java 8 has a lot of cool features (mainly Closures) that are well worth getting out of the door as soon as possible. But still it's a pity that Jigsaw won't make it on time..."

dutchiedave noted, "It is essential to modulize the jre as soon as possible because it makes all future code added to the jre more efficient. Modulizing the jre will massively decrease loading time and memory use for the majority of java applications, everyone should be pushing for Jigsaw as soon as possible."

Meanwhile, marrs said, "Project Jigsaw was already too late when it started, and having it part of Java 9 means that only developers that can actually use this version can take advantage of it. That means adoption will take a long time. OSGi is here, it is proven technology and it works on any JVM out there."

But marrs didn't stop there, offering Oracle two interesting counter-proposals to continuing a massive Project Jigsaw effort with much delayed delivery:

  1. Modularizing the class libraries. This is not that difficult at all. Apache Harmony basically already did it for them. The benefit of modularizing these is that you can choose to not even deploy the parts you are never going to use and, maybe even more importantly, you can choose different implementations of the same module (more focussed for example on embedded or server usage).
  2. Implementing "Isolates". This is also something that was already done years ago in the Sun Labs, even though it never made it to the main stream JVM. Isolates allows you to manage modules better, forcefully stopping them or limiting their resources.

The lack of modularization in Java is indeed almost surprising, when you consider languages like C and C++ that were mainstream when Java came into existence, and languages like Python that became mainstream later. For so many modern languages, either it's easy to make a very small, fast-loading executable; or your application can be constructed such that it loads only the language modules/libraries that it actually uses. Even though Java started out much smaller than it became over many years of enhancement, that modularization would be beneficial was always a fact. For example, recall the typical PC on an office worker's desk, or in people's homes, in the late 1990s. There wasn't much power or memory there; so, a modularized Java would have been useful even during Java's early days. Undoubtedly, at the time, other Java platform objectives seemed more critical. For example, Java was increasingly being used for server side programming in those days, making EJBs, containers, and application servers of critical interest...

I suppose you could call the division into Java EE, Java SE, and Java ME a form of "modularization"; but, then again, this really isn't modularization. And clearly the EE/SE/ME division doesn't address all of today's needs.

New poll: Timed Java release schedule, or not?

Our new Java.net poll generalizes the discussion into whether or not new Java releases should come out on a timed schedule. At last year's JavaOne, Oracle announced that this in fact would happen going forward. Specifically, the poll asks Should Java have a timed release schedule (for example, a new major release every 18 months)?


Java.net Weblogs

Since my last blog post, several people have posted interesting newjava.net blogs:


Java News

Here are the stories we've recently featured in our Java news section:

In JDK Enhancement Proposal (JEP) 155, Doug Lea proposes concurrency updates related to JSR 166 (Concurrency Utilities). Why is this significant? Well, Doug's proposed enhancements are not actually part of JSR 166 (which was finalized almost eight years ago); Doug's JEP 155 instead represents an instance of the interactive design process that eventually determines what the next major release of the JDK will include.

If you're not familiar with the term "JEPs", JDK Enhancement Proposals(JEPs) are proposals for JDK enhancements that provide a baseline statement and overview of a proposed enhancement to the JDK. Each new version of Java has as its objective the implementation of a set of functionalities that are defined in JSRs. JEPs are in a sense proposals for meeting those objectives, but with more focus on the actual facets of implementation detail. "How will we accomplish this objective?"

The JEP process is quite new. JEP 1 was created by Mark Reinhold on 23 June 2011. That JEP defines the "JDK Enhancement Proposal & Roadmap Process." What are the JEP process objectives? JEP 1 says:

The primary goal of this process is to produce a regularly-updated list of proposals to serve as the long-term Roadmap for JDK Release Projects and related efforts. The Roadmap should extend at least three years into the future so as to allow sufficient time for the most complex proposals to be investigated, defined, and implemented.

A secondary goal of this process is to define a uniform format and a central archive for enhancement proposals so that they are easy for all interested parties to find, read, comment upon, and contribute to. Proposal documents evolve as work upon them progresses so that, in the end, a completed proposal serves as an authoritative, though not necessarily self-contained, record of what was changed and why.

So, are JEPs an attempt to circumvent the JCP? Mark Reinhold anticipated this question, as he wrote into JEP 1:

This process does not in any way supplant the Java Community Process. The JCP remains the governing body for all standard Java SE APIs and related interfaces. If a proposal accepted into this process intends to revise existing standard interfaces, or to define new ones, then a parallel effort to design, review, and approve those changes must be undertaken in the JCP, either as part of a Maintenance Review of an existing JSR or in the context of a new JSR.

Following the JDK's future through subscribing to the OpenJDK email lists is likely far more than what most developers have time for. But, JEPs come through at a much slower pace, yet they highlight many prominent issues that critical for the next version of the JDK. If you're interested in the JDK's future, I very much recommend following what's happening with JDK Enhancement Proposals.

As for me, you can look forward to more blogs about specific JDK Enhancement Proposals. I've written about JEPs in the past. I think their invention was a great idea, an excellent advance in terms of openness for the Java community!


Java.net Weblogs

Since my last blog post, several people have posted new java.net blogs:


Poll

Our current Java.net poll asks What's your view of the proposed removal of Project Jigsaw from Java 8?. Voting will be open until Friday, August 10.


Java News

Here are the stories we've recently featured in our Java news section:


Spotlights

Our latest Java.net Spotlight is Tori Wieldt's Be in the 2012 Java Music Video:

Here's your chance to be in the Java Music Video for 2012! With your webcam, phone or camera, film yourself doing walks, spins, or drinking (ahem) Java. Watch this video to see samples and where to upload... Now show us what you got and FREESTYLE!

Before that we featured Stuart Marks' OSCON 2012 Recap:

OSCON was an interesting conference again this year. Unlike last year there was no Java sub-conference. Instead, there was a Java/JVM track as part of the main conference. I thought this worked out better; it felt like part of something bigger. This year the emphasis was on open source community...

Articles

Our latest Java.net article is Ken Rimple's Spring Roo and WebFlow. The article is the first in a series that will explore how Spring Roo integrates (and doesn't) with various technologies. This first article discusses Roo and Spring Web Flow.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.

-- Kevin Farnham
Twitter: @kevin_farnham

Filter Blog

By date: