A couple of weeks ago I wrote a summary of 7 new cool features in Java 7. Others have written great blog posts about them, so I was thinking it might be useful for me to focus on lesser known or “Hidden Java 7 Features”. In the next few weeks, I’ll try to explore and write a series of blog posts about them.

System and Process CPU Load Monitoring

Java 7 provides a new MBean that finally allows Java developers to access overall System and current process CPU load monitoring. This feature is not really that hidden as it’s listed in the what’s new page for JDK 7, but I haven’t really noticed a lot of talk about it and I certainly overlooked it initially.

The interface com.sun.management.OperatingSystemMXBean, has two new methods that easily get this information; getSystemCpuLoad() and getProcessCpuLoad(). Both methods return the load as a double value in the [0.0,1.0] interval, with 0.0 representing no load to 1.0 representing 100% CPU load for the whole system or the current JVM process respectively.

It’s pretty easy to get access to this MBean;

import com.sun.management.OperatingSystemMXBean;
...
OperatingSystemMXBean osBean = ManagementFactory.getPlatformMXBean(
                OperatingSystemMXBean.class);
// What % CPU load this current JVM is taking, from 0.0-1.0
System.out.println(osBean.getProcessCpuLoad());

// What % load the overall system is at, from 0.0-1.0
System.out.println(osBean.getSystemCpuLoad());

Wasn’t this already available?
Java 6 introduced a new method in java.lang.management.OperatingSystemMXBean called getSystemLoadAverage(), which could get the CPU average for the overall system (there wasn’t a mechanism for the JVM/current process load). However this doesn’t seem to work on Windows and would just return a -1 (tried this with Java 7 in Windows 7 and that is still the case).

Other ways of doing this prior to Java 7 would include Java APIs implemented via native libraries like SIGAR, which are good alternatives but obviously not part of the standard Java distribution, or may not support most platforms.

Now the bad news
If you notice in my code I use com.sun.management.OperatingSystemMXBean, not java.lang.management.OperatingSystemMXBean which means the methods getSystemCpuLoad() and getProcessCpuLoad() are not part of the official, supported public interface of the Java Platform. Oracle actually discourages the use of these packages, since they could be removed in future releases or may not be available in all JVM implementations.

I’m not 100% sure why these methods were only added to the com.sun version of OperatingSystemMXBean. Initially I thought it was because Oracle didn’t want to add a method to a public interface (which would break any code implementing that interface), however Java 6 added getSystemLoadAverage(). If anybody has any insight on this, please let me know.

There are ways to use these new methods without having a hard dependency to these com.sun classes (for example via reflection, or using JMX conventions), I may cover these in a future blog post or update to this one.

Demo, JCPUMon
Finally, I wanted to do a simple UI that would use this feature to have a little widget to monitor system CPU and current process load graphically. I call it “JCPMon”, it can be launched as a standalone Java application, run inside an application you want to monitor or just used as a Swing component in a Java UI.

The green part of the graph represents the overall system CPU load, while the yellow part represents the current process load, in this case CPU load imposed by the GUI (I did a lot of resizing to get a few yellow bars for this image ). If you want to monitor a Java application you already have, you can easily do so by calling;

// This method won't block, so you can call it at the start of your program
com.sellmic.apps.monitoring.jcpumon.Main(null);

// And then continue doing anything else ...

Of course an improvement would be to have the ability to connect to an external process via JMX (remote or local).

You can launch this app via webstart, .You’ll need Java 7 to be installed.

This simple GUI uses this new Java 7 capability and also has some extras to configure the look of the UI (squares or circles, size, how often to update, always on top, full screen). If anybody is interested in the code for this let me know and I can setup a page to host it.

UPDATE: JNLP URL was wrong, if you tried webstart before and it failed please try again. Sorry about that!

The evolution of the Java language and VM continues! Mark Reinhold (Chief Architect of the Java Platform Group) announced yesterday that the first release candidate for Java 7 is available for download, he confirms that the final released date is planned for July 28.

