Archive for category Java

Rant: don’t name interfaces like ISomething

Posted by Olivier Gérardin in Java, OO on 2009-07-24

I see a trend lately in Java libraries and code that I thought was only plaguing Microsoft developers: naming interfaces like ISomething. I find this very disturbing so I thought I had to react.

First thing: an interface is a type just like a class. What a type does is mainly to define the set of operations (methods) that are applicable to an instance of a class that implements this type. When dealing with references, the only thing the Java compiler cares about is the type of the reference, so that is knows if a method call is licit or not. It does not care if the type is a class or an instance. Think about the instanceof operator: despite what the awkward name suggests, it works with interfaces as well as classes, because what it actually tests is whether a given reference is of a particular type.

So, why shouldn’t you name your interfaces beginning with the letter I?

  • it breaks a fundamental OO rule, which is that you should let the users of your code know as little as possible about the implementation. If a method returns a object of type Foo, it doesn’t make any difference to the caller of this method if Foo is actually a class or en interface.
  • it is redundant. If you really need to know, the documentation (written or Javadoc), or your IDE’s lookup mechanism, will tell you if it’s an interface or not
  • it makes code harder to read. Which one do you prefer:


IFoo foo = getFoo();
IBar bar = (IBar) foo.getStuff();

or

Foo foo = getFoo();
Bar bar = (Bar) foo.getStuff();

I understand that developpers are often tempted to name interfaces like that because they know there will likely ever be only one implementation of this interface. So they have a Foo class, and it needs to implement an interface, why not name it IFoo?

Two points here:

  • You don’t always need to define an interface for such a class. If you are configuring Spring beans for example, your bean references don’t need to be an interface type. Even if it is good practice to do so, there are cases (such as the one above) where it’s a perfectly valid case to use the class directly.
  • Why not name your interface Foo, and your implementation something else, like DefaultFoo or SimpleFoo or BaseFoo or whatever. Or maybe just Foo, provided it’s not in the same package! If you are using a factory, no-one will ever know or care how the concrete class is named anyway.

Naming interfaces like ISomething is similar to including type name or scope in your variables names. Yuck… Please don’t bring this to Java.

, ,

2 Comments

WebDriver: automated web UI testing

Posted by Olivier Gérardin in Java on 2009-06-04

Automating UI testing is not a trivial task, yet it is highly desirable as part of a complete non-regression test suite, which is (as everyone knows by now) a must-have for any project claiming to be agile. This is how I came across WebDriver while looking for ways to automate testing a GXT-generated frontend.

While being quite similar in its goals to Selenium, WebDriver takes a different approach: instead of interacting directly with the application’s JavaScript, it runs totally external to the browser and “drives” it, a bit like SeleniumRC.

Yes, it introduces a platform dependency, but this is mitigated by 2 points: the FirefoxDriver is available on all platforms, and you also have a HtmlDriver which is not platform-dependant, but unfortunately cannot work with JavaScript interfaces.

On the other hand, piloting the browser means you test exactly what the user will see. And depending on the browser is also a good thing because the browser is part of what you want to test! if your application has a glitch on IE which does not exist on Firefox (this is just an example of course…), then you want your tests to find out.

Writing a WebDriver test can be done in minutes. It’s simpy an API, so you can integrate it in any kind of Java code, including a JUnit test suite.

For example:

import ...

public class TestWebDriver {
public static void main(String[] args) {
WebDriver driver = new FirefoxDriver();

driver.get("http://localhost:8080/myApp/MyHostPage.html");

WebElement checkbox = driver.findElement(By.xpath("//div[@id='checkbox-id']/input"));
checkbox.setSelected();

WebElement element = driver.findElement(By.id("submit-button-id"));
element.click();

System.out.println("Page title is: " + driver.getTitle());
}
}

Can’t imagine much simpler than that. Want to test with IE ? Use InternetExplorerDriver instead of FirefoxDriver. Checking iPhone compatibility? Try IPhoneDriver.

As I’m working with GXT, there are a few things to be aware of. You will most often look for elements by ID, but of course the ID you set with GXT’s setId() is not always where you expect it to be. For example, if you set it on a Checkbox, it’s actually attached to the DIV that surrounds the INPUT element, not the INPUT element. This is why, in the example above, I used XPath to select the element, rather than direct selection by ID. When you want to access an element, the best is to have a look at the HTML by using an inspection tool such as Firebug or similar; then you can easily write an XPath expression that will select just the element you need.

