What's interesting is this really starts the beginning of the end. It really doesn't matter if Java 7, or for that matter, Java 8 comes out. Java has always succeeded because of the community and the wide quality of open-source Java projects that have driven the infrastructure forwards. However, Oracle has completely destroyed the Java community with its sheer incompetence in handling this dispute. Further, it has stirred up more anti-Oracle emotion than even Microsoft has these days; from OpenOffice (now LibreOffice), Hudson on the move, and now the farce that is the Just Customers Please, Oracle have gone from saviour to villain in a matter of months.

Oracle needs to remember that developers choose the technologies that are used in projects. Given an equivalent offering from Oracle or Sybase, or Oracle and DB2, who do you think developers are going to lean towards in their analysis and recommendations?

This has lit the fuse on the Next Big Language, because this is the final indication that Java is on the way out, regardless of what progress is made on the delivery of Java SE 7 or even the fictitious Java SE 8. What's needed is a new language, and a new runtime. Something like Google Go, but with decent modularity and exceptions.

One of the things that also encouraged me was the generated application was also a valid OSGi bundle; great. So when Roo 1.1 was released recently, I gave it a spin. (Sadly, and somewhat ironically, whilst Roo 1.1 is now running in an OSGi container, the generated products are no longer OSGi bundles. Roo-1052 has more information about this slide backwards.)

Before going into how to use Spring Roo, it's worth mentioning what it does and why. The goal of Roo is to make it easy to put together web-based applications that have persistent entities; in other words, your fairly typical web/servlet/jsp/hibernate kind of setup. However, the way it achieves this is somewhat different to other tools. Instead of modifying source code that you write, it creates additional files which it generates. It then uses – effectively – a #include at compile time to bring those fragments into your class. This is achieved with the AspectJ compiler, and in a unique and fairly useful way, using AspectJ as more than just wrapping-a-method-with-log-statements.

The net result is you write a minimal set of code in your class, and Roo automatically generates the necessary AspectJ fragments to support what you've written. (Those who have seen Project Lombok may already have seen this kind of approach in an IDE.)

Using Spring Roo is fairly easy. There's a roo.sh executable (roo.exe on Windows) which brings up a roo> prompt, from which you can hit a number of commands. Unlike a standard OSGi shell, there's TAB completion; also a bonus is the fact that commands which aren't enabled are hidden from the list. Finally, there's a hint system that you can call (with hint) to bring up a list of what-you-can-do.

The steps are as follows:

• Create a project
• Setup the persistence mechanism (database, mapping provider)
• Create one (or more) entities
• (Optionally) Create a web container

Project

Creating a project is easy enough – you need to run project --topLevelPackage com.example. It generates a number of source directories, a spring folder and a log4j properties file, along with a Maven project to build them all. Think of it as a one-liner for Maven archetypes and you'll be close to what's required.

roo> project --topLevelPackage com.example
Created /tmp/example/pom.xml
Created SRC_MAIN_JAVA
Created SRC_MAIN_RESOURCES
Created SRC_TEST_JAVA
Created SRC_TEST_RESOURCES
Created SRC_MAIN_WEBAPP
Created SRC_MAIN_RESOURCES/META-INF/spring
Created SRC_MAIN_RESOURCES/META-INF/spring/applicationContext.xml
Created SRC_MAIN_RESOURCES/log4j.properties

Persistence

Setting up persistence is also as easy. persistence setup --provider p --database db will do all the legwork for you in terms of setting up a persistence.xml file, the driver classes to use and the per-provider magic settings that you need to know. Providers such as EclipseLink, OpenJPA and Hibernate are available, as are database drivers like DB2, Derby, Oracle and so on. (The setup notes that if you use a commercial driver you have to install it manually into your Maven repository in order for it to be found.) Use the TAB key to get a list, or complete what you're typing, in doing this.