For a good overview of the new features and what’s coming next in Java 8, I recommend this video on the Oracle Media Network, which features Adam Messinger, Mark Reinhold, John Rose and Joe Darcy. I think Mark sums up Java 7 very well when describing it as an evolutionary release, with good number “smaller” changes that make for a great update to the language and platform.

I had a chance to play a bit with the release candidate (made easier by the Netbeans 7  JDK 7 support!), and decided to list 7 features (full list is here) I’m particularly excited about. Here they are;

1. Strings in switch Statements (doc)

Did you know previous to Java 7 you could only do a switch on char, byte, short, int, Character, Byte, Short, Integer, or an enum type (spec)? Java 7 adds Strings making the switch instruction much friendlier to String inputs. The alternative before was to do with with if/else if/else statements paired with a bunch of String.equals() calls. The result is much cleaner and compact code.

    public void testStringSwitch(String direction) {
        switch (direction) {
             case "up":
                 y--;
             break;

             case "down":
                 y++;
             break;

             case "left":
                 x--;
             break;

             case "right":
                 x++;
             break;

            default:
                System.out.println("Invalid direction!");
            break;
        }
    }

2. Type Inference for Generic Instance Creation (doc)

Previously when using generics you had to specify the type twice, in the declaration and the constructor;

List<String> strings = new ArrayList<String>();

In Java 7, you just use the diamond operator without the type;

List<String> strings = new ArrayList<>();

If the compiler can infer the type arguments from the context, it does all the work for you. Note that you have always been able do a “new ArrayList()” without the type, but this results in an unchecked conversion warning.

Type inference becomes even more useful for more complex cases;

// Pre-Java 7
// Map<String,Map<String,int>>m=new HashMap<String, Map<String,int>>();

// Java 7
Map<String, Map<String, int>> m = new HashMap<>();

3. Multiple Exception Handling Syntax (doc)

Tired of repetitive error handling code in “exception happy” APIs like java.io and java.lang.reflect?

try {
    Class a = Class.forName("wrongClassName");
    Object instance = a.newInstance();
} catch (ClassNotFoundException ex) {
    System.out.println("Failed to create instance");
} catch (IllegalAccessException ex) {
    System.out.println("Failed to create instance");
} catch (InstantiationException ex) {
   System.out.println("Failed to create instance");
}

When the exception handling is basically the same, the improved catch operator now supports multiple exceptions in a single statement separated by “|”.

try {
    Class a = Class.forName("wrongClassName");
    Object instance = a.newInstance();
} catch (ClassNotFoundException | IllegalAccessException |
   InstantiationException ex) {
   System.out.println("Failed to create instance");
}

Sometimes developers use a “catch (Exception ex) to achieve a similar result, but that’s a dangerous idea because it makes code catch exceptions it can’t handle and instead should bubble up (IllegalArgumentException, OutOfMemoryError, etc.).

4. The try-with-resources Statement (doc)

The new try statement allows opening up a “resource” in a try block and automatically closing the resource when the block is done.

For example, in this piece of code we open a file and print line by line to stdout, but pay close attention to the finally block;

        try {
            in = new BufferedReader(new FileReader("test.txt"));

            String line = null;
            while ((line = in.readLine()) != null) {
                System.out.println(line);
            }
        } catch (IOException ex) {
            ex.printStackTrace();
        } finally {
            try {
                if (in != null) in.close();
            } catch (IOException ex) {
                ex.printStackTrace();
            }
        }

When using a resource that has to be closed, a finally block is needed to make sure the clean up code is executed even if there are exceptions thrown back (in this example we catch IOException but if we didn’t, finally would still be executed). The new try-with-resources statement allows us to automatically close these resources in a more compact set of code;

       try (BufferedReader in=new BufferedReader(new FileReader("test.txt")))
       {
            String line = null;
            while ((line = in.readLine()) != null) {
                System.out.println(line);
            }
        } catch (IOException ex) {
            ex.printStackTrace();
        }