WebDriver will eventually be integrated into Selenium 2.0.

, , , ,

3 Comments

Java and Primitive Types… latest round

Posted by Olivier Gérardin in Java on 2009-05-27

java_logoThis point surfaces once in a while… I guess it’s time for a new round: Would Java Be Better Off Without Primitives?

I became aware of this issue a long long time ago, by reading this excellent IBM paper: Primitive Types Considered Harmful (download available as PostScript only). It’s quite outdated now because at the time (1998), there were no such things as Collections and auto(un)boxing, but the roots of evil were already there. And it’s still a good read that I recommend to any serious Java programmer.

This paper also included a proposal that could have been almost painlessly integrated into the JVM, and would have allowed immediate types similar to what exists in SmallTalk. Obviously this proposal didn’t make its way into Java.

Now I wonder what good it does to argue about this once again. After reading about this, I have come to the conclusion that:

  • primitive types were originally introduced into the Java language for a wrong reason: performance. We know today that the performance gain was not worth the confusion and lack of consistency that resulted from this choice. The introduction of auto(un)boxing only added to the confusion, just to save a few lines of code.
  • primitive types will not go away. The Java language has reached a point where it has too much inertia to even think of introducing such a radical change. I believe that if closures ever make their way into Java it will be the last significant change.
  • it’s alright this way. Now that everyone has learned to use primitive and wrapper types, now that auto(un)boxing, however awkward, is there, what would be the real benefit, other than to satisfy a few purists? Java is not a pure OO language. So what? If you want to do pure OO, do SmallTalk… The strength of Java is not there, it’s in its ubiquitous presence, its profusion of libraries and tools, its ease to find as a skill, etc.

So we can continue to make mental exercises and debate on how Java could be altered to eliminate the need for primitive types, or we can accept the situation and do with it. I’m not saying the former is not interesting, in the contrary… but I’ve chosen my side.

,

No Comments

Oracle acquires Sun – what’s at stake for Java?

Posted by Olivier Gérardin in Java on 2009-04-21

Logo Sun/OracleThe announced acquisition of Sun by Oracle leaves us Java developpers wondering about the future of this platform.

Indeed, Oracle has always been supportive of Java, and an Oracle backend is definitely a natural piece in a JEE architecture, but there will be consequences for the Java world.

To start with, there are the databases: Oracle of course, MySQL that was acquired not long ago, and now PostgreSQL. MySQL has a strong installed user base with very specific needs, and those will not switch to Oracle, even if a lite express web edition was made for them. So maybe Oracle will drop PostgreSQL along the way? I know PostgreSQL is a steady database and has fervent supporters, but let’s face it, it’s marginal. But being open source, it will survive in some way of course.

Then, Oracle now has no less than three application servers: its own OAS, WebLogic which came with the acquisition of BEA, and now GlassFish. Eventually not all of them will survive, but Glassfish has a good chance of being a survivor, first because it’s open source, second because it’s a reference implementation. Glassfish could be an efficient weapon against JBoss if it continues to evolve at the current rate, and Oracle might want to use it.

Oracle also inherited NetBeans, a very serious competitor for Eclipse; but Oracle is involved in Eclipse as a member of the Eclipse foundation, not to mention that Oracle also has its own Java IDE: JDeveloper, itself a fork of JBuilder… I believe NetBeans has a lot more potential than JDeveloper, so I think it’s not unlikely that JDeveloper will be gradually abandoned for a “custom” version of NetBeans, while the base NetBeans remains open source.

So is this acquisition good for Java? Better than the aborted IBM deal? Hard to say. One thing is that their respective portfolios complement each other better: Oracle doesn’t build hardware, IBM does, Oracle doesn’t make OSes, IBM does. By obtaining those two components from Sun, Oracle now has a pretty nice stack: Sun server, Solaris OS, Oracle DB, JEE application server. On the other hand, IBM did a lot more for the Java ecosystem than Oracle, being a huge contributor to Eclipse and Java libraries through its AlphaWorks division.

It seems that the Java part of Sun interested Oracle mostly because it powers its Fusion middleware offering, which makes it quite essential to the eyes of Larry Ellison, who called it “the single most important software asset we have ever acquired”. How true is this? Will Oracle really increase the investment in Java? I might be wrong, but I’ve always seen Oracle as a data-oriented company, and I’m afraid there is a so-called impedence mismatch between Sun and Oracle, just like there is between RDBMS and OO programming. But I hope it’s just me.

, , , , , ,

2 Comments

