Java SE 8

Project Jigsaw Booted from Java 8?

In his post Project Jigsaw: Late for the train, Mark Reinhold’s proposes "to defer Project Jigsaw to the next release, Java 9." He explains the reasoning for this: "some significant technical challenges remain" and there is "not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands." Reinhold also proposes "to aim explicitly for a regular two-year release cycle going forward."
Based on the comments on that post, it seems that this news is not being particularly well received by the Java developer community. Markus Karg writes, "In fact it is a bit ridiculous that Jigsaw is stripped from JDK 8 as it was already stripped from JDK 7. ... Just give up the idea and use Maven." Jon Fisherwrites, "I don't think this is a good idea for the java platform. ... Delaying this will only turn java in to a leagacy technology." The comment from ninja is, "Whatever route you guys decide to go, I think it's time to prioritize Java the platform ahead of Java the language."
Although this news is generally receiving unfavorable reviews from the Java developer community, the explanations do differ to some degree. Some of those commenting think the modularization of Project Jigsaw is needed now (already may be too late), others think OSGi (or Maven or Ivy) should be used instead and Project Jigsaw abandoned, others would rather get other new features and aren't worried about the modularization being pushed to Java 9, and others simply want to use Groovy or Scalainstead. The question was posed whether other features of Java 8 should be dropped in favor of Jigsaw.
As one of the two "flagship" features of Java 8 (lambda expressions being the other one), I too am disappointed to see that it is likely that modularity will be delayed until Java 9. However, Reinhold points out that if the proposal to jettison Jigsaw from Java 8 is accepted, "Java 8 will ship on time, around September 2013" and is planned to "include the widely-anticipated Project Lambda (JSR 335), the new Date/Time API (JSR 310), Type Annotations (JSR 308), and a selection of the smaller features already in progress."
I really want a new Date/Time API and I think the lambda expressions will dramatically improve what we can do in Java. Because of this, I'll be excited to get my hands on Java 8 even without modularity.

Recent Interesting Software Development Posts - 1 May 2012

This post references and very briefly summarizes several recent posts on subjects of interest to software developers such as NetBeans 7.1.2, progress on Java 8's Lambda Expressions, Guava Release 12, TestNG, Scala, and the expense of ineffective meetings.
NetBeans 7.1.2The release of NetBeans 7.1.2 includes JDK 7 Update 4 (first version of Java SE 7 for Mac OS X).
State of the Lambda: Libraries EditionAfter attending JavaOne 2011, I believe that lambda expressions are going to dramatically change how we write Java. Therefore, it is always interesting to read about progress related to Lambda expressions. In the April 2012 post State of the Lambda: Libraries Edition, Brian Goetz "describes the design approach taken in the rough prototype that has been implemented in the Lambda Project repository." He points out that this description is "intended as a working straw-man proposal" and that "the final version may look different." Another Goetz April 2012 post (Translation of Lambda Expressions) "outlines the strategy for translating lambda expressions and method references from Java source code into bytecode."
Guava Release 12Guava Release 12 was released this week. According to the Guava Release 12 Release Notes, this is the first release of Guava that requires Java SE 6: "Guava 12.0 is the first release to require JDK6. Users requiring JDK5 compatibility may continue to use Guava 11.0.2"
TestNG Rather than JUnitTomek Kaczanowski has posted the slides he prepared "to persuade my colleagues to migrate fromJUnit to TestNG" in his post Why TestNG and Not JUnit?
Scala or Java? Exploring Myths and FactsThe post Scala or Java? Exploring myths and facts addresses some of the alleged pros and cons of Scala articulated online. The author addresses questions about productivity, complexity, concurrency support, tooling, extensibility, interoperability, performance, and backwards compatibility.
The Expense of Ineffective MeetingsJeffrey Scott Klubeck's post The Expense of Ineffective Meetings is not necessarily new, but it is new to me. This short post is well worth the couple of minutes to read and articulates well what many of us have felt after having a particularly useless meeting foisted upon us. I love the quote, "Patrick Lencioni, author of Death by Meeting, says that bad meetings not only exact a toll on the attendees as they suffer through them, but also cause real human anguish in the form of anger, lethargy, cynicism, and even in the form of lower self-esteem."
10 Hard Truths Developer Must AcceptIn the post 10 hard truths developers must learn to accept, Peter Wayner offers ten things that are reminders that "programming offers an array of bitter pills to swallow."
SSH Tunneling ExplainedBuddhika Chamith's post SSH Tunneling Explained is a detailed and illustrated overview of SSH tunneling.
ConclusionThis post has referenced a small set of other blog posts, articles, and announcements that I have found particularly interesting in recent weeks.

