JavaOne 2012: JSR 353: Java API for JSON Processing

I went to Parc 55 Mission to see Jitendra Kotamraju's (Oracle) presentation "JSR 353: Java API for JSON Processing." Kotamraju is the JSR 353 specification lead, so it's safe to assume he knows something about this "JSON for Java" JSR. I have written about Groovy's impressive JSON support and have looked forward to Java having something like this.

JSON (JavaScript Object Notation) in Java has been a popular topic for some time now. It is refreshing to see that JSR 353 ("Java API for JSON Processing") is in Early Draft Review and looks likely to be part a forthcoming Java EE release.

Kotamraju began with a brief overview of JSON and looking at an alternate (JAX-RS) use case of JSON before moving onto coverage of JSR 353 and JSON processing in Java. He described JSON as it's typically described: "lightweight data exchange format" that is "easy for humans/machines to read and write." One of his bullets emphasized that JSON is textual and fairly concise. He showed a slide with numerous "popular web sites" that provide "RESTful web services" using JSON.

Kotamraju had a slide focusing on the JSON used with Amazon Cloud Services. Another slide focused on the same for Twitter Search.

Kotamraju first showed slides on JAX-RS that showed exposed services returning XML via JAXP and JAXB. He then introduced the idea of using JSON ("application/json") rather than XML ("application/xml").

He stated that while the JAX-RS specification doesn't currently support JSON, many of the JAX-RS implementations do support JSON.< The downside to JSON being a nonstandard feature of JAX-RS implementations includes work-arounds used to make this work (such as converting JAXB to JSON or converting JAXB to XML to JSON), limitations in some implementations, and the need to bundle extra libraries. Standardizing JSON support would help make its use leaner and cleaner and more consistent.

The JSON standard support is encapsulated in JSR 353. This JSR currently includes a "streaming API to produce/consume JSON" and an "object model API to represent JSON." The Expert Group for this JSR includes Oracle, RedHat, and Twitter as well as individual and community members.

Kotamraju showed a bubble chart showing the states of a JSR with the current state of JSR 353 (Early Draft Review) highlighted. JSR 353 is implemented as a java.net open source project. They have mailing lists and an issue tracker, both of which Kotamraju provided URLs for on one of his slides. The JSR 353 reference implementation (jsonp) falls under the "GlassFish umbrella."

Kotamraju had a nice slide summarizing (two bullets each) the characteristics of the two JSR 353 APIs (Steaming API and Object Model API). He then went into more detail on each of these two APIs.

The JSR 353 Streaming API is similar to StAX and includes JsonParser for "parsing JSON in a streaming way from input sources." An instance of JsonParser is acquired via Json.createParser() or Json.createParserFactory().createParser(). This parser is optionally configured to use certain features and supports several state events including START_OBJECT, END_OBJECT, KEY_NAME, and VALUE_STRING. Kotamraju pointed out that the Streaming API is very low-level and not type safe (difficult to be type safe with String-oriented things like this!).

The Streaming API also includes a JsonGenerator that "generates JSON in a streaming way to output sources" and is "similar to StAX's XML StreamWriter.

The JSR 353 Object Model API core classes include JasonObject and JsonArray as well as JsonBuilder, JsonReader, and JsonWriter.

JsonObject is immutable and "holds name/value pairs" that are accessible as Map<String, JsonValue>. The JsonValue returned from the "value" portion of that map supports a getNames() method. JsonArray is similar to JsonObject in terms of immutability but is a List of values.

JsonBuilder is used to "build JsonObject and JsonArray from scratch." It allows for method chaining and is "type-safe" in terms of not allowing mixing of objects and arrays.