Google App Engine – Where Does It Fit?

Posted by Olivier Gérardin in Java on 2009-04-17

In an interesting article about GAE, Dmitriy Setrakyan points out several limitations of the new Java support in the Google App Engine. Most importantly:

1. You have no control over number of deployment instances.
2. You have no control over load balancing
3. You cannot use any of the existing clustering infrastructure you have

What this means practically is that the GAE is not suited for deployment of large-scale distributed applications, where fine-grained control over how jobs are split and distributed or how threads are managed is necessary.

This doesn’t mean it will not come one day, and I doubt that Google will (forever) leave this part of the market to Amazon. But for now the GAE/J is best for deploying web apps that don’t care about how their infrastructure is managed, only that it is available.

@Gridify Cloud Computing: Google App Engine – Where Does It Fit?.

No Comments

Google App Engine: killing many birds with one stone

Posted by Olivier Gérardin in Java on 2009-04-09

Logo Google App EngineAn interesting fact about the new support for Java in the Google App Engine, is that it supports real, standards based Java; in other words it runs JVM bytecode. It might sound like something trivial, but it’s not. In fact, before the announcement many people had speculated that the Java support in GAE would be based on some sort of variant of Java. Maybe they would use only the Java syntax, but not the compiler.

See GWT: on one hand you’re developing in Java, and you’re lead to believe that you are actually writing a Java application, but when the source gets translated for deployment, it’s JavaScript that is generated. There is no trace of Java whatsoever in the code that runs in your browser. Using Java as a source language is just a way to leverage existing tools and developer skills.

See also Android: here it’s not the source code that gets translated to a target code, it’s the compiled JVM bytecode that gets translated to another kind of bytecode, the Dalvik executable bytecode. And the Dalvik bytecode runs in Dalvik VM, Android’s own virtual machine. Again, no trace of Java at runtime. Again, Java is used because of the existing tools and skills.

But apparently, it goes differently with the GAE. It runs true, standard JVM bytecode. It supports WAR deployment, JDO and JPA mapping, etc. This is already a good thing in itself, but there’s an added benefit to this, which is maybe the reason why Google choose to make it this way: it can run bytecode generated by the emerging galaxy of languages that compile to JVM bytecode or run in a JVM, such as JRuby, Groovy, Jython, Scala, and others.

That’s what you call killing many birds with one stone…

, , ,

No Comments

Project Guest VM

Posted by Olivier Gérardin in Java on 2009-04-02

I’ve often wondered how realistic it was to imagine a JVM without an OS. There have been attempts to create a full-Java OS (Sun’s own JavaOS, JNode, JOS, JX, …) and I recall that when Java was first introduced, Sun promised that there would be Java CPUs that would natively run bytecode. Results have been quite disappointing so far, even Sun abandonned its own JavaOS project, and attempts to optimize bytecode execution at the CPU level have been limited to mobile platforms.

I discovered today that there is a project at Sun that takes the virtual approach. Instead of trying to create a full-blown Java OS, the Maxwell Project aims at creating a JVM that can run directly as a guest under a hypervisor without the need for a guest OS:

A Virtual Machine Monitor, or hypervisor, e.g. Xen, manages the concurrent execution of several guest virtual machines on a single computer. Guests are typically traditional operating systems but may be any system that conforms to the API exported by the hypervisor. We define a Java Guest to be an implementation of a Java Virtual Machine (JVM) that runs directly on the hypervisor API without the traditional operating system layer.

Project Guest VM Overview.

, ,

1 Comment

TheServerSide Java Symposium – Jour 3

Posted by Olivier Gérardin in Java on 2008-06-21

Troisième et dernier jour du symposium…je n’ai pas gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)

On commence par une conférence de Geert Bevin: Boldly go where the Java language has never gone before. On le sait, Java ce n’est pas qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces composants pour “pousser l’enveloppe” lorsque les limites se font sentir.

