JavaOne 2012: 101 Ways to Improve Java - Why Developer Participation Matters

Bruno Souza, Martijn Verburg, and Heather Vancura presented "101 Ways to Improve Java: Why Developer Participation Matters" in Continental Ballroom 4 of the Hilton. They split these up into their areas of greatest familiarity. Souza, the founder and coordinator of SouJava, talked about greater participation via user groups. Verberg, also heavily involved in user groups with the London Java Community and recently heavily involved in the Adopt-A-JSR program, talked about Java Specification Requests (JSRs) and adopting a JSR. Vancura [JCP Program Management Office (PMO)] talked about the greater Java Community Process (JCP) and contributing to that.

The 101 ways developers can participate in improving Java were divided among several categories such as "Ways to Improve Your Java User Group (JUG)," "Ways to Teach," "Ways to Help Java Open Source Project," "Ways to Adopt a JSR," and "Ways to Participate in JCP."

The ideas for ways Java developers can contribute to the improvement of Java ranged from very simple to more involved. Most, however, were highly approachable for the typical developer. One example from the improving JUGs category was to be a speaker or to provide a speaker from among one's colleagues. The idea here was that even if one did not want to speak, he or she could probably refer a great speaker. Another simple idea is to promote a Java Users Group via Twitter, Facebook, or other means.

Some of the ideas presented spanned categories. For example, writing a blog post could be an idea for furthering a Java User Group, for helping an open source project, for helping adopt a JSR, etc. I have blogged myself on how blogging can help other developers.

Other example of where ideas from different categories overlapped are any of the cases where helping an open source project is also helping a JSR because that open source project is the JSR's reference implementation. For example, previous work helping with Tomcat, GlassFish, or EclipseLink was helping the respective JSRs for which those projects are the reference implementations. Downloading OpenJDK 8 releases and using them, writing bug reports on them, and writing about them are all ways to help the OpenJDK project in particular and to help the development of JDK 8 in general.

Some ideas were almost as simple as falling off a log. For example, one can download the reference implementation (RI) of a JAR and try it out. Recounting one's favorite JavaOne experiences or lessons learned was another. Other easy ideas include simply requesting a new feature for a forthcoming JSR, writing a FAQ for a favorite or newly learned API or open source project, or even simply creating a simple web page listing available resources for more information on a particular subject.

The three speakers at this session reiterated that there are selfish motivations to improving Java. They were able to tie better Java user groups, better Java adoption, and so forth to benefits for all of us. They pointed out, for example, that if typical developers help with more mundane tasks such as open source project documentation and responding to questions in forums, others can focus on development of new libraries and language features. Verburg mentioned a couple of times that we probably want Brian Goetz focused on improving the lambda expressions implementation in JDK 8 and we can help by working on mundane things surrounding that so that he can focus on the implementation itself. Contributing to open source projects allows us to enjoy better tools and frameworks and greater selection of tools and frameworks.

The presentation slides were composed simply of the categories in which Java developers could help improve things with a list of bullets of the various ideas for each category. Those lists of ideas together obviously form one of the most important parts of the presentation and hopefully the presentation with those lists will be available online soon. Rather than regurgitate that list here, I have focused on a high-level description of the voice track the speakers provided to accompany the slides and lists of ideas. UPDATE - Vancura has made the list of all 101 ideas available on the JCP Program Office blog.

One of the early themes already encountered frequently at JavaOne 2012 is the need for Java developers to contribute to the community and the success of Java and the Java ecosystem. Speakers from the Strategy Keynote and Technical Keynote repeatedly asked for community help and feedback and I have seen that theme expressed in other sessions of JavaOne already.

JavaOne 2012: NetBeans.Next - The Roadmap Ahead

I walked the few steps necessary from Continental Ballroom 4 and one NetBeans topic (Project Easel) to Continental Ballroom 5 to see another NetBeans-oriented presentation: "NetBeans.Next - The Roadmap Ahead."

Ashwin Rao started the Birds of a Feather (BoF) presentation and introduced John Ceccarelli and Tinuola Awopetu. Several audience members attended yesterday's NetBeans Community Day. Rao showed the typical Oracle disclaimer slide about outlining "general product direction," but in this case (roadmap) it did seem particularly relevant.

Rao talked about the "Motivation for Roadmap." This motivation includes "providing best end-to-end development experience for Java platform" and supporting various Java releases as well as "HTML5 and popular languages and frameworks that complement and co-exist with the Java platform." He added that two main forces drive the NetBeans Roadmap: "Industry and Technology Trends" and the "Java Platform Roadmap."