So “in” will be closed automatically at the end of the try block because it implements an interface called java.lang.AutoCloseable. An additional benefit is we don’t have to call the awkward IOException on close(), and what this statement does is “suppress” the exception for us (although there is a mechanism to get that exception if needed, Throwable.getSuppressed()).

5. Improved File IO API (docs 1, 2)

There are quite a bit of changes in the java.nio package. Many are geared towards performance improvements, but long awaited enhancements over java.io (specially java.io.File) have finally materialized in a new package called java.nio.file.

For example, to read a small file and print all the lines (see example above);

       List<String> lines =  Files.readAllLines(
       FileSystems.getDefault().getPath("test.txt"), StandardCharsets.UTF_8);

       for (String line : lines) System.out.println(line);

java.nio.file.Path is an interface that pretty much serves as a replacement for java.io.File, we need a java.nio.file.FileSystem to get paths, which you can get by using the java.nio.file.FileSystems factory (getDefault() gives you the default file system).

java.nio.file.Files then provides static methods for file related operations. In this example we can read a whole file much more easily by using readAllLines(). This class also has methods to create symbolic links, which was impossible to do pre-Java 7. Another feature long overdue is the ability to set file permissions for POSIX compliant file systems via the Files.setPosixFilePermissions method. These are all long over due file related operations, impossible without JNI methods or System.exec() hacks.

I didn’t have time to play with it but this package also contains a very interesting capability via the WatchService API which allows notification of file changes. You can for example, register directories you want to watch and get notified when a file is added, removed or updated. Before, this required manually polling the directories, which is not fun code to write.

For more on monitoring changes read this tutorial from Oracle.

6. Support for Non-Java Languages: invokedynamic (doc)

The first new instruction since Java 1.0 was released and introduced in this version is called invokedynamic. Most developers will never interact or be aware of this new bytecode. The exciting part of this feature is that it improves support for compiling programs that use dynamic typing. Java is statically typed (which means you know the type of a variable at compile time) and dynamically typed languages (like Ruby, bash scripts, etc.) need this instruction to support these type of variables.

The JVM already supports many types of non-Java languages, but this instruction makes the JVM more language independent, which is good news for people who would like to implement components in different languages and/or want to inter-operate between those languages and standard Java programs.

7. JLayerPane (doc)

Finally, since I’m a UI guy, I want to mention JLayerPane. This component is similar to the one provided in the JXLayer project. I’ve used JXLayer many times in the past in order to add effects on top of Swing components. Similarly, JLayerPane allows you to decorate a Swing component by drawing on top of it and respond to events without modifying the original component.

This example from the JLayerPane tutorial shows a component using this functionality, providing a “spotlight” effect on a panel.

You could also blur the entire window, draw animations on top of components, or create transition effects.

And that’s just a subset of the features, Java 7 is a long overdue update to the platform and language which offers a nice set of new functionality. The hope is the time from Java 7 to 8 is a lot shorter than from 6 to 7!

JavaFX Script is officially dead.

Oracle has decided to continue investing in JavaFX as the UI platform for Java client applications, but at the same time they’ve realized that the JavaFX Script language was probably a limiting factor in the general adoption of their RIA technology.

History

On November 8, 2006, Sun engineer Chris Oliver published an entry in his blog introducing a project he had been working on called “F3″. His blog entry explained the general concepts behind the project;

My name is Chris Oliver. I came to Sun through their acquisition of Seebeyond in September 2005. I’d like to present something about my current work – it’s not public yet but it should be open-sourced on java.net shortly.

My project is called F3 which stands for “Form follows function”, and its purpose was to explore making GUI programming easier in general.

F3 is actually a declarative Java scripting language with static typing for good IDE support and compile-time error reporting (unlike JavaScript…), type-inference, declarative syntax, and automatic data-binding with full support for 2d graphics and standard Swing components as well as declarative animation. You can also import java classes, create new Java objects, call their methods, and implement Java interfaces.

Chris’ first blog post on F3 introduced code snippets showing off the main features of the language, and a follow up post had a set of very impressive demos meant to show off the language and how it could compete with other RIA technologies like Flash.