Geert cite 4 exemples pour illustrer cette approche.

  1. Terracotta: il s’agit d’une extension de la JVM qui facilite la scalabilité des applications, en permettant de mettre des JVM en cluster. Déclarativement, certains objets (“shared objects”) sont répliqués entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par toutes les instances. On a ainsi étendu le comportement natif de la JVM.
  2. RIFE continuations: déjà évoqué hier au sujet de Comet, il s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis reprendre à partir de n’importe quel état avec resume(). Les continuations sont organisées en arbre (parent = continuation à partir de laquelle on a restauré). Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion des threads.
  3. GWT: on ne présente plus GWT, Geert fait un rappel des principes de fonctionnement (translation Java->Javascript, mode hosted vs. compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java par une plateforme web pure, et seul le développement utilise le stack Java standard. Un participant pose la question du JavaScript généré, et Geert dit que pour lui c’est un problème, car le JavaScript généré est illisible et impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin pour lui expliquer que pour GWT, le browser est la plateforme, la lisibilité du JavaScript généré est aussi peu importante que la lisibilité du bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer ça…
  4. Android: la plateforme mobile de Google. Comme pour GWT, le développement et debugging se font en Java, avec les IDEs habituels, et un émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex) pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.

On aurait pu multiplier les exemples, notamment les langages dynamiques qui fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples extensions et détournements sont plus des preuves de la puissance de Java que de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus bouillonnant que jamais.

Deuxième conf: JCR: TheServerSide as a Content Application. David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR 283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une démo en prenant une page du site TheServerSide.com, et en la transformant en appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on n’arrive pas à lire le code ! J’aurais peut-être dû choisir la conf sur MapReduce dans l’autre salle…

Dernière conf du matin, Michael Keith présente What’s new in JPA 2.0. Les objectifs étaient multiples:

  • standardiser les propriétés
  • remplir les manques de l’ORM
  • rendre la modélisation objet plus flexible
  • fournir une abstraction du contrôle du cache
  • contrôle du verrouillage (locking)
  • fournir des “hooks” pour des frameworks propriétaires
  • améliorations JPQL
  • etc.

Je ne vais pas détailler les nouveautés, mais globalement il semble que le groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera sorti, il sera difficile de justifier l’utilisation directe d’une API de persistence propriétaire.Au passage, la présentation a été agrémentée d’une page culturelle sur les oies du Canada…

Comme hier et avant-hier, déjeuner avec un lance-pierres… et en plus ils ont enlevé les machines à café !

L’après-midi commence avec Choosing a Web framework, par Shashank Tiwari. En fait de conseils pratiques, il s’agit d’une énumération de définitions, de généralités, de questions (quel problème résout un framework, quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons sont bonnes de choisir un framework, y compris parce qu’il est à la mode ou pour faire bien sur son CV !!! Au final si on est en recherche d’un framework, cette conférence ne fait qu’ajouter à la confusion et à l’incertitude. Ou comment gâcher un bon sujet.

Case Study: Better Software with the Spring portfolio, par Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société qui emploie tous les committers de Spring, mais aussi certains de Tomcat et Apache. Spring, outre le framework bien connu, c’est aussi dynamic modules, batch, integration, webflow, etc.

On nous propose un cas de système de traitement de commande à architecturer autour de Spring. Le système peut recevoir des commandes par Web Services. La démarche classique est de définir une interface Java, implémentée par un POJO, et de générer le WSDL à partir de cette interface. Or cette démarche présente des inconvénients: le WSDL expose de facto l’interface d’une classe interne.. que se passe-t-il si le WSDL doit changer? D’autre part certains types communs en Java, comme Map, ne sont pas supportés en WSDL…Eberhard propose d’inverser la démarche: puisque le contrat avec les clients est le WSDL, on part du WSDL et on base le traitement d’une commande sur le schéma XML correspondant. Ansi on n’expose pas d’interface interne, on traite un objet Java généré à partir du message envoyé, via un système de mapping (JAXB/XStream). La logique est découplée de l’interface. La classe qui traite le message est un Endpoint qui est annoté via les annotations Spring. Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML, mais qu’on peut très bien faire du Spring sans XML (ou presque, soyons honnête..)

Pour rendre robuste le WebService, on peut aussi baser le traitement du message sur des expressions XPath. Ceci permet d’avoir un contrôle plus fin sur des messages qui seraient incomplets, et donc ne pourraient pas être mappés avec la solution précédente.

Eberhard introduit également les notions de pipes et filtres, qui sont des pipelines de traitement, supportés par Spring Integration, et configurables par XML (tiens donc).

Spring fournit également une approche à la notion de batch, mal résolue en Java; notamment le problème des redémarrages en cas d’interruption volontaire ou non. Un batch Spring c’est une série d’étapes, chaque étape lit quelque chose (un record dans une base probablement) et écrit quelque chose (résultat du traitement). Cette notion est supportée par Spring batch.

Dernière conf de la journée, et du symposium: Real GWT applications, par Jeff Dwyer. Une énième présentation rapide des principes de GWT, et une petite démo sur le site tocollege.net, dont une partie est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur les problèmes pour envoyer des objets métier au client provenant d’hibernate: les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin que ce n’est pas forcément la meilleure idée, et qu’avec Dozer il est facile de populer des objets spécialisés pour les transmette au client, car je n’ai pas forcément envie de voir mes objets métier transiter sur le fil, on ne sait jamais ce qui peut s’y trouver demain…

Jeff conseille judicieusement d’utiliser un pattern Command pour les communications du client. Il aborde la sécurité, notamment les attaques XSRF, et présente Goggle Gears pour les applis offline.

La présentation était un peu rapide, mais l’intérêt pour la techno est évident. J’espère que cette présentation (qui a été donnée deux fois lors du symposium suite à la forte demande !) y aura contribué.

Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été présentées, et on sent qu’on est à un tournant car pour ainsi dire “ça part dans tous les sens”, l’écosystème Java, aux frontières autrefois bien nettes, commence à devenir une galaxie en expansion avec des projets qui poussent l’enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on n’a pas abordé les closures !). Le monde Java de demain sera certainement bien différent de celui d’aujourd’hui, mais Java en restera probablement le centre de gravité…