com.example roo> persistence setup --provider ECLIPSELINK  --database DERBY 
Managed SRC_MAIN_RESOURCES/META-INF/spring/applicationContext.xml
Created SRC_MAIN_RESOURCES/META-INF/persistence.xml
Created SRC_MAIN_RESOURCES/META-INF/spring/database.properties
Managed ROOT/pom.xml [Added dependency org.apache.derby:derby:10.6.1.0]
Managed ROOT/pom.xml [Added dependency org.eclipse.persistence:eclipselink:2.1.0]
Managed ROOT/pom.xml [Added dependency org.eclipse.persistence:javax.persistence:2.0.1]
Managed ROOT/pom.xml [Added dependency org.hibernate:hibernate-validator:4.1.0.Final]
Managed ROOT/pom.xml [Added dependency javax.validation:validation-api:1.0.0.GA]
Managed ROOT/pom.xml [Added dependency cglib:cglib-nodep:2.2]
Managed ROOT/pom.xml [Added dependency javax.transaction:jta:1.1]
Managed ROOT/pom.xml [Added dependency org.springframework:spring-jdbc:${spring.version}]
Managed ROOT/pom.xml [Added dependency org.springframework:spring-orm:${spring.version}]
Managed ROOT/pom.xml [Added dependency commons-pool:commons-pool:1.5.4]
Managed ROOT/pom.xml [Added dependency commons-dbcp:commons-dbcp:1.3]
Managed ROOT/pom.xml

Entities

Now we're able to create entities. The entity --class c kicks off the entity generation process; you can type in a fully qualified name or use ~ to represent the project package.

com.example roo> entity --class ~.Employee 
Created SRC_MAIN_JAVA/com/example
Created SRC_MAIN_JAVA/com/example/Employee.java
Created SRC_MAIN_JAVA/com/example/Employee_Roo_Configurable.aj
Created SRC_MAIN_JAVA/com/example/Employee_Roo_Entity.aj
Created SRC_MAIN_JAVA/com/example/Employee_Roo_ToString.aj

At this point, we have a project that's capable of being used as a pure JPA provider. Before going further, it's worth looking at what's been generated:

• pom.xml - the project details, source directories and so on
• persistence.xml - which defines the database, configuration mappings and so on
• *.properties - for supplying mutable data, like userid, password and logging levels
• *.aj - the aspect fragments
• Employee.java - a single Java file

The Employee is fairly simple; at the moment, we've not added anything to it. In fact, other than a few annotations (@RooJavaBean, @RooToString, @RooEntity) it has no contents. We can add a field using the console to give an employee a name and a manager.

~.Employee roo> field string --fieldName name 
Managed SRC_MAIN_JAVA/com/example/Employee.java
Created SRC_MAIN_JAVA/com/example/Employee_Roo_JavaBean.aj
Managed SRC_MAIN_JAVA/com/example/Employee_Roo_ToString.aj
~.Employee roo> field reference --fieldName manager --type ~.Employee
Managed SRC_MAIN_JAVA/com/example/Employee.java
Managed SRC_MAIN_JAVA/com/example/Employee_Roo_JavaBean.aj
Managed SRC_MAIN_JAVA/com/example/Employee_Roo_ToString.aj

All this has done is added a couple of fields to the class, one with a single JPA annotation:

@RooJavaBean
@RooToString
@RooEntity
public class Employee {
    private String name;
    @ManyToOne
    private Employee manager;
}

The interesting thing is what you don't see, which are being generated in the *.aj files. For example, take a look at the Employee_Roo_ToString.aj file:

privileged aspect Employee_Roo_ToString {
    public String Employee.toString() {
        StringBuilder sb = new StringBuilder();
        sb.append("Id: ").append(getId()).append(", ");
        sb.append("Version: ").append(getVersion()).append(", ");
        sb.append("Name: ").append(getName()).append(", ");
        sb.append("Manager: ").append(getManager());
        return sb.toString();
    }
}

This aspect, when compiled with AspectJ, effectively inserts a toString() into your class automatically. It uses the name and manager that we've just added; and in fact, if you were to go into the Employee.java file and edit it with your favourite text editor, when you save it, Roo will notice and update the toString() automatically.

The id and version are defined in the Employee_Roo_Entity.aj file, so all Roo entities have these. IDs are represented with a Long by default (though you can change that when the entity is created) as well as an Integer version (to support verification of recency when two updates occur on the same row in the database).

Finally, we've also got Employee_Roo_JavaBean.aj which generates the getName() and setName() methods based on the fields you add. Of course, most IDEs can do this for you but Roo takes it out of your IDE and into a standalone monitoring process which can update the aspects automatically.

If you have a need to do a specific implementation – say, to pre-validate a field – then you can simply write the setName() in your Employee.java file. Roo notices that it's already there and doesn't bother regenerating it.

There's a web controller as well, though I'm not going to go into it here; doing controller all will generate a huge amount of code for you, and perform command --mavenCommand jetty:run will bootstrap a Jetty environment to test it.

Since it's scriptable, you can easily replay this by copying and pasting the below into a Roo shell prompt:

project --topLevelPackage com.example
persistence setup --provider ECLIPSELINK --database DERBY
entity --class ~.Employee
field string --fieldName name
field reference --fieldName manager --type Employee
controller all --package ~.web
perform command --mavenCommand jetty:run

Once you've done that, point your web browser at http://localhost:8080/example/ and see the app in action.

What's not to like?

Simple project setup, integration with a variety of different providers and databases, single command entry – what could be better?

Well, although it's an excellent idea in principle, it does have its drawbacks. One is that although using aspects in this way is a great idea, there is still some concern with using aspects which may put some people off. The second is that sometimes it's not clear what is happening behind the covers which takes a bit of getting used to.

It's a real shame that Roo has stopped generating OSGi bundles by default. Partially the enterprise spec runtimes aren't there yet, so generating a Meta-Persistence header may not be immediately usable; but more was the complaints against Roo that it was using the SpringSource EBR instead of Maven central. Although EBR has been great for popularising OSGi, many upstream projects are migrating over to use OSGi metadata so it's not clear immediately that it's as much of an issue as it was when Roo originally came out.

The license is also a potential sticking point as well. Although the Roo annotations are licensed under an Apache License, Roo itself (which reads and generates the *.aj files) are GPL. Some are concerned that this might introduce viral dependencies on the GPL – though whether from some kind of indirect linkage with the annotations or whether it's a bigger concern about the code that is automatically generated by Roo differs depending on who you ask. Either way, it's something to consider when basing an application off Roo.

Conclusion

Spring Roo is a great environment for creating persistent entities and web applications to drive them. Obviously not all applications fit into this shape so it has a limited audience. Being a Spring project, it uses Spring heavily in the generation of the runtime entities; much more so than you need if you're generating an OSGi JPA bundle. It's also a great application of aspect-oriented-programming that is more than the log-it-and-see example that you come across.

However, concerns about the license and the fact that it no longer generates OSGi bundles mean that it's probably better suited to prototyping or learning about how to generate JPA entities. The approach is promising though and with a different license or different style of generation it could be a real winner.

I recently posted a cryptic tweet in response to @Vogella's article on REST with Jersey, since Jersey has repeatedly failed in an OSGi runtime like environment. Using Restlet is a much smarter move if you want to serve REST based requests.

Here's the Hello World of Restlet:

import org.restlet.*;
import org.restlet.data.*;
import org.restlet.resource.*;
public class Test {  
  public static void main(String[] args) throws Exception { 
    int port = 8080; 
    new Server(Protocol.HTTP, port, HelloResource.class).start();  
  }
  public static class HelloResource extends ServerResource {
    @Get 
    public String helloWorld() { 
      return "Hello World";
    }
  }
}

Run that, with restlet-2.0.1.jar on your classpath, and then point your browser to http://localhost:8080.

There's a lot more documentation in the Restlet tutorial if you want to know more.