At JavaOne 2007 F3 was rebranded as JavaFX Script, and we were shown some cool demos, like this JavaFX PDF Reader which unfortunately was never released.

JavaFX 1.0 was released on December, 2008.

At JavaOne 2009, Sun showed off a much needed JavaFX designer tool. The demo showed how the tool would allow for visual design of JavaFX applications on different “screens” (desktop, mobile, TV, etc.). This tool hasn’t been released to the public, instead there’s a more developer oriented Netbeans plugin with Matisse like UI design capabilities that was released a while ago.

But it’s not Java

The complaint I would often hear from developers when talking about JavaFX is that it was not Java. Unlike Java, F3 was designed from the beginning with UIs in mind. Chris Oliver wanted the flexibility of a declarative language, and decided that XML was not the best fit for this, thus the need for the F3 language.

The problem was that the new language was very different from Java. I remember doing a JavaFX Script presentation for a JUG in Panama, and even after having written a few programs in it, the context switch between it and Java was quite big for me.

At the last JavaOne I attended, I could overhear a lot of people rejecting the idea of learning yet another new language just to do a Java based UI. Not only a new language, but one that was so different from what they were used to. People often forget that one of the reasons Java dominates the development landscape today is because it was so similar to it’s predecessors; C and C++. While the benefits of a new UI focused language are many (the binding features alone in JavaFX Script are a good example), one thing that I’ve noticed is that modern UIs are being done in less exotic ways; just take a look at the UI framework in Android which is Java language based and on iPhone which uses Objective C.

JavaFX technology in Java, and other languages

Oracle has published the proposed roadmap for JavaFX 2.0. The key standout feature listed there is “Port JavaFX Script APIs to Java”, which will make JavaFX not only easily available to Java developers but to those who use other dynamic languages like Scale, JRuby, Groovy, Javascript, etc. The roadmap also mentions support for lambda expressions (closures), which I can already see being very useful for UI programming.

There are other notable features listed there, like additional UI controls, web views and integration with HTML5, HD playback, etc. The roadmap mentions the binding API, I’m curious to see how it would be integrated in the core Java language.

I think Oracle has made the right move here, the JavaFX stack is already pretty advanced and shows a lot of promise. It should be used more, but was being hindered by the lack of adoption of JavaFX Script. Porting these APIs to Java, and supporting other dynamic languages should allow a lot more developers to leverage the power of JavaFX.

Sorry for the long post, but I wanted to include a bit of history at the beginning about F3. I wonder how Chris Oliver and the other engineers that worked so hard on the core JavaFX Script language feel about this development. Hopefully they feel pretty proud about their work, because even though the language is being dropped, it seems the core of JavaFX is pretty strong. Adoption should grow now that there is no “new language” excuse.

At least that’s what I’m hoping for.

“The classpath is dead“ … that’s what Mark Reinhold (Principal Engineer @ Sun) said at a general session during JavaOne 2009. It’s the type of statement that should resonate with any of us who have been victims of classpath/jar hell. Mark announced this in the context of reviewing the new language features due to be released in JDK 7 (ETA 2010) or more specifically the new Java module system codenamed Jigsaw.

Module Systems and Jigsaw

Jigsaw is a low level implementation of a module system, which also includes some language and VM changes that are specified in JSR 294 (note that Jigsaw is being done outside of any JSR and is not a reference implementation of 294). Another implementation of a module system most Java developers are likely more familiar with is OSGi. But what is a module system and why do we need one?

Depencies on multiple versions (of module B in this example)

A module system enables modular programming, it allows developers to separate code into clearly defined modules that can specify what other modules they depend on and their versions, can be internally modified without breaking other modules that depend on it and can hide its own internals from external modules.

A module system can solve the classpath/jar hell problem by leveraging the previously mentioned features in order to allow an application to use the right versions of the set of libraries it requires. In the diagram shown here, we have an APP module that depends on the A, B and C modules. But module C also depends on B, however this dependency is to a different version of B than the one APP needs. A useful module system would then allow us to have 2 versions of the B module, with the compatible version and implementation visible to the appropriate modules (in this case APP and C).