How Badly Do We Want a New Java Date/Time API?

The current Java.net poll question is, "How critical is it for JSR-310 (new Date and Time API) to be implemented in Java 8?" At the time of my writing of this post, nearly 150 respondents have voted and an overwhelming percentage have answered either "Very" (53%) or "It would be nice, but we can get by using the current classes" (22%). With 3/4 of the respondents feeling that it would either "be nice" or is "very important" to get a new Java Date/Time API, I think it's safe to say that Java's current Dateand Calendar approach has not grown on us. Perhaps my biggest surprise so far with the survey results is that 2% of the respondents have stated, "I prefer the current date and time classes." Maybe that's from the people who wrote those classes?
I tend to use Java's date/time/calendar APIs off and on. When I use them, I really don't like them, but do start to tolerate them. I begin to forget how much I loathe them until I use them again. I recently helped a colleague familiar with Java (but not with the date/time APIs) to understand how to do some Date/Calendar/String manipulation and presentation. Explaining this mess out loud to him made the ridiculous difficulty of using these too-flexible APIs even more obvious to me. I could see on his face that he was thinking I was either kidding him or didn't know what I was talking about. Although I've gotten to the point where I can make them make do, it's much more difficult than it should be.
Much has been written about the woes of date/time handling in Java. Rob Sanheim wrote in 2006 about date/time-related problems in three of his Top Five Worst APIs in Java (Calendar, Date, andDateFormat/SimpleDateFormat). Java's Date-handling is focused on in Cameron Purdy's 2005 post The Seven Habits of Highly Dysfunctional Design. Tero Kadenius reminded us in the 2011 postHandling dates in Java that "The date/time API in Java is notoriously painful to work with." The aptly named post Java Dates Still Suck was published in 2009.
The current Java.net survey confirms my feeling after working with numerous Java developers and after reading many blogs and articles that the vast majority of Java developers are anxious to get a better standardized way of handling dates and times in Java.

A Plethora of Java Developments in February 2012

There are several sites (Java.net, JavaWorld, JavaLobby/DZone, Java reddit, and Java Code Geeks) that I like to browse for the latest Java news. These sites are great and bring the best from around the web from the wider Java community. A nice complement to these sites is Oracle Technology Network'sJava page. There are several Java stories available on the OTN Java page that originate from Oracle and its employees that are of interest to Java developers. I briefly summarize and link to a subset of these in this blog post.
New Java Language and Java VM SpecificationsAlex Buckley's post JLS7 and JVMS7 online announces the availability of new versions of the Java Language Specification and of the Java Virtual Machine Specification. Besides announcing the availability of these new specifications associated explicitly with Java SE 7, the post also provides some interesting background regarding the history of these two specifications. For example, Buckley states, "Only a major Java SE release can change the Java language and JVM." I also find it interesting that these specifications no longer have names based on their edition (was Third Edition for JLS and Second Edition for JVMS). Instead, these two specifications are now named for the edition of Java SE they are associated with. To me, that's much clearer. You may wonder why this wasn't done in the first place and Buckley explains that, "Historically, the JLS and JVMS pre-date the Java Community Process so there was no Java SE platform to which they could be tied." The specifications are available in HTML or PDF format and it is anticipated that they will be published in printed book format in the future.
Java SE 6 End of Life ExtendedHenrik Stahl uses the post Updated Java 6 EOL date to announce that the JDK6 "EOL date has been extended from July 2012 to November 2012, to allow some more time for the transition to JDK 7." He also highlights portions of the updated EOL policy. The Oracle Java SE Support Roadmap (AKA "Java SE EOL Policy") was updated on 15 February 2012 with this new EOL date.
New Java UpdatesThe Java SE News blog contains posts regarding newly available Java updates. The titles of the posts say it all: Java 7 Update 3 and Java 6 Update 31 have released!, 7u4 Developer Preview is now Available, and 6u32 Developer Preview is now Available.
JSR 354: Money and Currency APIThe JCP Program Office blog features a post announcing JSR 354: Money and Currency API. This JSR proposal describes deficiencies with the already available java.util.Currency class that will be addressed by the JSR. The "proposed Specification" section states:

This JSR will provide a money and currency API for Java, targeted at all users of currencies and monetary amounts in Java. The API will provide support for standard ISO-4217 and custom currencies, and a representation of a monetary amount. It will support currency arithmetic, even across different currencies, and will support foreign currency exchange. Additionally, implementation details surrounding serialization and thread safety are to be considered.

It sounds like there is some optimism about this making it into Java SE 8.
JavaFX 2 Developer CommunityNicolas Lorain writes in JavaFX 2 and the developer community that "JavaFX 2 was only released in October 2011, but there's already a thriving developer community kicking the tires of the new kid on the block." He adds, "There's no denying that we've pretty much started from scratch with JavaFX 2." Lorain then provides evidence of the growing JavaFX 2 community that includes increasing number of discussion threads on the JavaFX 2.0 and Later forum, the developer community contributing roughly 20% of the bug reports related to JavaFX, an "increasing number of people interested in JavaFX are following me" (@javafx4you), and number of community blog posts on JavaFX (references JavaFX Links of the Week). Lorain concludes, "pretty much all the [metrics] I've seen show that JavaFX is growing in terms of popularity."
Incidentally, one of the co-authors of Pro JavaFX 2: A Definitive Guide to Rich Clients with Java Technology has provided some details about that book which will soon be in print and is already available in electronic format.
ConclusionThe Java development community seems more lively and more energetic in recent months (especially since JavaOne 2011) than it has been for years. After years of seeming stagnation, Java-related developments appear to be coming at us more quickly again. It is nice to have so many online forums to get information about these developments.

Recent Java-Related Posts Worthy of Special Notice

In this blog post, I reference and summarize recent Java-related posts that I have found to be particularly interesting and well worth the time spent reading them.
JDK 8 and Unsigned Integer ArithmeticJoe Darcy's post Unsigned Integer Arithmetic API now in JDK 8 states that "initial API support for unsigned integer arithmetic" has been pushed into Java 8. Darcy explains that this is implemented largely via static methods on classes java.lang.Integer and java.lang.Long.
Although Darcy's post is not very long, he manages to talk about the specific unsigned arithmetic functionality that is supported (conversion of Strings to unsigned integers, conversion of unsigned integers to Strings, comparing unsigned values, and calculation of unsigned division and remainder) as well as why it was decided to not implement new types such as UnsignedInt. A consequence of not implementing specific unsigned types is that it is easier to inadvertently mix signed and unsigned values and Darcy suggests some ideas built on naming conventions or new built-in annotations to address this concern.
Versions, Code Names, and Features of Java ReleasesSpeaking of new versions of Java, another Joe (Joseph Kulandai) started 2012 off with a nice post onJava Versions, Features and History. In this post, Kulandai lists the versions of Java in backwards chronological order (Java SE 7 listed first and JDK Version 1.0 at the bottom of the post). Under each major version of Java, Kulandai provides bullet lists of new features in that release and provides thecode name of each release.
Java 8 Status UpdatesContinuing the theme of Java 8 updates, another post of interest is Johannes Thönes's Java 8 Status Updates. This post looks at the status of "the two big new language features of the upcoming Java SE 8" (Project Lambda and Project Jigsaw).
Java 7 ConcurrencyNiklas Schlimm has written two recent posts on using Java 7 concurrency features. He introduces "a flexible thread synchronization mechanism called Phaser" in the post Java 7: Understanding the Phaserand looks in detail at ThreadLocalRandom in the post Java 7: How to write really fast Java code.
OutOfMemoryError: Using Command-line ToolsVladimir Šor's Solving OutOfMemoryError (part 5) - JDK Tools is, as its title suggests, the fifth in a series on Java memory issues available on that blog ("Solving OutOfMemoryError blog post series"). This post provides a brief summary description and usage information for three command-line toolsbundled with the Oracle Java SDK (jps, jmap, and jhat).
The previous entries in this series are written by Nikita Salnikov-Tarnovski: Solving OutOfMemoryError (part 1) - story of a developer, Solving OutOfMemoryError (part 2)- why didn’t operations solve it?,Solving OutOfMemoryError (part 3) - where do you start?, and Solving OutOfMemoryError (part 4) - memory profilers.
Debugging the JVMAttila Balazs's post Debugging the JVM provides interesting insight on something that we don't seem to have to do as often these days as in the earlier days of the JVM, but could be a very useful resource on the occasions this does occur. Balazs talks about "crashing the JVM itself" via null thread group name and then goes onto explain using gdb in Linux to debug the issue with the JVM.
Groovy IntroductionAlex's post provides an introduction to Groovy including coverage of XML with Groovy, regular expressions with Groovy, and SQL with Groovy.
A New Java Blog With Two JavaFX PostsI've posted before on why more developers should write blogs. One of the reasons is the variety of opinions and ideas that are generated that way. With this in mind, I have been interested to read the first two posts of new blog Experiments with Java. Both of the blog's current posts have been written in January 2012 and are on JavaFX 2. The posts are Percent Width for TableColumn in JavaFX 2.x TableView and Sliding in JavaFX (It’s all about clipping).
ConclusionThere have been several good Java-related posts in recent weeks and a sample of them are highlighted in this post.