Il me reste à visiter Prague (superbe ville) et regarder les Turcs se qualifier sur l’écran géant au centre ville…

, , , , , ,

No Comments

TheServerSide Java Symposium – Jour 2

Posted by Olivier Gérardin in Java on 2008-06-19

La journée d’aujourd’hui a commencé fort, avec un keynote de Neal Ford Language Oriented Programming: Shifting Paradigms. Une présentation impressionnante, avec des slides à faire pâlir d’envie Al Gore, et une parfaite maîtrise…

S’appuyant sur un cas concret, Neal montre que la façon de résoudre un problème dans le monde informatique d’aujourd’hui est souvent de créer un framework (aussi petit soit-il) qui généralise le problème, puis de le configurer pour résoudre le cas particulier qui nous préoccupe. Or cela conduit à du code qui est rempli de “bruit” (comprendre: redondance et constructions syntaxiques), illisible par les personnes du domaine métier, et donc ne peut être validé. Que fait-on alors? On externalise le code dans un fichier de paramétrage, XML forcément, mais ça ne le rend pas plus lisible par le métier…

La solution ce sont les DSL, Domain-Specific Languages, qui permettent d’exprimer des notions propres au métier d’une façon accessible aux hommes du métier. On peut les diviser en:

  • DSL internes: utilisant les constructions du langage hôte
  • DSL externes: indépendants d’un langage

Un exemple de DSL interne en Java est JMock, qui permet d’écrire des choses du genre:

one(gt).getGreeting(); will(returnValue(”Good afternoon”));

C’est ce quon appelle “fluent interface”, car on cherche à imiter le langage naturel, quitte à introduire des artefacts sans utilité (“bubble words”). En Java ça reste fortement contraint par la rigidité du langage, mais dans les langages dynamiques on peut faire des choses beaucoup plus avancées.

XML est une forme de DSL externe, a fortiori.. Mais selon Neal XML est obsolète ! (Pas de polémique…). Le futur c’est de modéliser le métier à un niveau d’abstraction supérieur, que ce soit via un langage ou en manipulant un arbre abstrait (ce que certains IDEs tendent déjà à faire), et ensuite d’exécuter le résultat dans un contexte qui, selon le cas, donnera un schéma de DB, un exécutable, etc.

Ce fut de loin la meilleure conf des 2 premiers jours, prenante et stimulante…

Ensuite je choisis d’assister à la conf Son of SOA: Event-Driven Architecture and the Real World, par Eugene Ciurana (LeapFrog). Ca commence par des challenges (calendrier serré, équipe à construire, politique IT rigide, existant à intégrer, …) qui sont autant de challenges si on les voit d’un autre angle. Le choix a été de mettre en place un architecture Resource-Oriented, où tout est considéré comme une ressource, services comme données, et acccessible par une URI. Même si ça ressemble furieusement à du REST, Eugene s’en défend; en effet il y a quelques différences, notamment le mélange entre verbe et nom dans l’URI, mais globalement la différence est si fine qu’elle est invisible.

Eugene a mis en place des outils “best of breed”, avec MuleESB à la place d’honneur, en tant que backbone et resource container. Aussi choisis: Crowd pour le SSO, GWT (tiens…), Wicket, Communiqué (CMS). Au final une success story bien ficelée.