Also, by clearly expressing module dependencies, we no longer have to look at random lib folders or hidden documentation when using a 3rd party library, just so we can guess what the corresponding jar files are needed to run it. With the system implemented by Jigsaw, we can simply introspect the module and let it tell us what those dependencies are. It takes the guesswork and the dark magic completely out of the equation.

But back to Mark’s presentation at the general session. The main reasons to introduce Jigsaw into JDK 7 are the following:

• Eliminate classpath complexity (classpath/jar hell problem already discussed).
• Increase performance. The VM download size can be made smaller, and startup time should improve because for small programs (say HelloWorld) unnecessary classes don’t have to be loaded at all. Mark showed how he could run HelloWorld by only using 2 modules listed by the new jmod command; jdk.base@7-ea and jdk.boot@7-ea.
• Enable native integration for installing modules.

Mark demonstrated that last point by showing a demo of him installing various JDK packages via the Synaptic Package Manager.

Installing Java modules via Synaptic Package Manager

Alex Buckley’s presentation

I attended Alex Buckley‘s (Computational Theologist @ Sun) session on “Modularity in the Java Programming Language: JSR 294 and beyond”, which had a lot more details on the specific language changes to be implemented in order to support this new feature.

The most noticeable aspect of this is the introduction of module-info.java. This file goes at the top of your module filesystem, and is the class that specifies at compile and runtime the definition of the module. Here is an example, coming from Alex’s slides;

module org.planetjdk.aggregator {
          system jigsaw;
          requires module jdom;
          requires module tagsoup;
          requires module rome;
          requires module rome-fetcher;
          requires module joda-time;
          requires module java-xml;
          requires module java-base;
          class org.planetjdk.aggregator.Main;
 }

Our module is “org.planetjdk.aggregator” and uses the jigsaw module system. Depenencies are denoted by using requires and providing the module name, Alex calls this part of the module metadata the “logical classpath” of the module. You can also define the main class for the module which in this case is “org.planetjdk.aggregator.Main“.

You’ll also notice that the module name is quite long “org.planetjdk.aggregator”, while the list of required modules uses shorter names. This can be done by supplying a module alias. In the previous example, we could have added the line;

provides module aggregator;

This would then allow other modules to say “requires module aggregator” and successfully link to this module by this shorter form of the name.

Also, you can specify your module version and version dependencies in module-info.java. This updated example illustrates this mechanism;

module org.planetjdk.aggregator @ 1.0 {
          system jigsaw;
          requires module jdom @ 1.*;
          requires module tagsoup @ 1.2.*;
          requires module rome @ =1.0;
          requires module rome-fetcher @ =1.0;
          requires module joda-time @ [1.6,2.0);
          requires module java-xml @ 7.*;
          requires module java-base @ 7.*;
          class org.planetjdk.aggregator.Main;
}

Note also that you can only have one module-info.java per module, in only one location, so if you have a big source tree and you want to create multiple modules from it you will have to either separate your source into different trees or use some creative scripting to accomplish this at build time. I believe Mark mentioned they had to use some scripted solution for the jdk base as I believe it's one tree.

The rest of Alex's presentation focused on how to locate modules at compile and runtime by using the "modulepath", the use of the new module keyword and how it affects accessibility, and he gives a glimpse as to how they plan to support other module systems (for example, the version notation can be different when using other module systems).

This is all better explained in Alex's slides, so I encourage everyone to take a look at his presentation (link provided above).

The Modular Java Platform: Q&A

There were rumors in the meeting that the clown is a secret member of the Java Posse

Wednesday night, I attended a BOF like meeting hosted by Mark and Alex setup in order for the community to openly ask and voice any concerns over the work presented by them on modular Java. The setup was sort of a round table configuration (without the round table) in a very informal setting (btw it was hard for participants in the back to listen well, hopefully microphones are used next time). The first question was kind of funny, somebody asked Alex what a "Computational Theologist" does (the title makes it sound like the equivalent of a Thomas Aquinas for the nerd world).