JsonWriter writes JsonObject and JsonArray to output source and uses pluggable JsonGenerator. There will be optional configuration features such as "pretty printing" (what's pretty will be up to implementation) and single-quote strings.

The JSR 353 Expert Group still needs to define equals/hashcode semnatics, how to handle exceptions, and other miscellaneous to-do items. Kotamraju encouraged attendees to try read more about JSR 353 and try out the reference implementation. He'd like to know if it's simple enough to understand and meets peoples' needs.

There were several points during this presentation when Kotamraju stated that the JSR 353 Expert Group would appreciate feedback on a specific design decision or other design choice. This again fits a common theme of JavaOne 2012 that community feedback is desired. This common goal of basing standards on developer feedback is the polar opposite of the old we-know-better-than-you expert committee approach of "you'll have EJB 1.x/2.x and you'll like it."

I liked that Kotamraju showed code samples embedded within his slides. I did this when I presented at Colorado Software Summit and received rave reviews from the audience members for doing so. It's certainly more work for the developer than simply showing code in the IDE, but it allows for greater focus on what's important and makes the sample code readily available for anyone reviewing the slides at a later time. I now regularly include sample code directly within slides of presentations that I give.

JavaOne 2012: Build Your Own Type System for Fun and Profit

I returned to Hilton Yosemite A/B/C to see two speakers from the University of Washington Computer Science and Engineering (Werner Dietl and Michael Ernst) speak on The Checker Framework in a presentation called "Build Your Own Type System for Fun and Profit."

Ernst started off the presentation and showed images demonstrating that we can seen undesired errors and stack traces on the web, on the desktop, and even on mobile devices. With this background in mind, he introduced the idea of a "pluggable type system" to address Java "being too weakly typed."

The Checker Framework "plugs a type checker into the Java compiler" and is used with the standard javac command-line compiler tool. New annotations can be used today (before Java 8/JSR 308 general availability) because they can be commented out with /* */ comment syntax and the Checker Framework will respect them. Then, when Java 8 is released with this new type support, these can be uncommented and the language compiler will allow annotations to be specified against types. This means that Checker Framework's annotations can be used directly (not commented out) on types in JDK 8 (but Checker Framework will not itself be part of JDK 8).

It is important to emphasize the value of this: using Checker Framework and provided compiler plug-ins allows errors and exceptions that would normally not be seen until runtime (and then perhaps sporadically) to be seen consistently and earlier at compile time. The presentation was organized to present the runtime (mis)behaviors that we desire to avoid followed by what operations are legal for each misbehavior and the types of data that lead to that problem.

The speakers ran their Checker Framework against millions of lines of source code and used a consistent approach. This approach included the differentiation of real problems found versus problems with the annotation.

@NonNull and @Nullable are part of the "Null Pointer Exception type system." They found that Google Collections's ForMapWithDefault class has an @Nullable field called defaultValue that is (by implicit default) initialized to null, but then is dereferenced in the hashCode() implementation. The FindBugs runs against this code and the many unit tests written against this code had not detected this issue. Use of annotations such as these is another good tactic for effective NullPointerException handling.

Ernst talked about avoiding ClassNotFoundException and outlined four types of data (unqualified strings, fully qualified names, binary names, and field descriptors). The Javadoc for java.lang.class.forName() states that the provided String is the "fully qualified name of the desired class." However, it really should have been documented as binary name. The only way this problem is encountered in runtime is when an anonymous class is used, but it will have an error in that case. Related to this particular issue, they found 24 errors in OpenJDK and other libraries.

Dietl started by talking about the "regular exprsesion type system." The effort here is to avoid PatternSyntaxException and IndexOutOfBoundsException. This can be done using two annotations: @Regex and @Unqualified.

After showing Checker Framework code and its use by demonstration, Dietl asked the audience for other useful runtime errors they'd like to have. Ernst "got so excited" in responding that he temporarily left the methodology, but the point was still made: Checker Framework already supports detection of numerous common runtime issues at compile time, but is extensible for new or yet undiscovered runtime issues.

Dietl talked about a sample of type checkers including @Tainted, @BinaryName, @Nullable, @Lock, @GuardBy, @Immutable, @SwingCompassDirection (fake enumerations), @Localized (internationalization), @RegEx, etc.

Dietl moved onto showing how to develop one's own type system and used creation of an "Encryption type system" to demonstrate this. He showed four lines of code that completely implement the checker to make sure that only encrypted Strings are sent.

Ernst explained that more complicated checkers can be created. Complex checkers can consist of multiple checkers. The Checker Framework has built-in "powerful analyses" that can be used by all checkers.

Ernst talked about other tools built into Checker Framework and then summarized pluggable type checking as one approach to building quality code. The Checker Framework is a pluggable type checker that can be extended for personal and custom needs. There are three simple questions (What runtime behavior?, What operations are legal?, What is the data?) whose answers can make working with types easier.

One interesting question and response led to Ernst's statement that the Checker Framework is best suited for quality issues related to data, but not to structure.

Another question brought up two actual questions. One question was about why Checker Framework reports warnings rather than errors, but Ernst stated that there is a switch to change it to report them as errors. The second question was about integration of Checker Framework with Eclipse. Eclipse has its own compiler, but there is a "mostly functionality" Eclipse plugin that can be used to support Eclipse use of Checker Framework.

Any version of Java can be compiled with Checker Framework and Java 8 will even support special syntax for this. The reasons that this is not a standard part of the language include that not everyone wants it and not everyone can agree on the definitions. "Because different people need different things," it is not desirable to standardize all of the checkers. JSR 305 ("Annotations for Software Defect Detection") is Dormant currently.

There are many things I'm excited to use sometime in the future such as the JDK 8 features of Project Lambda and JSR 310 Date/Time API, but I am really excited to try using Checker Framework immediately to improve my code's quality! I like it when my experiences at JavaOne do include exciting things for the intermediate to long term future as well as some try-it-right now experiences.

JavaOne 2012: From Instants to Eras, the Future of Java

After spending all day Monday in the Hilton, I wasn't too surprised when my first session on Tuesday brought me back to the Hilton. Stephen Colebourne and Roger Riggs and presented "From Instants to Eras, the Future of Java" in the Hilton Yosemite A/B/C conference room. This presentation was high on my list of those to see because, after lambda expressions, the new date/time API is the feature of JDK 8 that I'm most looking forward to. Indeed, as Mark Reinhold stated in the Technical Keynote when trying to soothe concerns over the booting of Project Jigsaw to JDK 9, lambda expressions and the Date/Time API are among the many changes coming in JDK 8 that still make it an exciting release.

Colebourne showed an image of complicated clock machinery and stated that the photograph is representative of the complications inherent in attempting to write a satisfactory date/time for Java. He, of course, had a plug for Joda Time, which is the inspiration ("similar, but not identical") for JSR 310. He pointed out that JSR 310 was approved back in January 2007, but it is expected to be Feature Complete (M6) by January 2013. I agreed with his point that it's better to take time putting this in rather than to introduce yet another unfinished or poorly finished API into the SDK (think Date and Calendar).

Colebourne covered several design principles behind the new date/time API. These include fluency, immutability and thread safety, extensibility, IDE friendliness, clarity, and more.

Colebourne showed a colorful slide with numerous words and concepts sprinkled throughout. The point is how many different terms, concepts, and meanings there are in the date/time space. One of his bullets pointed out, "'time' is overloaded with many meanings." One of the goals of JSR 310 is to "define a consistent language for the domain" and "help teams communicate."

In the end, JSR 310 faces "two core requirements": machine time and human time. Continuous incrementing numbers (think milliseconds since epoch time) work well for machines while field-based dates/times work better for humans.

One concept in JSR 310 is the "Instant" (single instantaneous point on the timeline). Another named concept is "Duration" (amount or quantity of time not connected to a timeline, but it is a difference between two Instants). Both Instant and Duration are measured in nanoseconds. Colebourne showed a slide with several code examples using Instant and Duration and performing operations on each in terms of the other.

"Colebourne went on to address the "weird" aspects of date/time: "There is such a time as 23:59:60." He talked about leap seconds and "real life." He pointed out that, "The length of a day changes, but the length of a second does not change." Java's current implementation counts milliseconds since 1970-01-01 (Java's epoch time), but "UTC only started properly at 1972-01-01" (scientists' current definition at this time).

To address issues like these, JSR 310 defines "Java time-scale relative to civil time." "Civil time" is currently UTC, but by having a different name, it can be associated with anything that might replace UTC in the future. He stated that "Midday always matches civil time exactly" and that a Day already has 86640 sections.

A LocalDate is a "date without reference to time or timezone." Colebourne pointed out that this is better than trying to set java.util.Calendar to a date with 0 for hours, minutes, and seconds. Similarly, LocalTime is "a time without reference to date or timezone." Combining these two together creates a LocalDateTime (no timezone).

Colbourne talked about timezones and JSR 310 classes such as OffsetDateTime. As a "date and time with an offset," OffsetDateTime is an absolute point on the timeline. Java uses the TZDB ("Timezone Database"). The JDK's TimeZone class represents a timezone offset AND "figures out daylight savings," but JSR 310 splits up these two responsibilities into separate classes. One useful class in JSR 310 is the ZoneResolver, which uses the Strategy Design Pattern to deal with difficult/weird timezone issues. The ZonedDateTime class combines all of this into a single class supporting dates, times, and timezones.

Other classes and enums in JSR 310 include Year, YearMonth, MonthDay, Month, DayOfWeek, and so forth.

Because JSR 310 objects are immutable, they provide "with" methods rather than "set" methods. The "with" methods return a new instance based on the target instance modified by the value passed to the "with" method. Colebourne likened this approach to that used by String.lowerCase().

Riggs talked about integrating the JSR 310 implementation into the Java SDK. While JSR 310 concepts and constructs will show up in Calendar, the current plan is to prevent "pollution" from Date and Calendar creeping into the JSR 310 constructs. I definitely think this is the correct approach.

Riggs also discussed JDBC and database support for JSR 310. His bullet stated that "JDBC group represented on JSR-310." He showed a mapping of JSR 310 classes to JDBC classes.

Riggs explained the Period class, which "describes duration in human fields." The main differentiation I see between Duration and Period is that the former supports machines and the latter supports humans. [Later Update: An audience member asked about the difference between these two concepts and Colebourne answered similar to what I assumed, but he added that there is a more subtle difference: duration takes into account Instant timeline (timezone considered) while the period takes into account the clock on the wall (timezone not considered).]

Riggs returned to the concept of the "current 'civil' calendar," which is based on ISO-8601. They are working on a calendar-neutral system for using non-ISO calendars and lookup the alternate calendar systems by name ("Coptic", "Hijrah", "Japanese", "Minguo", "ThaiBuddhist"). As currently implemented, this non-civil support is only available for dates. All of these are convertible to the ISO ("civil") standard.

One of the difficult things that Riggs talked about related to regional calendars is the concept of eras. Chronology and ChronoDate support methods for dealing with eras and other less common date measurement concepts. A goal of JSR 310 is to be extensible so that new calendars can be added.

So far, I like what I've seen from JSR 310 related to handling different calendars. It is obviously nice to allow support for anyone's preferred calendar, but it seems silly to make everyone deal with strangeness and difficult APIs to accommodate a minor fraction of developers (think Calendar interface). The JSR 310 approach seems to provide easy-to-use APIs for the majority of developers while not precluding developers needing special cases from having the support they need.

Riggs showed a code example of acquiring Instant that used the Clock class to initialize the Instance instance. JSR 310 retains its immutability in its date/time formatter called DateTimeFormatter. There are common formatters in DateTimeFormatters and an ISO-8601 compliant string is returned by toString().

The core date time model, according to Riggs, consists of the DateTime interface and the AdjustableDateTime interface.

Rigg's slide on "Open Issues" was also interesting. They would like to use Java 8 (Lamba) features. They also still need to work out details of the Period to SQL mapping. They have several design issues still to address. One of their next steps is to integrate ThreeTen (JSR 310 reference implementation) into OpenJDK. Other "next steps" are "more implementation" and "more unit tests." Finally, they need "review by OpenJDK reviewers."

As with many other sessions at this JavaOne, Riggs mentioned that JSR 310 is open ("very open!") and listed some ideas for community help (joining mailing list, comment on Wiki, reviewing the API). Colebourne reiterated the point about its openness and the desire for community feedback.

Before answering audience members' questions, Colebourne had some questions for the audience. My guess is that he was looking for community feedback on certain design issues. One of his questions was how many people using a production system used a date older than 1900. There were, surprisingly, several of these. However, only one person answered the second question affirmatively (how many of you have used a non-ISO calendar system in Java?). This is not surprising to me, but audience members made a good point that this should be asked in JavaOne in Brazil, Japan, and Thailand.

In response to an audience member's question, Colebourne said he plans to update Joda Time to implement JSR 310 interfaces, giving developers an option to use those implementation classes rather than the JDK classes (and an easier way to migrate if necessary). He mentioned that a disadvantage of this is that there will be class name clashes requiring fully specified package names in some cases.

Although this session was decently attended (room was about 20% full), I was surprised that it wasn't much more full than it was given the significance of this change, given the itch that it scratches, and given that it is one of the more exciting features of forthcoming JDK 8. Like Lambda, this seems to be maturing nicely and I doubt that much that is learned now will be wasted (will change dramatically before the JDK 8 release). Riggs called JSR 310 a "very robust, very complete" API for handling date and time and that definitely seems to be the case.

The questions in the question and answer section proved that while the audience was smaller than I had anticipated, there are still many people very interested developers in attendance. There were lots of great questions that showed familiarity with the pains of date/time and interest in the new API.

Like The Road to Lambda, this presentation met my expectations and left me excited about its subject matter. Some have stated that JDK 8 should not be delivered without Jigsaw, but my feeling is that Lambda and JSR 310 alone make JDK 8 well worth delivering as soon as possible.

JavaOne 2012: The Road to Lambda

One of the presentations I most eagerly anticipated for JavaOne 2012 was Brian Goetz's "The Road to Lambda." The taste of Lambda at last night's Technical Keynote only added to the anticipation. Held in the Hilton Plaza A/B, this was a short walk from the previous presentation that I attended in Golden Gate A/B/C. I had expected the relatively large Plaza A/B to be packed (standing-room only), but there were far more empty seats than I had expected.

Goetz started talking about Java 8 being "in the home stretch," but not yet released or ready for delivery. He said he expects Java 8 and Lambda to be available about this time next year. Goetz said that you "can write any program that's worth it to write using Java," but that Java 8 will make it much easier to do so. His slide "Modernizing Java" talked about Java SE 8 "modernizing the Java language" and "modernizing the Java libraries." His last bullet on the slide stated, "Together, perhaps the biggest upgrade ever to the Java programming model." This has been my feeling and that's part of why I was surprised this presentation was not better attended.

Goetz stated that a lambda expression is "an anonymous method." It has everything that a method has (argument list, return type, and body) except for the name. It allows you to "treat code as data." A method reference references an existing method. Goetz reiterated the huge fundamental shift to writing and using libraries that will result from addition of lambda expressions.

Goetz pointed out that most languages did not have closures when Java started in 1995, but that most languages other than Java do have closures today. He then summarized some of the history of closures in Java in the slide titled "Closures for Java - a long and winding road." He referenced Odersky's and Wadler's 1997 "Pizza" (1997), Java 1.1's inner classes (1997), and the 2006-2008 "vigorous community debate about closures" (including BGGA and CICE). Project Lambda was formed in December 2009 and associated JSR 335 was filed in November 2010. It is "fairly close to completion" today.

Goetz stated that the for loop is "over-specified for today's hardware" while describing the "accidental complexity" associated with use of "external iteration" that we frequently use today. I agreed with the point he made that the "foreach loop hides complex interaction between client and library."

The goal of lambda expressions allows the "how" to be moved from the client to the library. Goetz emphasized that this is more than a syntactic change because the library is in control with lambda expressions and it is an internal iteration. Goetz stated, "The client handles the 'what' and the library handles the 'how' and that is a good thing." He added that lambda expressions have a profound effect on how we code and especially on how we develop libraries.

Goetz discussed the new forEach(Block) method added to collections using the new default implementation mechanism for Java interfaces. Goetz differentiated that Java has always had multiple inheritance of types (can implement multiple interfaces), is now (Java 8) going to have multiple inheritance of behaviors (default method implementation available for interfaces), but still won't have multiple inheritance of state (the last of which he describes as the most dangerous). Goetz had a slide dedicated to explanation of why "diamonds are easy" when you take date (state) out of the multiple inheritance.

Goetz had a nice slide summarizing "Default Methods - Inheritance Rules." This slide featured three rules. He pointed out that "if default cannot be resolved via the rules, subclass must implement it." Goetz pointed out that an interface could provide a "weak" default implementation and subclasses can provide better implementations.

Another advantage of default methods on interfaces is that the default implementation can throw an exception (such as UnsupportedOperationException) for optional methods so that subclasses not implementing the optional behavior don't need to do anything else. Goetz also showed how lambda expressions enable the addition of reverse() and compose() methods to Comparator.

Goetz showed several examples of code that illustrated that lambda expressions allow for "cleaner" and "more natural" representations. In his words, "the code reads like the problem statement" thanks to the composability of the lambda expression-powered operations. There is also "no mutable state in the client."

One of Goetz's slides had a quote I plan to use in the future: "Laziness can be more efficient." The context of this is that laziness can be more efficient if you're not going to use all of the results because you can stop looking once a match is determined. Stream operations are either intermediate (lazy) or terminal (naturally eager).

The Stream is an abstraction introduced to allow for addition of bulk operations and "represents a stream of values." Goetz's bullet cautioned that a Stream is "not a data structure" and "doesn't store the values." The aim here was to avoid noise in setting things up and try to be more "fluent."

Goetz stated that "one of Java's friends has always been libraries." He talked about how lambda expressions enable greater parallelism in the Java libraries. Goetz stated that fork-join is powerful but not necessarily easy to use. Goetz emphasized that "Writing serial code is easy; writing parallel code is a pain in the ass." Lambda expressions will still require parallelism to be explicit, but should be unobtrusive with lambda expressions and their impact on the libraries.

To emphasize Project Lambda's effect on parallelism in the libraries, Goetz showed a painful slide with how parallel sum with collections would be done today with fork-join and then another slide showing the much simpler use of lambda expressions. The point was made: much less code with lambda expressions, making the business logic a much larger percentage of the overall code.

Goetz introduced Spliterator as the "parallel analogue of Iterator." The Spliterator's prescribed behaviors are available to any object that knows how to split itself (Spliterable).

The slide "Lambdas Enable Better APIs" drove home the powerful and welcome effect of lambda expressions on the standard Java APIs. He emphasized that the "key effect on APIs is more composability.

Goetz stated that we typically prefer evolving programming model via libraries than language syntax for numerous reasons such as less cost, less risk, etc. He summarized his presentation by stating that times have changed and it is no longer a radical idea for Java to support closures.

One of the attendees asked why lambda expression method support is on the collections rather than on iterators. Goetz said that although C# did approach it from the iterator approach, his team found it less confusing for developers to have the methods on the collections instead of on the iterators.

In response to another question, Goetz stated that reflection on lambda expressions is not yet available due to its complexity. In response to another question, Goetz stated that lambda expression support is built with invokedynamic and method handles. This is part of an effort to make lambda expressions "fun to program" and "fast."

Another question led to a really interesting response from Goetz in which Goetz explained that the availability of internal iteration within a collection itself means the iteration complexity will be encountered by far fewer people (library developers rather than end user developers). Goetz encouraged attendees to run Java 8 drops currently available to help determine if Lambda expressions are being handled correctly. Goetz remarked, "The most valuable contribution we get from the community are people who say, 'I tried it out and found this bug.'"

Goetz started this presentation by stating that this was one in a long line of presentations at previous JavaOne conferences and other conferences on the state of lambda. What was different about this one, however, is that Project Lambda is "almost there" and, with that in mind, it seems that the syntax and concepts are largely in place. This obvious solidification of the APIs and syntax is welcome and this presentation met my very high expectations for it.

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 Fisher writes, "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 Scala instead. 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.2

The 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 Edition

After 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 12

Guava 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 JUnit

Tomek Kaczanowski has posted the slides he prepared "to persuade my colleagues to migrate from JUnit to TestNG" in his post Why TestNG and Not JUnit?

Scala or Java? Exploring Myths and Facts

The 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 Meetings

Jeffrey 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 Accept

In 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 Explained

Buddhika Chamith's post SSH Tunneling Explained is a detailed and illustrated overview of SSH tunneling.

Conclusion

This 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 Date and 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, and DateFormat/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 post Handling 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's Java 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 Specifications

Alex 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 Extended

Henrik 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 Updates

The 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 API

The 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 Community

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

Conclusion

The 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 Arithmetic

Joe 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 Releases

Speaking of new versions of Java, another Joe (Joseph Kulandai) started 2012 off with a nice post on Java 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 the code name of each release.

Java 8 Status Updates

Continuing 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 Concurrency

Niklas 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 Phaser and looks in detail at ThreadLocalRandom in the post Java 7: How to write really fast Java code.

OutOfMemoryError: Using Command-line Tools

Vladimir Š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 tools bundled 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 JVM

Attila 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 Introduction

Alex'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 Posts

I'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).

Conclusion

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

Conclusion

Smith'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 the C#/Scala-inspired syntax would look.

Goetz states reasons for selecting the syntax such as doing well by "subjective measures" and Java being 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.