Thoughts on the Jigsaw debacle

July 20, 2012 § 8 Comments

Disclaimer: this is a personal piece of opinion and in absolutely no way does it necessarily reflect the views of my current employer. I have spent 13 years at Sun/Oracle (5 of which in the GlassFish team which had a modularity experience of its own) and I still care very much about the future of Java. I now work at Google.

Runtime modularity in Java has been promised since JSR 277 was filed in 2005 and I wrote how excited I was about its potential back then. Seven (7!) years, a fair amount of OSGi lobbying and politics, Sun’s acquisition, and a plan B promise later, we’ve come to this day to learn that it’ll be pushed further out to 2015 which really means 2016 for a stable release and probably 2020 for a wide adoption. After being promised Java 8 with Jigsaw in late 2012 by Oracle, we’re now taking another 3-year hit because the project missed “the train”.

About resources and goals
Jigsaw has been Mark Reinhold’s baby project for all this time (Mark is the Chief Architect of Java) and I’m now hearing excuses about staffing issues. “Oracle failed to staff Java modularity effort for years”. Hey, now that’s a much better headline! The reality I believe is that Oracle still doesn’t know why it’s doing Jigsaw and thus giving it the proper priority is hard. Modularize the JRE itself to help with JavaME and JavaFX adoption? Offer a modules system for Java’s longer-term viability? A business case can certainly be put together to shrink down the JRE to get Oracle upper management on board. On the other hand, bringing the JVM, the compiler, and the language together around a modules system seems, sadly, to be falling off of Oracle’s radar.

About that train
The common wisdom is that the Eclipse way of shipping software is the best way to get a community of developers building on a platform. You’ve probably also heard of “release early release often”. Eclipse is a very special project which is really about providing a baseline for the Foundation members to build upon and I’d argue that Eclipse IDE users on the other side are not benefiting much from this release model. When it comes to Java, we’re talking about something that also has a diverse audience and I think developers remain far more important than vendors and that a cadenced release model is actually harmful. It’s easy to agree on shipping software when it’s fully baked but the two-year cycle is really the key issue here. Oracle should be able to declare Jigsaw a strategic goal and deliver it with an extra 6 to 12 months (which, by the way, would still mean 2+ years from now!).

About the community
Jigsaw has been presented for many many years by Sun and later Oracle as a key feature in numerous keynotes and conferences and promised in Java 7, Java 8 (in fact I’ve done my share of such promotion while at Oracle) and now Java 9. That has created a lot of expectations in the community. In fact, it’s not only about Java SE as a large portion of the Java ecosystem is also waiting for a standard modularity solution: JavaME, Java EE (see this sample IBM reaction when modularity had to be removed from EE 7), Groovy and other JVM languages and probably by many developers building non-trivial applications with Java. Surely there’s got to be a better way to convey bad news to the community than “sorry, we’ve missed the train!”. In retrospect, the plan A/plan B approach was a brilliant communication plan with Plan A really not being an option and the community rallying behind Plan B. It’s often about how things are conveyed, not only about what they convey.

About open source
I hear some say that this would not have happened if Java was truly open source with a community, not a company, overlooking its destiny. First, my definition of Open Source remains. IP and governance are (ideally) orthogonal to the license and no simple solution exists for all software projects. But more importantly, this is a sad case of a project’s failed risk mitigation (sadly a very common failure in our industry). To consider that a different governance model would have changed anything is wishful thinking. Innovative carefully crafted designs always come from a very small number of talented engineers and in fact, this may even be a case where going open source and transparent was not a good idea but rather a fatal distraction.

About what’s next
As I wrote above, Oracle has the resources to declare Jigsaw a strategic goal. I can agree that it may be hard to deliver by late 2013 but waiting for 2016 is effectively killing Jigsaw and encouraging everyone to look at alternatives which will jeopardize yet even more Jigsaw’s chances of ever seeing the light of day. In fact, even Oracle is considering profiles in Java 8, an ugly band-aid if you ask me. One you’ll need to painfully tear off to get proper modularity in the platform. Jigsaw really shouldn’t be seen as “a new feature”, to me it’s really the Java reboot some people have been calling for a long time. Only a compatible one.