After that, it seemed some people were very concerned about how to deploy modules, patch jars and other deployment issues. My impression was that a lot of people had a problem with the native installation part of the proposal. Mark answered that Java developers have gotten used to being in our own little jar world, separate from the OS integration issues of module and library management and that it was time for Java to integrate more with these systems. He has a point, do we really have to deploy log4j jars with all our products over and over instead of simply having a log4j installed in the system that all modules can refer to?

However, installation with native package systems is a big change. And it is also unclear what that is going to look like in Windows. It seemed like the Windows part of the equation has not been finalized, would Java 7 include some type of Java specific module registry or would it leverage something like .NET's Global Assembly Cache?

Somebody bought up the point that this new system was imposing more work on open source projects. That is, today you want to release your library as a jar, you know it's going to work everywhere. With Jigsaw, projects may have to deliver a large set of native module packages depending on all the platforms they want to deploy to. Many suggested to Mark and Alex that a cross platform package format was needed, but Mark acknowledged that Sun is not really working on that and they're just worrying mainly about specifying the module file structure and leaving the rest to the native package systems.

I noticed a few members from the OSGi community in attendance, I recognized Peter Kriens (member of the OSGi Alliance), Richard S. Hall (From Apache Felix, works for Sun in the Glassfish team) and BJ Hargrave (CTO of the OSGi Alliance, committer on Eclipse Equinox and IBM employee). Peter and Richard are both members of the expert group for JSR 294, so I was a bit surprised they weren't at all in "harmony" with Mark and Alex and the work they've done with Jigsaw. See, last time I saw discussions on this topic, JSR 277 was still active (it is on hold for now) and I was under the impression that Sun and OSGi had reached some type of "gentleman's agreement". That doesn't seem to be the case at all.

OSGi is a very mature technology and has more features than Jigsaw. However OSGi doesn't address the issue of native package installation, and you could argue that it would not be suitable to solve the issue of modularizing the JDK itself. I think on that last point, many people don't mind Jigsaw even on the OSGi side, the arguments come when you say Jigsaw could be used as an application level module system. Additionally OSGi still has some key features that are missing in Jigsaw; it allows more dynamic loading of modules (useful for plugins) and is backwards compatible (Jigsaw will only be supported from Java 7 and up).

Having said that, one thing I like more about Jigsaw is how it defines dependencies is the module-info.java file. It is a much better syntax than the error prone use of manifest files used in OSGi, where an extra space can break the whole thing for you. Adding keywords for module accessibility is also a very nice thing, and it seems the goal is to also let a modular system like OSGi take advantage of these features. Now how can these both systems inter-operate between each other in a single VM? I have no idea how that works ... yet.

In the end, the Q&A showed that there is a lot of controversy and confusion over this new feature. There was also a noticeable lack of questions during the meeting, with a few of the same people asking all the questions. I got the impression that the need and functionality of a module system in Java is not generally fully understood, so to me that means a lot more work needs to be done to explain just what is going on and why there is so much effort going into this area.

Some key questions I'd like to see clarified:

• A more technical and detailed explanation of why Jigsaw was chosen over OSGi.
• Will the JDK provide tools for wrapping modules in native packages?
• Is a cross platform package system completely out of the question?
• How would multiple modules systems work together in the same VM/application instance?
• What happens when an applet or javafx application requires core JDK modules that are not present in the current installation?
• Native library module integration issues (I sort of asked this in the Q&A). Where are native packages placed, and what happens when multiple modules include the same native libraries (say 2 modules have the same DLL embedded in them)?

This doesn't affect me, why should I care?

These changes will affect everybody, at the very least under the hood your core Java packages will be loaded in a more modularized fashion. For people who would like to run Java in other devices, you will notice that you have better ways to split up your Java distribution to only the parts that you need.