Rao introduced the topic of ways to determine industry and technology trends including market analysis and community engagement. Awopetu then talked about how the community can use bug reports and RFEs (requests for enhancements) to relay to the NetBeans team the level of priority to apply to bugs and enhancements. She added that NetCAT (NetBeans Community Acceptance Testing program) is a main driver of what they work on. NetCAT users have contributed as many as 7,000 bugs/enhancements. Awopetu also stated that user satisfaction surveys and monitoring forum posts over the past 18 months have helped give them an idea of what the community wants in NetBeans.

I was pleased to hear Ceccarelli state that they will be tackling NetBeans's known memory issues in the same way that they have tackled the scanning issues in NetBeans 7.2. It was pointed out that there is a command-line switch that can be used with NetBeans Rich Client Platform in production.

One of the main motivations I had in attending this session was a peek at the road ahead. This chart came toward the end and was titled "The Road Ahead." Rao talked about NetBeans 7.3 (advanced HTML5 tooling, Oracle Public Cloud, and Java ME 3.2 and Embedded). He also cited Java EE 7 support (Avatar) and NetBeans JDK 8 support (Lambdas, JavaFX 8, and Java ME 8 and Embedded), and NetBeans JDK 9 support (Jigsaw).

One audience member expressed interest in NetBeans supporting specific cloud vendors and warning when code is not compliant with a particular cloud provider. The lack of standardization in cloud is reminiscent of the lack of standards implementation in web development in the past and even to some degree today. Therefore, it's not surprising that this would be a desirable feature to have.

Another audience member wondered about a tool for code collaboration. I was interested in this question because I would love to see a NetBeans equivalent of the Code Collaborator plugin for Eclipse. It was explained that Kenai was a sponsored project that became Java.net, but Java.net support does not include code collaboration. It was stated that it is relatively easy to write GUI for code collaboration, but the repository is what is difficult. NetBeans will support Oracle Cloud ALM tools and there is some consideration of Github support.

There is no plan to add WYSIWYG support for HTML/CSS/JavaScript to NetBeans and the audience seemed to be fine (and even welcome) that. It was explained that it is easier to do this with GWT, Oracle ADF, or other known deployments. It is difficult enough to make the editor work with JavaScript.

Discussion of "Top Feature Requests" with no delivery plans focused on three features not anticipated for NetBeans at this time:

• UML
• Visual Web
• Android/IOS

There was a large percentage of those in attendance who expressed interest (even if forced by employers and clients) in UML support. Based on this support, it was stated that "reports of UML death are overrated." It was also expressed that they would like to move JDeveloper's UML into NetBeans. The team has moved much NetBeans functionality into JDeveloper, so this would be other direction. JDeveloper UML has been heavily used, but the many complaints about it led the NetBeans team to think it wasn't wanted in NetBeans. For times I need to create UML, I too would like to see UML support available again in NetBeans. UPDATE - Apparently IntelliJ IDEA users also use UML frequently.

Although NetBeans will not provide native support for Android or iOS, it was pointed out that there is a community Android plugin for NetBeans. Also, the NetBeans team may add PhoneGap support (PhoneGap allows for HTML/CSS/JavaScript to be used to write applications to 7 native mobile device formats) for Project Easel at some point in the future.

Ceccarelli stated that his "job now is not to make NetBeans successful, but to make Java successful." He added that the "Java IDE wars are over." Each of the IDEs has pieces of other IDEs in it now. One of the compelling things for NetBeans in the short-term future will be the availability of HTML5 support in NetBeans with Project Easel.

JavaOne 2012: NetBeans - Project Easel

The JavaOne 2012 conference materials listed this presentation as "Project EASEL: Developing and Managing HTML5 in a Java World," but the title slide posted as we wait for the session to begin is titled "NetBeans - Project Easel." The authors and presenters listed on that title slide are John "JB" Brock, John Jullion-Ceccarelli, and David Konecny. This was my fifth presentation on Monday (5 for 5 so far) to be held in the Hilton, but it was in a new room this time (Continental Ballroom 4).

John Brock (who goes by JB) introduced and gave the presentation. David Konecny was also at the table and John Ceccarelli contributed a Tweet about JB that was picked up by their example client that accessed the Twitter API. They began by covering "what Project Easel is not" and what it is. Brock said that Project Easel is NOT a WYSIWYG editor. He emphasized that it does not compete with JavaFX, but rather is a tool to use when working with CSS and JavaFX. Brock added that Project Easel is not a web designer and so doesn't compete with PhotoShop or other such applications.