Now of course this is all my personal take and I don’t pretend to know what’s good for Java nor represent the community at large. So getting some hard data about what the community expects from Jigsaw would be a good start before making any decision. I believe this has not been done so far. The closest I’ve seen is the recent JAXenter poll which isn’t very scientific (self-selected, somewhat biased questions).

So in the end, if the community wants Java 8 with its updated and stripped-down content (Lambda, maybe JSR 310, what else?) in 2013, Oracle and the JCP should deliver just that. Again, it’s about meeting expectations. But shipping a Java 8.5 with Jigsaw sooner than later should also be considered. And if there really needs to be a train release model, it has to be a yearly one and not every release needs to be a major one.

In a world where standing still is perceived as fossilization, bringing proper modularity to Java is what moving Java forward ™ is really about.

Google Developer Expert (GDE) en France

July 17, 2012 Comments Off

Parmi les annonces que vous n’avez peut-être pas vu passer lors de Google I/O 2012, il y a le programme Google Developer Experts.

Avec ce nouveau programme, Google propose à des individus d’obtenir un titre d’expert à l’année pour l’un des domaines de prédilection de Google (Android, Cloud, HTML5, Chrome, Social, Geo, etc…).

Il ne s’agit bien entendu pas d’un rôle de porte-parole mais plus d’une reconnaissance apportée à une personne à la fois technique, experte et visible (présentations publiques, blog, commits, etc…). Ce titre lui permettra d’entretenir une relation avec Google (contact avec les developer advocates, access aux previews et plus encore) et de présenter lors de conférences développeurs.

Initiallement piloté en Israel et au Japon, le programme est désormais publique et actif en France comme l’indique la page des Experts actifs. Sa gestion est effectuée localement par Google France.

Maj: voici un billet sur GDE rédigé par le responsable du program au niveau mondial.

CloudSQL for the busy Java Developer

July 12, 2012 § 1 Comment

CloudSQL, Google’s fully-managed and highly-available MySQL-based relational database service, can be accessed directly by Java IDE’s or used as a target for on-premise running Java application servers, and of course it can be seamlessly used from AppEngine Java applications. Here’s how.

Pre-requisites

This paper assumes you have a CloudSQL database instance configured and (ideally) populated. You should have authorized your local machine using OAuth and the command-line tool and have the CloudSQL JDBC driver handy (it’s in the AppEngine SDK in lib/impl). If you need help on any of this, consider reading this Getting Started paper.

Here are the values used here :

  1. Cloud SQL instance name : scott-tiger:scott
  2. Database Name : jpetstore
  3. JDBC Driver Class Name : com.google.cloud.sql.Driver
  4. JDBC URL : jdbc:google:rdbms://scott-tiger:scott/jpetstore

By default the CloudSQL instance can be accessed with user root and an empty password.

This paper uses NetBeans (7.x) as the IDE and GlassFish (ships with NetBeans) as the local Java Application Server but everything should be easily adaptable for other tools such as Eclipse and other runtimes (tomcat, JBoss, etc).

NetBeans & CloudSQL