Ensuite je vais découvrir Comet: Building a richer, more interactive web application, avec Ric Smith de kaazing.com. Il s’agit d’expliquer les mécanismes qui permettent de faire du reverse push, ou reverse AJAX, c’est à dire de permettre à une application AJAX d’être notifiée par le serveur de nouveaux événements, par opposition au polling où c’est le client qui interroge périodiquement le serveur. Les avantages sont clairs dans des applications type finances, jeux ou paris, ou tous domaines où le 1/10 de seconde peut faire la différence.

Historiquement, la première façon d’implémenter le push est un iframe invisible, dans lequel le serveur reçoit en continu des balises <script> qui déclenchent l’exécution de callbacks côté browser. Ca marche, mais avec des effets de bord parfois très gênants (clignotement du curseur, fuites mémoire, …).

Deuxième technique, le XHT long-polling: le client lance une requête qui ne revient que lorsque des données sont dispo. La connexion est fermée, et ré-établie immédiatement. Problèmes: léger overhead dû à la reconnexion, et latence possible.

Autre option, XHR streaming. Pour cela, on a besoin que le browser implémente “onreadystate”. La réponse à la requête XHR ne se termine jamais, et lorsque des données sont dispo un callback est appelé. Principal souci, le support limité de cette fonctionnalité dans le parc de browers.

Dernière option, la connexion socket, qui nécessite un plugin (Flash, SIlverlight, Java). Ici on s’appuie sur des fonctionnalités du plugin pour établir une connexion serveur rémanente et notifier le browser.

Enfin, à l’avenir HTML5 intégrera la notion de server-side events, et le serveur pourra alors envoyer un type MIME application/x-dom-server-event qui activera un callback. Mais ce n’est pas pour demain.

Un point important à considérer est le couplage connexion-thread qui existe dans les serveurs classiques; en effet si 100 000 clients sont en attente d’évenements, on ne peut pas admettre de créer autant de threads. Jetty et d’autres résolvent ce problème avec la notion de “Continutation” qui permet de rendre les threads indépendants des connexions.

Un tour d’horizon super intéressant du problème !

Avant de manger, un Expert Panel: Languages: The Next Generation, composé de Ted Neward, Ola Bini et Guilaume Laforge, discute de la prochaine génération de languages. C’est très divertissant, et il en ressort surtout qu’il n’y aura pas de “next big language”, mais que comme Neal Ford l’a prédit, les DSL vont prendre le devant de la scène, avec les langages dynamiques…

Midi, cette fois j’ai compris le truc pour ne pas faire la queue aux plats chauds: d’abord le buffet froid où il n’y a personne, ensuite les plats chauds!

Je saute le Vendor Tech Brief, encore GigaSpaces (eh oui ils sont le principal sponsor). Je vais récupérer mon T-shirt JavaBlackBelt gagné au concours hier, et une petite démo de JavaRebel s’avère assez impressionnante: rechargement à chaud des classes sans arrêt redémarrage! Un confort et une productivité qu’on a oublié sous Java, à force d’appeler des scripts ant et de redéployer à tout bout de champ.

The Enterprise Without a DB, par John Davies: ça fait longtemps que je traîne l’obligation de travailler avec des bases relationnelles comme un boulet, d’où mon intérêt pour ce sujet. John montre l’absurdité de la situation: le schéma FpML compte plus de 4000 éléments, et peut aller jusqu’à 12 niveaux de profondeur. Il est quasiment impossible de mapper un tel schéma avec un ORM. Les DB XML de leur côté n’ont pas d’API standard, et ont des performances sous optimales. Ce que propose John: utiliser le caching, la mémoire quoi, et travailler avec un data grid. Il cite plusieurs outils qui tendent vers ce but: GemStone, TangoSol (acheté par Oracle), GigaSpaces, Terracotta.

Malheureusement, de trop nombreux outils (reporting, etc) et un poids historique des tenants du camp “DB” rend cette approche exotique, et pour encore longtemps.

What’s new in EJB 3.1, par Anotnio Goncalves: Non EJB n’est pas mort! Même si la spec 2.1 l’a presque tué… Aujourd’hui les EJB 3 (JSR 220) sont un soulagement pour qui fait des EJB: POJOs, interfaces simples, injection, annotations, peu de XML à écrire… Les EJB 3.1 (JSR 318) ont pour objectif de les rendre encore plus simple à utiliser, et d’amener de nouvelles foinctionnalités. On note déjà que JPA a son propre JSR (317), ce qui aidera peut-être à redorer son blason. Ensuite l’interface locale devient facultative! l’injection reste obligatoire. Il sera aussi possible de packager des EJB dans un WAR tout simplement, en gardant la fonctionnalité EJB. Enfin différents profils seront définis: A (minimal, pas d’EJB), B (EJB lite), full (EJB complet plus une trentaine d’autres specs). Nouveau encore: la notion de singleton, les appels asynchrones, et le timer service.