Brock summarized what Project Easel is. It is for client side projects and leverages "new WebKit internal and external browser synchronization." It has a "new JavaScript editor with smart code completion" and includes support for jQuery and a "new JavaScript debugger." The debugger is based off of WebKit's remote debugging API. Project Easel is intended to help developers build responsive designs.

Brock only had a few slides and then moved into code and IDE demonstration. He showed how online templates could be downloaded as a starting point and he pointed out that an organization could generate its own template as a common starting point. Brock demonstrated some of the features of the project once a template was downloaded.

Project Easel allows the application to be run off the file system, but also includes a lightweight embedded HTTP server to run JavaScript and other code against. If there is a pre-running server on the same local machine, it can be selected and used.

Brock showed HTML code in the Project Easel editor and pointed out how the IDE treats HTML code the same way we expect in Java code. For example, he showed closing elements and opening elements being visually marked when one was highlighted. The editor has built-in support for HTML5 elements/tags. Hovering over these displays help for using that tag.

Brock stated that Project Easel was designed around the dual browser concept. This means that edits made in the IDE can be reflected in the Chrome browser. Brock differentiated this from using Firebug or Chrome developer tools because Project Easel supports direct changes to the code being reflected in the browser. This is different from making the changes locally in the browser and then having to make them again in the source code once it is determined that the changes address the issue.

One of the powerful features that Brock demonstrated was the ability to click the yellow light bulb icon familiar to NetBeans developers to add CSS styling to any selected CSS style sheet. Brock pointed out that each CSS attribute has a help screen in Project Easel that shows icons for the browsers supporting that particular CSS attribute. If a browser does not support that attribute, its icon is grayed out. One of the most frustrating aspects of web development is browser idiosyncrasies and differing levels of support, so this is is helpful idea. A challenge will remain as far as documenting support for certain attributes across different versions of the same browser.

Because Project Easel uses WebKit's debugging API, the example Brock was demonstrating had the warning banner across the top in bold yellow stating "NetBeans IDE Support Plugin" is debugging this tab." Brock explained that Google Chrome does this anytime debugging is occurring.

Brock showed how Project Easel allows the developer to change the presentation of $ used with jQuery to "JQuery" in an effort to help someone less familiar with jQuery to see what is happening. It doesn't affect the code itself, but merely presents it differently. This feature is page-only and does not affect the entire application.

I liked Brock's statement, "In the world of REST, you're going to get a chunk of something and need to go figure out how to deal with it." He used this as a segue into discussing how to use the Project Easel debugger to ascertain what's available in a RESTful response.

Brock demonstrated the Project Easel capability to generate a JavaScript-based REST client using MVC.

Brock referenced Twitter Bootstrap and explained how building the example application on this enabled it to automatically resize and reposition pieces of the page based on the size of the browser. The main page for Twitter Bootstrap defines it as, "Sleek, intuitive, and powerful front-end framework for faster and easier web development."

Brock also referenced use of the Backbone.js JavaScript library. This library's main page describes it: "Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface."

In response to a question, Brock stated that version 1 ("which we hope to release in the next week or so") of Project Easel requires the HTML5 project to be used in NetBeans. Brock also reminded the audience that of all of the IDEs that Oracle contributes to (NetBeans, JDeveloper, Oracle Enterprise Pack for Eclipse), NetBeans is the IDE that gets to try out new features. Brock acknowledged that it'd obviously be nice to have Project Easel capabilities in JSF and other non-HTML5 projects (I was thinking this of JavaFX).

In response to another question, Brock stated that Project Easel is aimed at client-side GUIs. It can obviously be deployed to any application servers via WAR files, but the tool's benefit is for client side coding (HTML/CSS/JavaScript).

Brock stated, in response to a question, that the only thing in his demonstration that was HTML5 is drag-and-drop. He says most of it runs on any browser, but the CSS "is what messes you up." He called CSS support across browsers "iffy." An interesting anecdotal story he relayed was that the box shadow started working during his work on the demonstration as Chrome received an update. He said it is "the Wild Wild West" and that they're "shooting from the hip" in trying to stay current with various browsers' support for CSS.