OK, it looks dated now; but remember this was back in 1992 (check the copyrights at the end of the video if you don't believe it). At the time, Windows 3.1 had just been released and and Linux 1.0 was two years in the making from its initial 1991 release. To say it was ahead for its time seriously undermines its power at the time; the Objective-C language and NSObject hierarchy (which ultimately became Cocoa on OSX) gave it its drag-and-drop behaviour between applications. My first introduction to OO languages was in Objective-C; both Java (and Windows 95) didn't come onto the scene until 1995. And let's not forget that a NeXT box was used to create the world wide web in 1990.

Skip forward through Jobs' return and OSX, and I've been an avid Mac user since. It's not just about the build quality (though arguably the hardware is second to none) but the operating system and foundation is really a key part of the OSX experience. And as a developer platform it is great; it comes bundled with Python, Ruby, AppleScript, and has integration with document parsers, quick indexing and hardware support for a number of USB and other external devices out of the box.

In fact, when Jobs rolled out onto WWDC 2001, he said that he wanted to make OSX the best platform for Java development. And until a few years ago, that was arguably the case. There was concern during the transition of PPC to Intel with Java 6 being only available on 64-bit Intel systems but the feeling was that it was a transitional issue and a way of encouraging developers to move forwards. Unfortunately, it meant that Java developers couldn't develop against Java 6 APIs and then sell them to customers on OSX 10.5 platforms; but in reality, the Java marketplace for end-user applications has always been pretty small.

For developers, though, OSX has historically been far more popular than its market share would suggest. Go to any tech conference and the number of Macs in use are likely to be above average. Whatever language you use, Mac had it all. Many Mac developers use laptops or desktops for doing development work, even if that's on a platform-neutral runtime like Python, Ruby or Java. And although the Java language might be jaded, the JVM is used by many more languages, like Scala, Groovy and JRuby/JPython.

So Apple's departure from providing a Java runtime was a significant concern for me. OSX's server marketshare isn't likely to be significantly affected – Jobs' focus on consumers means that OSX server is never likely to get a foothold – but what it's really going to hit is developer platforms. Whatever your favourite IDE (Eclipse, NetBeans, IntelliJ), they all require a Java runtime to operate. Without an Apple-provided runtime in the future, it means that upgrading to future OSX platforms may not be worth the investment. My aging G5 needs replacement in the near future; I had been eyeing up the new Mac Pro; but the G5 will continue to work as a Java development platform whereas the next version of OSX on a Mac Pro may not.

Apple's push for continued Objective-C on the iPhone makes sense; and OSX-based GUI applications in Objective-C is also total sense as well. There's a lot of strength in the frameworks and the language, which isn't immediately obvious to those who have lived in the Java world for many years.

But the key problem is that many developers on the Mac *don't* use those languages, because their customers have no interest in OSX-only solutions. For better or worse, OSX is the only system that hosts Objective-C applications; and whilst GNUStep and and The Cocotron exist to assist in porting applications to other platforms, ironically it is Apple's own iTunes and QuickTime products that are the widely used Cocoa ported applications.

Apple has always been at the forefront of ditching technology that is past its sell-by date. It ditched floppy discs with the introduction of the iMac range; it ditched the PS/2 (and ADB) connectors for USB before it was widely used; it's started to evict hard drives and optical drives from its lightest laptops. Has Java fallen foul of this as well? Will there never again by a well-ported JVM on OSX?

It's too early to say whether Oracle can save Java; and whilst Jobs wants others to ship JVMs, it's not clear whether anyone else wants to do it, either. Apple has a great track record for integrating technology – for example, DTrace, and before it ditched it, ZFS – but when Apple abandons something, it does it in style. All of the hooks for the OSX specific behaviours (including the recently released support for fast shutdown) were things that Apple made possible. Even Swing didn't look too bad on a Mac thanks to the effort put in by Apple's Java team.

Although SoyLatte has been cited as a possible successor for OSX, the Harmony project shows that few people are interested in maintaining a Java platform. Even if Oracle does take over producing a Java version (and it's not clear why it should; it supports development tools but doesn't run Oracle on any OSX platforms), the integration with the UI is likely to be worse than it currently stands. As Scott Kovatch, former Apple engineer on the JVM platform said, All the talk about how well OpenJDK and X11 work together on the Mac is extremely depressing.

There's a small possibility that Oracle will manage an OSX port going forwards. But even if it does in the short run, I can't see it being supported in the long run. And ultimately that means that Mac OSX is transitioning from a development platform to a user-driven content platform. Perhaps it's time to dust off my Linux skills and see if it has made any significant progress in the UI space in the last couple of decades.

What does this mean for Eclipse and other Java-based IDEs? Well, one of the key problems is that the OSX implementation of Java provides a number of Cocoa-specific bindings and hooks. Whilst Eclipse is based on top of SWT, and SWT uses the native widget set directly (rather than AWT and Swing which render their own), there are a number of hooks into the Cocoa layer to provide application-level services. Some of these have been extended in the redesigned eAWT package to permit Java applications to opt into user events (including the “sudden termination” which enables faster OS shutdown).

NetBeans and IntelliJ, which rely on the AWT and Swing directly, may not be so lucky. Ports of the OpenJDK (such as SoyLatte) may use X11 instead of the native OSX windowing components; it's not clear whether Apple will donate back the OSX-specific UI code. (Earlier, when Sun was in charge, Apple were happy to donate back certain items such as the ability to load the rt.jar into shared memory for multiple JVMs to take advantage of.) Going forward, JVMs will be installed into /Library/Java/JavaVirtualMachines; though hopefully the JVM selector will still map the commands like /usr/bin/java into the selected default platform.

Either way, this is the end of an era; and, if as promised Apple don't ship a JVM with OSX 10.7, may be the beginning of the end of Eclipse on the Mac platform. If so, this would be a tragic end to an excellent journey, which led me to the Eclipse community back when it was being ported to OSX for the first time, through to helping test out the Cocoa port when it was ported again, and to now, where I am finally in an Eclipse paying job.