Java EE 6 (sortie Q1 2009) embarquera EJB 3.1.

On finit par un Fireside Chat: Zero Turneround in Java Development, où je revois les démos JavaRebel et Grails, plus Geert Bevin (Uwyn) qui présente RIFE.

Rendez-vous demain pour la clôture!

, , , , , ,

No Comments

TheServerSide Java Symposium – jour 1

Posted by Olivier Gérardin in Java on 2008-06-18

Le TSSJS Europe se tient à Prague cette année, du 18 au 20 juin. Les thèmes majeurs proposés sont assez alléchants, jugez-en:

  • les frameworks web (spring, struts, JSF)
  • les nouveaux langages de l’écosystème java (groovy/grails, scala, jruby)
  • les nouvelles versions de spécs (JEE 6, EJB 3.1, JPA 2.0)
  • concurrence, performance, scalabilité
  • SOA

A part quelques événements communs (keynotes, etc) il y a en général 3 sessions simultanées, ce qui rend parfois le choix cruel…

Le premier keynote “Supporting RIA space” est délivré par Stephan Janssen, le fondateur et président du BeJUG, fondateur de JavaPolis et de parleys.com, un site qui met en ligne des conférences filmées avec les slides synchronisées. C’est ce site qui lui servira de support pour tester différentes technologies RIA dont il nous fera part…

Premier point délicat: définir une application RIA… Pour la petite histoire le mot a parait-il été inventé par Macromedia, et donc absorbé par Adobe. Mais ça ne nous avance pas. Un application RIA c’est une application Riche (mais pas tout à fait comme une application desktop), et qui utilise Internet (mais pas forcément tout le temps)…

Bref l’éventail est grand, RIA encore mal cerné, et les technologies qui permettent de faire du RIA innombrables. Stephan en a retenu quelques unes et a expérimenté le portage du site parleys.com sur ces technos.

  1. le site original, HTML, rien à dire
  2. refactoring en DHTML/JavaScript avec Scriptaculous. Conclusion: il faut un doctorat en JavaScript, et la compatibilité cross-platform est un enfer… (quelle surprise!)
  3. GWT: développement et debugging agréable en Java avec les outils Java, support du bouton back, et “99% cross platform” ( un seul if/then dans tout le code). Un seul point noir est relevé par Stephan: le site n’est pas indexé correctement par Google!
  4. Flex: le résultat est extrêmement semblable à GWT, avec un peu plus d’”eye candy”, transitions animées et choses similaires. Techno mature, mais l’indexation Google est inexistante, sauf à utiliser des artifices (redirections)
  5. JavaFX: résultat sexy style Flex, avec en plus la possibilité d’utiliser le Java existant. Pas de support Mac…

Au final le site actuel est la version Flex, avec intégration AIR, mais on note bien que GWT n’a reçu que des éloges…

Deuxième conf, là il faut choisir… JSF? qui utilise encore JSF… JPA/Hibernate? déjà fait… Je reste donc dans la salle principale pour entendre Costin Leau (SpringSource) parler de “Spring Dynamic Modules“.

On le sait, Java ne gère pas les versions des classes ou le remplacement dynamique, et il est impossible à deux versions d’une même classe de coexister. OSGi fournit une solution, en définissant une notion de “module” ou “bundle”, qui est simplement un ensemble de classes, auquel s’appliquent les notions de

  • cycle de vie
  • “class space”
  • règles de visibilité
  • versionnage

Un service au sens OSGi c’est simplement une classe, un POJO qui exporte des méthodes au travers de la visibilité. Le reste est caché de l’extérieur, ce qui permet à plusieurs versions de cohabiter sans conflit. Spring 2.5 sera OSGi-compliant et intègrera la notion de bundle. On pourra également réagir aux événements qui affectent le cycle de vie des services (création, suppression, etc). Les dépendences OSGi sont localisées dans le contexte Spring, et non dans le code.

Au final cela semble très prometteur, reste à voir dans quelle mesure cela s’appliquera à nos développements. Annoncé également, la sortie du futur S2AP, SpringSource Application Platform… Pas plus de détails là-dessus.