JavaOne 2011: Project Lambda: To Multicore and Beyond

The presentation "Project Lambda: To Multicore and Beyond" (Session 27400 and not to be confused with Brian Goetz's presentation of the same name) was given in the Hilton San Francisco Grand Ballroom B in the early afternoon on Monday at JavaOne 2011. Even with Grand Ballroom A closed off, this is an extremely large venue for a non-keynote session and there is a large camera (with camera operator) poised to film the presentation. This can probably be construed to mean that the conference organizers anticipated huge interest in coverage of Java SE 8 (JSR 337) and Project Lambda. Alex Buckley (Specification Lead for Java Language and Virtual Machine) and Daniel Smith (Project Lambda Specification Lead) were the presenters and their abstract for this presentation is shown next.

This session covers the primary new language features for Java SE 8 - lambda expressions, method references, and extension methods - and explores how existing as well as future libraries will be able to take advantage of them to make client code simultaneously more performant and less error-prone.

A functional interface is "an interface with one method." A lambda expression is "a way to create an implementation of a functional interface." Lambda expression allows "meat" of functionality to be simply and concisely expressed, especially when compared to the bloat of an anonymous class. Several slides included code examples showing how we'd do it today versus the more succinct representation supported by lambda expressions.
Lambda expressions "can refer to any effectively final variables in the enclosing scope." This means that the final keyword is not required, but rather than it needed to be treated as final (reference not assigned) in the method to be referenced by lambda expression. Some more rules of lambda expressions were announced: the this pointer references enclosing object rather than lambda expression. There is "no need for parameter types in a lambda expression" because they are "inferred based on the functional interface's method signature" (no dynamic typing necessary). Method references support the "reuse" of "a method as a lambda expression."
Buckley talked about external iteration as the current predominate approach in Java libraries. In this idiom, the "client determines iteration" and is "not thread-safe." He talked about disadvantages of introduction of a parallel for loop for solving this issue, but extracted some concepts from the parallel for approach: a "filter" and a "reducer." Buckley introduced the idea that "internal iteration facilitates parallel idioms" because it does not need to be performed serially and is thread-safe.
One of the issues Java 8 faces is the need to retrofit libraries to use lambda expressions, but they already have defined interfaces heavily used in the libraries and collections. One approach that might be used to deal with this issue is the use of static extension methods in Java similar to those available in C#. There are numerous advantages to this approach, but there are also some major disadvantages such as not being able to use reflection. The decision was made to revisit the "rule" that one "can't add an operation to an interface." Based on thism the subsequent decision was made to add virtual extension methods which provide default implementation in the interface that is used only when the receiver class does not override the method with a default implementation.
The slide titled "Are you adding multiple inheritance to Java?!" stated that "Java always had multiple inheritance of types" and "now has multiple inheritance of behavior," but still does not support "multiple inheritance of state, which causes most problems." The slide added that "multiple inheritance of behavior is fairly benign" and is really a problem only when compilation occurs in multiple steps. It was emphasized in this presentation that extension methods are a language feature and a virtual machine feature ("everything else about inheritance and invocation is a VM feature!"). As part of this, a bullet stated, "invokeinterface will disambiguate multiple behaviors if necessary." The non-Java JVM languages can "share the wealth" of extension methods and there was a slide providing three examples of this.
Daniel Smith took over the presentation with the topic of parallel libraries. He showed a slide "Behold the New Iterable" which showed an Iterable interface with methods such as isEmpty(), forEach,filter, map, reduce, and into. He also showed a slide on a Parallelterable interface available from Iterable via extension method parallel().
Smith provided references to JSR 335, JSR 166, and Project Lambda as part of his slide on community contributions. He also cited four additional sessions at JavaOne 2011 regarding lambda expressions and closely related topics. Smith ended with a quote from Brian Goetz on Project Lambda:

...we believe the best thing we can do for Java developers is to give them a gentle push towards a more functional style of programming. We're not going to turn Java into Haskell, nor even into Scala. But the direction is clear.

ConclusionSmith's examples made it clear that lambda expressions will provide tremendous benefits to Java developers in their daily tasks. He showed the types of loops we've all had to write many hundreds or thousands of times and the cleaner, more concise syntax that lambda expressions make possible. This presentation has made it clear that, with the introduction of lambda expressions, Java will gain many of the benefits enjoyed by dynamically typed languages in terms of fluency and conciseness.

Java Lambda Syntax Announced

Brian Goetz's OpenJDK message Syntax Decision (on the lambda-dev mailing list) provides the "(mostly)" decided syntax for Java lambda expressions. Goetz caveats this announcement ["We may still deliberate further on the fine points (e.g., thin arrow vs fat arrow, special nilary form, etc), and have not yet come to a decision on method reference syntax"] before providing some examples of how theC#/Scala-inspired syntax would look.
Goetz states reasons for selecting the syntax such as doing well by "subjective measures" and Javabeing similar to the syntax of two highly related (syntactically) languages (C# and Scala) in the absence of a clearly preferred syntax choice.
Other interesting resources related to Java and the long road to lambda support include First Version of Java Lambda Syntax Sparks Debate, Lambdas in Java: An In-Depth Analysis, Understanding the closures debate, and Project Lambda: Straw-Man Proposal.

All I Want for Java 8 is...

With Java 7 considered practically a done deal (I've had it installed on my home computers as the primary JRE for weeks now), many of us are starting to dream about what might come with Java 8. In this post I briefly look at what I'd like to see in Java 8 before looking at some other folks' wish lists for Java 8. I'll end this post with my ideas on what it most likely to go into Java 8.


My Java 8 Wishlist

Full Runtime Generics Support

I think the thing I would most like to see in a future version of Java (and the sooner the better) is reifiedgenerics. Although there are many minor syntactic sugar changes that would be nice, the erasure ofgenerics type erasure would be most welcome.

JMX 2.0 Features

In the first response comment to Julian Exenberger's DZone-syndicated version of Java 8.0 Wishlist, Jonathan Fisher states that he'd like, among other things, "Annotation based JMX." I was disappointed when it was announced in the summer of 2009 that JMX 2.0 would be deferred until Java 8. Unfortunately, the relevant Java Specification Request (JSR 255) is in the Inactive state. There are numerous proposed features of JMX 2.0 that I'd like to see. Like Fisher, I'd appreciate annotation-based JMX. Other nice JMX 2.0 features included improved querying and the associated support forJMX web services.

Improved Date/Time Support

In the beginning, there was Date. This class had more than its share of problems and now 2/3 of its constructors (four out of six) are deprecated and nearly all of its methods are deprecated (the exceptions being largely methods overriding Object or implementing the Cloneable and Comparableinterfaces).

The Calendar interface and its primary implementation class (GregorianCalendar) were attempts to address the problems associated with Date (though there are arguments for situations when Date is preferable to Calendar).

Unfortunately, Calendar has issues of its own and is not particularly pleasing to use because it sacrifices usability in the name of generality and flexibility (a benefit which is seldom applied because most of us use GregorianCalendar anyway). Many Java developers have found the Joda Time library to be a refreshing approach to handling dates and times in Java.

Many of us were excited at the prospect of Java 7 delivering an improved date/time approach via JSR 310 ("Date and Time API"). Sadly, JSR 310 was not included in Java 7, but it sounds like there's the possibility that it could be part of Java 8. The reference implementation of JSR 310 is the ThreeTen project. It is summarized with this text: "ThreeTen provides a modern date and time library for Java and is the reference implementation for JSR 310. It includes many of the lessons of the Joda-Time project and aims to standardise date and time concepts in computing." I'd love to see JSR 310 implemented in Java 8.


Others' Java 8 Desires

The previously mentioned post Java 8.0 Wishlist outlines some of Julian Exenberger's most desired features for Java 8. These include properties, operator overloading, "finish autoboxing" (methods on literals), and "[making] JavaFX useful." Some of the people commenting on this post vehemently don't want properties or operator overloading. Other people stated their own desired features in comment on this post. These included annotations for checking preconditions and postconditions, modularization, "complete JavaFX," JRE on more platforms, and cleaned up SDK/libraries.

My guess is that one of the most sought-after features for Java 8 is "closures." Indeed, one of the best ways to identify which features are most likely to be most desired for Java 8 is to see what is "most missed" from the proposed but dropped Java 7 additions. I blogged that features such as closures, properties, reified generics, beans binding, operator overloading, and BigDecimal syntax that were dropped from Java 7. The Java.net poll on these features had almost half the respondents state that closures was their most-missed feature dropped from Java SE 7.

Charles Nutter would like to see Java 8 add coroutines and he has initiated that effort.


What's Likely to Make Java 8?

We will hopefully have a better idea of what will be in Java 8 by JavaOne 2011. However, we have some information that provides hints as to what we're most likely to see in Java 8. First, Mark Reinhold's famous Plan B gives us a good idea of initial tentative ideas for Java 8: modularity, "Lambda expressions (informally, 'closures')," Java types annotations, and more small language enhancements ("Project Coin 2").

Another good source of what is likely to really be in Java 8 is the article Looking Ahead to Java SE 7 and 8: A Discussion with Oracle’s Java Language Architect, Brian Goetz. In this article, Goetz talks about tentative Java 8 features such as "upgrades to the core Java libraries to more easily express parallel calculations on collections" and "virtual extension methods" (allows adding of " methods to interfaces that specify a reference to a default implementation").


Conclusion

Java is one of the most used programming languages in the world and the sheer size of its developer base means that there will be a wide disparity of opinions on which features Java would most benefit from. However, I believe that dynamic languages on the JVM (such as Groovy) have influenced many of us to favor closures and that is one feature that sounds destined for Java 8.

Java 7 and Java 8 JSRs Released!

There has been a lot of big news in the Java world as of late. The recent announcements that IBM is backing OpenJDK and Apple is backing OpenJDK were huge in and of themselves. Today there wasmore big news with the announcement that Java Specification Requests (JSRs) have been released for Java SE 7, Java SE 8, and related new Java features. The release of these JSRs is the realization of the now famous Plan B announced prior to JavaOne 2010 and then further detailed at JavaOne.

The newly released JSRs (referred to as a JSR Quartet in Mark Reinhold's blog) are JSR 334 ("Small Enhancements to the Java Programming Language") [Project Coin], JSR 335 ("Lambda Expressions for the Java Programming Language") ["informally, closures"], JSR 336 ("Java SE 7 Release Contents"), and JSR 337 ("Java SE 8 Release Contents").

Joseph D. Darcy has provided additional details on the release of JSR 334 (Project Coin) in his blog post Project Coin: JSR Filed! and pelegri likens this quartet of JSRs to the famous quartet known asThe Beatles (available on iTunes today). Alex Miller, who has maintained perhaps the most exhaustive collection of what is in and out, back in, and then back out, and then back in, for Java 7, has posted hisanalysis of the Java 7/Java 8 JSRs.

The release of these four new JSRs indicate that the plans announced for Java prior to and at JavaOne 2010 are moving forward. Coupled with the announced IBM and Apple support of OpenJDK, the future of Java seems very promising.

JMX 2 Postponed Until Java SE 8

It was disappointing, but not altogether surprising, to learn that JMX 2 will not be part of Java SE 7. Anyone who saw my Colorado Software Summit 2008 presentation JMX Circa 2008 is aware of how excited I was for some of the new features that were tentatively planned for Java SE 7. Java Management Extensions (JMX) is already a highly useful technology, but the advancements in JMX hoped for in Java SE 7 are convenient and welcome. With the long period of time between Java SE 6and Java SE 7, it likely means quite a wait for JMX 2 features that are now expected with Java SE 8.