However, if you are interested in scaling your code the right way and modularizing it, you should start becoming familiar with what is going on in this space. For your applications, you'll still have the choice of using existing modular systems like OSGi or using the new facilities provided by Java 7. In the future, we should expect more details to come out as to how you can combine both (Jigsaw and OSGi). Others might prefer not to depend on an external Java project like OSGi and leverage the core support that will be provided for modules.

On the other hand, some people criticize that his is a repeat of the java.util.logging fiasco and say they can mostly ignore these changes. The jury is still out, but this is a very fundamental change in the language and platform and a very different scenario than choosing what logging package to include in the core JDK.

Oh and you might soon see new annoying interview or exam code questions trying to trip you up with gems like this one (from Alex's slides and this blog entry):

package module;
// BTW you should NEVER write code like this!!!
module class module {
        module module module = new
            module();
        module module() {}
}

Anyways, sorry for the longish blog post but hopefully this sheds some light into some of the discussions about this topic that took place at JavaOne. If you are interested in getting more in depth details about this topic, please take a look at some of the following links;

Java SE: Project Jigsaw: Modularizing JDK 7
Project Jigsaw (Mark's blog)
The Modular Java Platform (Mark's blog)
The massive, monolithic JDK (Mark's blog)
Packaging Java code (Mark's blog)
Project Jigsaw: Language changes for Modules
Project Jigsaw (Peter Kriens, his version of the "saga of Java modularity)
Project Jigsaw #2 (Peter Kriens, some criticisms of the proposed system)
Project Jigsaw #3 (Peter Kriens, Jigsaw != JSR 294)
Jigsaw - the death knell of JSR277?
Jigsaw vs OSGi?
A wrinkle with 'module' (Alex's blog)
Modularity in Java (Alex's presentation at DEVOXX 2008; covers module friendship, "virtual modules", multi-module packages, type observability and other topics not covered in the JavaOne slides I linked to in this article)

Update. Some additional links that have come to my attention after publishing this blog post;

Jigsaw Feedback Roundup (Dalibor Topic)
Java Posse #259 - Jigsaw and JSR 294 Interview (Java Posse podcast interview with Mark Reinhold and Alex Buckley)

JavaOne officially starts tomorrow but today Sun has kicked off CommunityOne. Which is a more open source focused and free conference that precedes the bigger event.

The main theme this year is cloud computing. The presentation today has been about showing several vendor solutions in the areas of virtualization and large scale application deployment that is very easy to use (and graphical). To be completely honest, I think “cloud computing” is a big buzzword approaching marketroid levels, but there is some interesting technology here. I’ll be attending a few cloud computing sessions to see if I become one of the converted.

Currently, we’re listening to some of the folks from OpenSolaris and JavaFX in a setup that seems like a nerd version of David Letterman from an alternate reality.

BTW we got a small announcement that JavaFX is now officially released for OpenSolaris. Although I’m not sure there’s a large community of OpenSolaris users looking forward to that

I have to say, the most difficult part of preparing this presentation was trying to figure out the Spanish version of common programming words and concepts. Part of the problem is that when I was learning how to program in Panama (when I was around 10-12 years old) all of my resources; magazines, books, etc where all in English. So I never knew that array is “arreglo”, that a developer is called a “desarrollador”, or what the corresponding word for loop is. It would be really nice if there was some type of resource out there with a table with all these terms, and maybe other languages. One challenge is that it seems not all of these words are “settled”. I noticed some people were still pretty comfortable with the English versions, while others used the Spanish ones exclusively. Also, there are a lot of emerging technologies and concepts in Computer Science which I think still don’t have Spanish translations. Pretty much a more difficult challenge than I expected.

One more thing, JavaFX has changed a lot in the last year. When I did this presentation, I didn’t cover how much effort has gone into optimizing this technology or the new changes to the animation API (like the deprecated dur keyword). There is a preview JFX SDK coming out next month, and you can sign up for it at javafx.com. I didn’t attend JavaOne this year, so I don’t know all the details, but I’m hoping the SDK comes with some of the tooling that Sun has promised. Designer level tools are key to this technology’s success. I hope to make a blog post with a quick review of the SDK once it comes out.