Not surprisingly, Brock mentioned in response to another question that they likely won't add support for browers other than the main ones already covered in Project Easel. In other words, Project Easel probably won't add information on any new browsers related to their support of different CSS mechanisms.

In case it is not obvious, Brock pointed out in response to a different question that Project Easel is tied to NetBeans. He said he is planning on it being made available in the future in JDeveloper, but cannot comment on whether it will become available for Oracle Enterprise Pack for Eclipse. I hope the day comes when NetBeans's support for JavaFX and for Project Easel are all available together.

This session started out about only half-full, but people kept streaming in throughout. With numerous people coming in late and few if any people leaving, it got fairly full. Although this conference room is significantly smaller than Plaza A/B, it is still obvious that Project Easel interests numerous people.

JavaOne 2012: Looking into the JVM Crystal Ball

I returned to Plaza A/B in the Hilton to attend the fourth session on Monday, but first went up to the top floor of the Hilton to pick up lunch. I'm reminded every year on the first day of JavaOne how surprisingly frustrating the first day's lunch acquiring process is for everyone involved. I know I found the experience a little confusing my first year at JavaOne as I wasn't sure where the lunches were available and I wasn't aware of the ticket for lunch included with my badge (that's what I get for my not reading the instructions first mentality). There was obvious confusion today as I heard people asking, "What ticket?" when asked to produce their lunch tickets. It didn't help that those trying to organize the hungry horde advised us to stay away from the top of the escalator, but didn't know exactly where we should go instead.

Mikael Vidstedt and Staffan Friberg presented "Looking into the JVM Crystal Ball." They stated that the two primary areas of coverage for this presentation are technical VM details and the VM roadmap. An early slide, "VM Convergence," talked about the convergence of JRockit and HotSpot as well as the CDC (Jave ME) and HotSpot Embedded convergence.

A slide on "Serviceability: Introspection and Analysis" talked about desire for "unified logging" (JEP 158) and "native memory tracking." Another slide with the same title talked about "Java Flight Recorder and Java Mission Control" that is a licensed feature in JRockit that will be available in HotSpot (still as a licensed feature).

A "Just Say Java" bullet refers to intent to "remove artificial memory limits and required tuning" and to "reduce the complexity of tuning the garbage collector." The end goal is a "single scalable VM for both client and server" using a "multi-tiered optimizing compiler." Another slide with the same "Enterprise: Server Java" title talked about "instant performance," "low latency garbage collector," and big data (requiring big heaps).

"Cloud and Virtualization: Multi Tenancy" was the title of a slide talking about "dynamic scaling and on-demand availability," maintaining "full isolation" and maximizing "resource utilization."

The "Developer Experience: Continued Improvement" slide referenced the value of multiple languages supported on the virtual machine. The slide and speaker also referenced improving the development experience with "dynamic development and debugging" through "close cooperation with IDE developers."

A JEP is a Java Enhancement Proposal and JEPs document via community process what is to be added to the virtual machine. It was stated in this session that the JVM can now be scaled from the small Raspberry Pi to the huge Exalogic T3-1B. The point was made that many of the things that benefit one of these extremes also benefit the opposite extreme and everything in between.

The "Footprint: Every byte counts!" slide covered some examples of features of the embedded JVM that the HotSpot VM developers are working to add to the HotSpot VM. These include "compact JVM internal structures" (JEP 147) and "dynamic sizing" of "interned string table," "system dictionary," and "caches." Both enterprise and embedded extremes benefit from these changes.

In conjunction with the bullet "Java Heap is 'Easy'," there was mention of HPROF and Java Mission Control. Native Memory Tracking is "really useful for hunting footprints in general."

JSR 292/JEP 160 (invokedynamic had some issues (NoClassDefFoundError) in its initial release, but they believe these issues have been addressed. As was stated in The Road to Lambda earlier today, Project Lambda is using invokedynamic. The point was made that this is evidence that invokedynamic is not just for "alternate JVM languages," but is useful for the Java language itself. Project Nashorn will also benefit from invokedynamic.

Three actions were outlined that optimize for multiple languages. These are "inlining" (all of which is done upfront today, but they'd like to enable compiler to incrementally inline), "escape analysis improvements" (analysis of ways to improve code), and "boxing elimination" (avoid extraneous object creation). JEP 165 deals with "fine-grained compiler control" and JEP 143 exists to improve lock contention.

There was discussion of the slide "G1 - Garbage First: The Future of Garbage Collection." It was explained that this changes the approach from "one ginormous Java heap" to heap treated as "many small parts." The -XX:+UseG1GC option was mentioned as a way to try out this new garbage collector as of JDK 7 Update 4. JEP 144 is designed to reduce garbage collection latency for large heaps.

"PermGen is no more!" is a bullet on the slide on the new JVM memory layout anjd is a result of JEP 122. This change is supposed to be "transparent to user," but they would like Java developers to try it out to make sure the change is truly invisible.

JEP 159 deals with "Enhanced Class Redefinition." They would like to relax today's "redefinition using java.lang.instrument, JVMTI, etc." to more than just redefining code body.

Another direction for the JVM developers is toward heterogeneous computing. "GPUs are very powerful and more available than in the past." Project Sumatra attempts to support GPUs and Arrays 2.0 concept.

The point was made that "the Cloud makes the deployment environment more fluid," but that "the JVM is in a unique position to help." Their goal is to ensure that the JVM can pick up cloud-related changes and maintain isolation.

It was pointed out that "a nice outcome of the removal of the Permanent Generation" is that "Class Data Sharing" now can work with all garbage collectors rather than working only with the serial collector. JEP 145 aims to reduce start-up time and to reduce warm-up time of a Java application.

It was emphasized several times in this presentation that developers can help test out and drive fixes and improvements by downloading the latest versions of the VM and language compiler, trying them out, and providing feedback. The JDK8 early access builds are available for download and the versions without permanent generation should be available soon.

JavaOne 2012: A Walk Through of Groovy's AST Transformations

I made the very short walk from Hilton Plaza A/B back to Hilton Golden Gate 3/4/5 to see the presentation "Walk through Groovy's AST Transformations." Groovy's AST Transformations are something I've dabbled with directly a few times, but have more often benefited from others' work with them. I had started reading the Packt Publishing book Groovy for Domain-Specific Languages, but wanted to attend this presentation to reinvigorate my interest and kick-start my increased use of this powerful tool.

Andres Almiray (Canoo) presented this presentation on Groovy AST Transformations. It did not surprise me that most of the audience had Groovy experience given that use of Groovy ASTs is likely more appealing to those with some familiarity with Groovy already.

Almiray defined AST Transformations as "essentially byte code generation" that "enables compile-time metaprogramming." He showed that Groovy has two types of AST Transformations: global and local. The focus of today's presentation is on global AST transformations.

The AST Transformations framework was added to Groovy years ago, but things were made much easier in Groovy 1.7. Almiray covered the Delegate Transformation (@Delegate annotation) in Groovy allows the compiled code to have all of the public methods of the field that was explicitly delegated to. Almiray explained that @Delegate works with interfaces as well as classes. Almiray also explained that any new method defined will take precedent over any delgate method of the same signature. Similarly, the first delegate encountered takes precedent over same method signature of other delegates.

Almiray then covered @Singleton and the Singleton Transformation. Almiray stated that the singleton implemented with this transformation meets the definition of a safe singleton described in Josh Bloch's Effective Java.

@Immutable (the Immutable Transformation) was covered next. Just as the @Singleton transformation automatically implemented all necessary rules for singletons, the @Immutable transformation implements the rules for immutable. Almiray noted that there are different exceptions for attempts to set a property on an immutable Groovy class via property set versus method set.

The next Groovy AST transformation to be covered was @Category (the Category Transformation). This was the first covered transformation that requires usage within Groovy code (not within Java code) to be fully used. The Mixin Transformation (@Mixin) was also covered.

Almiray moved onto coverage of @Grab (Grab Transformation), one which I have posted about before. @Grab is useful for downloading dependencies at runtime. I like it for the same reason that Almiray mentioned: "it's perfect for self-contained scripts."

Almiray introduced the @Synchronized (Synchronized Transformation) as a Groovier way to specify synchronized blocks. Almiray covered the @Lazy (Lazy Transformation), which is used to only initialize values when actually needed (when first used). Almiray pointed out Groovy's ability to access classes' private fields and cautioned that this should only be used for unit testing and only when absolutely necessary in production.

Almiray demonstrated use of @Newify (Newify Transformation) before showing a code sample using @Bindable (Bindable Transformation), which he stated was added to Groovy to make use of Swing easier. The transformation makes a class observable and removes the need to write all the code for explicitly doing this. The @Vetoable transformation similarly makes it easier to veto a property change.

As I described in my post Easy Groovy Logger Injection and Log Guarding, @Log (Log Transformation) can be very useful (as are @Commons, @Log4j, and @Slf4j).

Almiray covered some of my favorite and most often-used Groovy transformations: @ToString (see my post), @EqualsAndHashCode (see my post), @TupleConstructor (see my post), or the combination of them all (@Canonical - see my post).

Following coverage of @Canonical and its constituent transformations, Almiray moved onto covering @IndexedProperty (related post). He then listed several others without code samples: @AutoClone, @AutoExternalize, @ConditionalInterrupt, @TimedInterrupt, @ThreadInterrupt, @PackageScope ("gain back package-level access specificity in Groovy"), @WithReadLock, @WithWriteLock, and @Field ("mostly used inside scripts").

I was happy to see Almiray mention the addition of @TypeChecked to support "static Groovy!" He referenced a later presentation on new features of Groovy 2.0 to get more details.

Almiray mentioned new transformations specific to Grails (@Entity) and to Griffon (@EventPublisher, @PropertyListener, @Treading, and more). He referenced @Scalify and @Bytecode as well.

Although I was already familiar with a large percentage of the Groovy AST transformations covered in this presentation, it was still worthwhile to attend and learn of or be reminded of other useful transformations that are available.

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.

JavaOne 2012: How Do Non-Blocking Data Structures Work?

I was a little surprised when I looked at my schedule for today and noted that all of the sessions I have currently planned to see today are in the Hilton. This became a little less surprising when I realized that about half of the JavaOne presentations are in the Hilton and that they seem to be roughly located by track.

Tobias Lindaaker's (Neo Technology) presentation "How Do Atomic Data Structures Work?" was held in the Hilton's Golden Gate 3/4/5 conference room area. Lindaaker changed his presentation's title since he originally submitted the abstract. The abstract's title (and that listed in the conference materials) was "How Do Atomic Data Structures Work?," but he has renamed it to "How Do Non-Blocking Data Structures Work?"

Lindaaker explained that "atomic" comes from Greek and meaning "undividable." He explained that a "lock-free data structure" is "a data structure that does not block any threads when performing an operation on the data structure (read or write)." He stated that one wants to avoid "spin-waiting" whenever possible.

Lindaaker talked about synchronized regions. He said such regions "create a serialized path through the code" and "guarantee safe publication." He defined "safe publication" as meaning "everything written before exiting synchronized [block]" and "guaranteed to be visible on entry of synchronized [block]." One of his bullets stated, "volatile fields give you safe publication without serialization." Lindaaker focused more on the volatile keyword modifier in his "volatile fields" slide.

The slide "What is a memory barrier?" provided a simple visual representation of the memory barrier concept.

For his slide "Atomic updates," Lindaaker stated that the easiest way to access an atomic reference is via use of java.util.concurrent.atomic.AtomicReference<V>. Lindakker provided a physical demonstration using coasters to illustrate the difference between compareAndSet (sets a value if the conditional matches favorably) and getAndSet. (sets new value returns old value).

Lindaaker prefers java.util.concurrent.atomic.AtomicReferenceFieldUpdater<T,V> because of its "lower memory overhead" ("fewer object headers") and "better memory locality" ("no reference indirection").

Lindaaker explained that array-based queues do block (sometimes a benefit when amount of work needs to be limited due to finite hardware resources), linked queues do not block. Lindaaker used a supermarket queue as an example of the differences. In the link-based queue, you always stand behind the same customer in front of you in the queue. In the array-based queue, you always remain in the same position. Bounded queues "frequently perform better," but will block when full.

One of the main themes of this presentation was the idea of learning new ideas and then individually researching them further. Lindaaker recommended that audience members look at the JDK's code to see some impressive and less impressive code examples.

Lindaaker referenced LMAX (London Multi Asset Exchange) Disruptor as an example of a "ring buffer" ("array with a read mark and a write mark"). He stated that "readers contend on the read mark, writers on write mark" and highlighted the consequence of this, "With single reader / single writer, there is no contention." The Disruptor page describes Disruptor as a "High Performance Inter-Thread Messaging Library."

Lindaaker stated that java.util.concurrent.ConcurrentHashMap is a good general choice, but is not very exciting for discussion in his presentation. He stated that it "scales reasonably well on current commodity hardware" (fewer than 100 CPUs) with proper tuning.

Neo Technology provides a database implementation (Neo4j) that is not relational (graph database). Lindaaker described the Neo Technology's graph-based database offering as, "Stores data as nodes and relationships between nodes."