Deuxième session de la matinée: monitoring, management sur la plateforme Java 6, par J-F Denise, responsable JSR 262 chez Sun.

Beaucoup de rappels sur JMX et les MBeans, l’agent JMX, l’agent remote… Depuis Java 5, l’outil JConsole est fourni avec le JDK et permet d’interroger une JVM qui tourne, y compris des MBeans. C’est une bonne chose de le rappeler, car le JDK est fourni avec beaucoup d’outils trop peu connus, car pour beaucoup l’IDE est la seule interface qui existe avec Java.

Implémenter un MBean est simple (juste une interface), mais peut poser des problèmes: si le MBean retourne un type composite sous forme d’une classe maison, il faut que le client JMX dispose de cette classe aussi dans son classpath !! Pour relaxer cette contrainte, Sun introduit les MXBeans, qui permettent de faire cela, et via un mécanisme interne, transforment les objets complexes sérialisés en des classes standard qui peuvent être lues par le client sans modification de son classpath.

Autres outils fournis avec le JDK 6: jps, jmap, jhat, jinfo… Et un nouvel outil qui ne fait pas à proprement parler du JDK: jvisualvm. C’est un outil intégré et extensible de troubleshooting, fonctionant avec des plugins, et qui regroupe les fonctionnalités éclatées dans divers outils… La RC1 est disponible depuis le 6 mai.

Avant de manger, un keynote par Nati Shalom de GigaSpaces “Getting ready for the cloud“. Il s’agit en fait de 40 minutes de marketing pendant lesquelles le message est martelé sur tous les tons: vos applications ne sont pas scalables, parce que bâties sur des silos. La solution: remplacer les silos par un “cloud”, une plateforme qui virtualise les 3 tiers habituels (middleware virtualization) et qui est la seule à pouvoir assurer le “scaling on-demand”. Et comme par hasard, GigaSpaces a un framework qui le permet. OK, le message est passé.

Déjeuner avec un lance-pierre, pas le temps de digérer on attaque l’après-midi. Eh non, après avoir erré dans les coursives, je me rends compte que la conf qui m’intéressait (Comparing Dependancy Frameworks) est annulée… J’assiste sans conviction à un case study “Using JSR-272 and Spring for a Monetary System”.

Ensuite, encore un dilemme: Holly Cummins, spécialiste des outils de diagnostic chez IBM (au style capillaire improbable), présente “Java Performance Tooling”, mais je choisis “Simplifying JEE Development with Grails” par Guillaume Laforge, project manager de Groovy.

L’idée de Grails c’est d’appliquer les principes de productivité de Ruby et Groovy, tout en s’appuyant sur les bibliothèques et infrastructures existantes (Java, Spring, Hibernate, servlet containers, etc.). Par exemple, Grails génère un WAR, qui peut être déployé tel quel sur un serveur d’applications. Grails utilise GORM, un ORM bâti sur Hibernate, WebFlow, domain-specific languages, GSP (un équivalent de JSP), supporte des plugins, et nécessite aussi peu de fichiers de configuration que possible grâce à des conventions de nommage.

La démo est impressionnante, en quelques lignes et en live Guillaume crée deux classes, les relations entre elles, les tables correspondantes, les mappings relationnels, les finders, les controleurs, l’interface web… et redéploie sans redémarrer quoi que ce soit! Est-ce que ce serait Ruby on rails, avec la scalabilité et la puissance en plus??

Conf suivante, je choisis une prés de GlassFish, par Antonio Goncalves (Paris JUG). Pas grand chose à retenir, Glassfish est prêt pour la production, scalable, clusterisable, avec une belle interface d’administration (bon tous les gouts sont dans la nature). C’est l’implémentation de référence pour Java EE 5 et 6 et il est open source.

Plus intéressant, mais on ne s’étendra pas dessus, ce qui est annoncé pour la v3: un noyau ultra léger et ultra rapide (HK2: Hundred Kbyte Kernel), modulaire, avec des modules web, EJB, JRuby, PHP, JavaScript, etc. et le support OSGi! Bref, on reviendra.

Ouf, c’est fini, une bière, remise des prix du concours GigaSpaces/OpenSpaces… je discute avec le gagnant, un Brésilien qui a réalisé un projet pour la distribution des surplus alimentaires au Brésil (avec GWT en front!), l’occasion de pratiquer mon portugais :)

Demain la suite…

, , , , , ,

No Comments