The NetBeans IDE offers a JDBC database explorer feature which you can use to access your CloudSQL database instance. In the NetBeans Services tab, chose Databases > Drivers and create a new driver configuration by pointing to the google_sql.jar archive and using com.google.cloud.sql.Driver as the JDBC driver name (should be auto-detected). Right-click this newly created JDBC driver and select “Connect With…” to create a new connection. Provide the username, the password and the full JDBC URL (jdbc:google:rdbms://scott-tiger:scott/jpetstore in my case) and test the connection.

You should now be able to navigate the database schema, view table content, manipulate data, and execute any SQL statement.

WebApp Project

We’ll now create a web application using JPA entities manipulating data from the Cloud SQL instance discussed above. We’ll deploy this application first to GlassFish, then to App Engine.

Within NetBeans, create a (Maven) Web Application project with GlassFish as the default target. Right-click on the project to select the “New Entity Classes from Database” wizard. Create a new data source using the JDBC connection defined in the previous step. Select the tables you want to create JPA entities for and do not check the “Create Persistence Unit” option (we’ll get back to this later). This generates standard JPA 2.0 @Entity-annotated classes for every table selected from CloudSQL.

Here’s a proper persistence.xml that will work with CloudSQL. Notice how this JPA persistence unit uses RESOURCE_LOCAL and not a JTA data source :

<persistence version="2.0">
  <persistence-unit name="CloudSQLPU" transaction-type="RESOURCE_LOCAL">
    <properties>
      <property name="javax.persistence.jdbc.url" value="jdbc:google:rdbms://scott-tiger:scott/jpetstore"/>
      <property name="javax.persistence.jdbc.user" value="user"/>
      <property name="javax.persistence.jdbc.password" value="pw"/>
      <property name="javax.persistence.jdbc.driver" value="com.google.cloud.sql.Driver"/>
    </properties>
  </persistence-unit>
</persistence>

Once this is setup, you can get a hold of this persistence unit in the servlet created by default the typical way you would in an servlet :

EntityManagerFactory emf = 
        Persistence.createEntityManagerFactory("CloudSQLPU");
EntityManager em = emf.createEntityManager();

A simple use to exercise the data could be to list all the names stored in the Category table (using its JPA entity representation) :

CriteriaQuery cq = em.getCriteriaBuilder().createQuery();
cq.select(cq.from(Category.class));
List<Category> categories = em.createQuery(cq).getResultList();

for (Category category : categories) {
    out.println(category.getName() + "<br/>");
}

Deploying this simple application to the GlassFish application server shouldn’t require any other changes. Obviously with this architecture, the performance is not ideal given the server is not exactly close to the data. Nevertheless, this demonstrates the standalone capabilities of CloudSQL

Ship it all to the cloud!

A better approach is to probably to use CloudSQL from a Google AppEngine-hosted application where all sorts of optimisations will quick in. To do so, only limited changes to the standard application described above are required.

The first simple change is to add the AppEngine-specific deployment descriptor appengine-web.xml :

<?xml version="1.0" encoding="UTF-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <application>MyCloudSQLApp</application>
    <version>1</version>
    <threadsafe>true</threadsafe>
</appengine-web-app>

You’ll also need to change the name of the JDBC driver in persistence.xml (a more elegant solution could be to use Maven profiles to keep the project fully portable) :

- <property name="javax.persistence.jdbc.driver"
-          value="com.google.cloud.sql.Driver"/>
+ <property name="javax.persistence.jdbc.driver"
+         value="com.google.appengine.api.rdbms.AppEngineDriver"/>;

The JDBC URL remains the same.

Finally, you’ll need to bundle JPA / EclipseLink and BeanValidation / Hibernate Validator by making them runtime-scope dependencies. The Servlet and AppEngine SDK API artifacts should use the default scoping. Your mileage may vary when it comes to the implementation versions. Here is my complete set of Maven dependencies :

<dependencies>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>eclipselink</artifactId>
            <version>2.3.2</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>javax.persistence</artifactId>
            <version>2.0.3</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>javax.validation</groupId>
            <artifactId>validation-api</artifactId>
            <version>1.0.0.GA</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-validator</artifactId>
            <version>4.2.0.Final</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
        </dependency>
        <dependency>
            <groupId>com.google.appengine</groupId>
            <artifactId>appengine-api-1.0-sdk</artifactId>
            <version>1.7.0</version>
        </dependency>        
    </dependencies>

Make sure the AppEngine application is authorized to access the CloudSQL instance (use the API Console for that). Once this is all done, simply deploy the application to AppEngine :

$ appcfg.sh update target/MyCloudSQLApp-1.0.0-SNAPSHOT

You’ll find the CloudSQL developer documentation here.

Nouveautés Google AppEngine 1.7.0

July 2, 2012 § 1 Comment

Google App Engine version 1.7.0 est disponible depuis son annonce à la conférence I/O fin juin 2012 à San Francisco. Cela fait maintenant quelques temps que l’équipe a pris l’habitude de sortir des versions environ tous les mois (un rythme rendu possible par la délivrance d’un service et non d’un logiciel) et cette version contient son pesant de nouveautés.


Il y a tout d’abord l’arrivée d’AppEngine dans les data centers européens pour améliorer encore la latence des applications web mais aussi pour offrir une conformité en matière de localité des données aux entreprises qui le nécessitent. Cette fonctionnalité sera initialement offerte aux clients “Premier” et sera associée à une facturation en euros.


Le support de SSL sur des noms de domaine personnalisés est proposé avec deux variantes:
- SNI, partageant une même adresse IP pour plusieurs domaines, supporté par la plupart des navigateurs et disponible pour $9 par mois avec 5 certificats.
- VIP, une adresse IP dédiée à l’application permettant de servir un nom de serveur, un nom de domaine complet ou bien de multiples domaines pour $99 par mois.

D’autres nouveautés concernent :
- l’intégration du service PageSpeed pour les applications HRD pour un supplément de $0.39 le Go sortant
- un service intitulé “Cloud Enpoints” offrant une interface simple et authentifiée (Oauth2) en Rest pour des applications web et mobiles
- une limite de taille d’application désormais fixée à 1Go (contre 15Mo précédement)
- la possibilité de stocker et de chercher (rajout à la récente API de Search) selon des points géographiques

L’ensemble des nouveautés sont documentées dans les Release Notes et présentées en qq minutes dans cette vidéo de la conférence.

eXo Cloud IDE support for AppEngine

June 28, 2012 Comments Off

eXo announced today during Google I/O that their Cloud IDE now supports Google AppEngine (which itself had its share of new features with 1.7.0 but more on that in a later post).

If you haven’t heard of or tried Cloud IDE yet, it’s a very fine IDE in a browser developed by eXo. While not on-par with your typical Eclipse/NetBeans/IntelliJ desktop solution it goes a long way offering multiple language support, code completion, syntax highlighting and integrated javadocs.

All of this goodness now integrates with AppEngine, both Java and Python. This means that you can start from Cloud IDE, seamlessly integrate with the AppEngine management tools to create the application, debug “locally” using the eXo infrastructure, and ship it to AppEngine. Here’s a short and sweet demo of this at work, all without ever leaving the browser:

Documentation for all of this is here.

Try it out for yourself!

Did you say Google Cloud?

June 15, 2012 Comments Off

Some people think Google is all about Cloud and that is mostly true.
When asked to be more specific developers usually equate Google Cloud to Google App Engine.

With the new cloud.google.com website it should become clear that it’s much more than that with Google Cloud Storage, Google BigQuery, and more to come. Orthogonal, fully-managed services to built the best cloud apps.

The developer resources remain on : developers.google.com/appengine, developers.google.com/storage and developers.google.com/bigquery/.

Google I/O Extended 2012

June 11, 2012 § 2 Comments

Paris, Nantes, Bordeaux, Lille, Lyon, Marseille, Nancy, Rennes, Strasbourg, …

Google I/O c’est la conférence Google pour les développeurs qui se tient à la fin du mois (du 27 au 29 juin 2012) à San Francisco.

Une seule keynote
Cette année la conférence dure 3 jours avec une keynote unique le mercredi 27 à 9h00 heure locale (18h en France). Celle-ci devrait durer 2h30 et comme chaque année de nombreuses annonces devraient y être faites.

Les Google Developer Groups de Paris et de Nantes et probablement d’autres encore seront partie prenante avec des événements locaux (connus sous le nom de I/O Extended) pour assister à la retransmission, pour échanger sur les annonces, regarder des sessions techniques, rencontrer des ingénieurs Google de Paris et participer à une session avec des ingénieurs Google en direct de San Francisco.

Inscriptions

* Inscriptions Paris, détails GDG Paris et PAUG.
* Détails et Inscriptions Nantes

En france, les “io-extended” sont organisés en partenariat avec les écoles du réseau Epitech. Toutes ces écoles devraient donc être connectées afin de retransmettre la keynote et les sessions qui suivent.

Posez vos questions!
Utilisez ce Google Moderator pour poser vos questions dès maintenant. La session avec des ingénieurs francophones en direct de I/O sera l’occasion de les passer en revue!

Tenez-vous au courant sur les événements I/O Extended en suivant la page Google+ de I/O Extended France.

Follow

Get every new post delivered to your Inbox.