Au sujet de ZeroTurnaround

ZeroTurnaround

ZeroTurnaround est un petit éditeur logiciel Estonienne (le même pays à l'origine de Skype, Kazaa, etc). Nous construisons de petits outils qui apportent une grande valeur ajoutée aux équipes de développement (ainsi qu'à leur budget). Par exemple, JRebel est un fichier JAR qui fait moins d'1Mb, facile d'installation et d'utilisation, qui économise entre 3 et 7 semaines de temps de développement perdus (sur la base de semaines de 40 heures) et vous coûte moins de 150 $ par an. C'est un assez gros challenge. A mesure que nous grandissons, grandit notre vision de l'amélioration de la qualité, de la cohérence, et de la productivité dans l'industrie du logiciel.

Jevgeni Kabanov - Founder, Chief Technical Officer

Image non disponible

Auparavant, Jevgeni travaillait en tant que directeur R&D de Webmedia, Ltd, la plus grande société balte de développement de logiciels custom. Dans le cadre des efforts de réduction du temps de développement, il écrivit un prototype de JavaRebel et en dirige, depuis la création de ZeroTurnaround en 2007, le développement. Il est speaker depuis quelques années lors de conférences internationales, parmi lesquelles JavaPolis/Devoxx, JavaZone, et JAOO sur des sujets comme : "Do you really get Classloaders" à "Zero Turnaround in Java Development". Il a un intérêt certain pour la recherche, avec de nombreuses publications sur des sujets allant de notions théoriques jusqu'aux typesafe DSLs Java. A côté des produits commerciaux réalisés dans le cadre de ZeroTurnaround, Jevgeni est le co-fondateur de deux projets open-source - Aranea et Squill. Aranea (www.araneaframework.org) est une plateforme de développement web et d'intégration basée sur de solides principes orienté objet. Squill (squill.dev.java.net) est un DSL interne type-safe pour la construction et l'exécution de requêtes SQL. Le blog personnel de Jevgeni peut être trouvé sur dow.ngra.de.

David Booth - Chief Executive Officer

Image non disponible

David a été en charge du marketing d'outils de productivité dans l'industrie Java depuis 2001, en commencant par JProbe, puis pour JetBrains (IntelliJ IDEA), prêchant pour la qualité dans le logiciel et l'amélioration de la productivité des développements. Il est convaincu par la nécessité de soutenir les communautés d'utilisateurs, et a fondé sur son temps libre le Young Professionals Forum à Prague où il réside.

I. ZeroTurnaround

I.1. Combien de salariés sont employés par ZeroTurnaround ?

Jevgueni : Une peu moins de 10 en ce moment, sachant que cela évolue au rythme du recrutement de nouvelles recrues ... d'ailleurs connaissez-vous des ingénieurs intéressés pour travailler en Estonie, ou des commerciaux et marketeux intéressés par Prague ?

I.2. Quel EDI est principalement utilisé par les équipes de ZeroTurnaround ? Pourquoi ?

Jevgueni : Tout le monde utilise Eclipse. C'est probablement en partie de ma faute, étant donné que j'étais un fervent partisan d'Eclipse il y a quelques années. Maintenant ca m'est indifférent, mais je pense qu'Eclipse possède de meilleures fonctionnalités Java de base, et nous ne faisons pas vraiment de développement web. Nous achèterions probablement des licences IDEA si nous avions à faire du web, mais je continue à être mécontent de leur support du Compile-On-Save et je pense qu'Eclipse a de l'avance sur cet aspect.

I.3. Certaines sociétés refusent de payer sur base d'autre chose qu'une facture et uniquement via un transfert bancaire. Comptez vous utiliser autre chose que les cartes de crédit comme moyen de paiement ?

Jevgueni : En fait, même si ce n'est pas écrit explicitement sur notre site web, la plupart des commandes importantes viennent avec une facture et un virement direct. Les sociétés nous contactent simplement par email et nous nous arrangeons pour répondre à ce besoin. J'adorerais pouvoir faire cela d'une manière automatisée, mais je ne pense pas que notre banque prenne en charge l'un de ces services.

David : Ce genre de choses est finalement assez simple à mettre en place. Envoyez simplement un email à sales@zeroturnaround.com

II. L'outil JRebel

II.1. Comment et quand le projet JRebel (anciennement JavaRebel) a-t-il vu le jour ?

Jevgueni : JRebel a démarré avec une idée courant Août 2006. A cette époque, je travaillai sur le rechargement à chaud chez Aranea, et j'ai soudain eu l'idée de faire du rechargement à chaud pour n'importe quel fragment de code Java. C'était assez compliqué, mais après quelques recherches j'ai pu mettre au point un prototype et le faire marcher en Mars 2007. En Septembre 2007 nous lancions une version publique en beta et les premières ventes ont démarré en Octobre la même année. Cela a été un parcours passionnant depuis.

David : Ce vendredi 16 avril (2010) nous avons sorti JRebel 3.0 et nous mesurons le long chemin parcouru depuis la première version. JRebel se concentre toujours encore sur l'élimination de la phase de redéploiement dans le développement Java EE, mais possède également un support pour les EDI, gère les changements sur la structure de classe, prend en charge le build instantané (avec des EARs, WARs, Maven, Ant), les changements dans la configuration (Spring, Guice, Struts 1 et 2, Log4J, Tapestry4, Wicket, Stripes, Velocity), et couvre les version 1.6 à 1.4 de Java.

II.2. Estimez-vous aujourd'hui avoir des concurrents sur le créneau couvert par JRebel ?

Jevgueni : Aucun qui ne nous inquiète.

David : Cela sonne comme une réponse typique de commercial ! Comme nous nous amusons à inverser les rôles, je vais compléter la réponse pour celle-ci. La version courte est "oui, nous avons des concurrents". Il y a HotSwap, "Hot Redeploy" - qui se décline selon différents noms (comme "FastSwap") selon le conteneur qui l'implémente. Malheureusement, à la fois HotSwap et Hot Redeploy ont d'importantes lacunes ... il est plus simple d'observer ce comparatif pour se faire une idée.

II.3. Avec que EDI JRebel est-il actuellement le mieux intégré ? ZeroTurnaround se charge-t-il de proposer une intégration pour tous les EDI principaux du marché ou s'appuie sur les communautés de ces derniers ?

Jevgueni : Nous fournissons un niveau de support environ équivalent pour Eclipse et IDEA. Le plugin NetBeans ne dispose pas de toutes les fonctionnalités que nous proposons pour les autres EDI. Il y a quelques contributions par la communauté (par exemple, le plugin IDEA était initialement une contribution), mais le plus souvent nous prenons en charge leur développement.

II.4. Quels sont les prochains challenges pour JRebel après la version 3.0 ?

Jevgueni : Et bien, il y a de nombreuses choses que nous avons initié avec la version 3.0 que nous allons continuer de complémeter. Le support complet de JPA en fait partie. Mais nous allons également mettre notre énergie sur le développement de LiveRebel, lequel dispose d'un gros potentiel et est attendu par plus de 200 sociétés. Cela se traduira aussi par une innovation importante pour JRebel.

II.5. Quels sont les plugins que vous comptez rajouter par la suite à JRebel, pour le support d'autre framework. Je pense par exemple actuellement à JSF, dont la configuration n'est pas mis à jour par JRebel et pour lequel l'ajout de bean nécessite quand même un redémarrage, ou commons-chain, qui charge une seul fois ses catalogues.

Jevgueni : JSF est pris en charge dans la version 3.0 :) Mojarra est d'ores et déjà supporté, et MyFaces le sera également bientôt. Nous aimerions désormais moins nous concentrer sur le support des frameworks et davantage à permettre à la communauté de contribuer aux plugins plus facilement. Il est déjà assez simple de créer des plugins pour JRebel, mais nous prévoyons de le rendre très vite encore plus simple. Si vous vous intéressez à l'écriture d'un plugin pour une framework en particulier, faites moi signe directement par mail sur jevgeni@zeroturnaround.com

II.6. Si ce n'est pas un secret, combien de licences, approximativement, avez vous vendue de la version 2.2.1, quel évolution envisagez vous pour les ventes de la version 3 ?

Jevgueni : Pour être honnête, je ne suis pas sûr du nombre de tête. C'est de l'ordre du millier. Je sais que nous avons plus de 10 000 téléchargements par mois, et cela augmente à la manière de la forme d'une crosse de hockey ... hmm... peut-être n'est ce qu'une expression valable au Canada ? Avec la version 3.0, nous modifions légèrement le modèle des licences, mais le changement le plus notable est l'ajout de l'Enterprise Add-On. Nous ajoutons le support de technologies anciennes qui donnent mal à la tête à bon nombre de gens ... versions majeures de serveurs d'applications en fin de vie, EJB 1.x et 2.x, et l'ajout d'un serveur de licence qui permettra les plus importants consommateurs de gérer leur parc de licences d'une manière plus efficace. Toutes les licences continueront à être sur une souscription annuelle, et continueront à vous faire économiser en moyenne 5 semaines de temps de développement en redémarrage et redéploiement. Vraiment impressionnant.

III. La JVM et le système de gestion dynamique des modules

III.1. Quelles limitations technologiques de la JVM aimeriez vous voir disparaître pour améliorer votre produit. Autrement dit, avez vous des fonctionnalités que vous aimeriez voir dans JRebel mais qu'il est techniquement impossible de réaliser à cause de la JVM ?

Jevgueni : En haut de ma liste : Interface Injection. Comparativement, cela devrait être simple à prendre en charge, étant donné que je suppose que cela ne nécessite pas nécessairement la mise à jour des vtables (qui sont inline dans la JVM de Sun et sont la raison pour laquelle HotSwap ne permet pas l'ajout de méthodes).

III.2. ZeroTurnaround pourrait-il être intéressé de participer à l'amélioration dans OpenJDK du fonctionnement du ClassLoader et de HotSwap ?

Jevgueni : Cela serait certainement intéressant de faire cela, nous avons discuté de cette opportunité mais nous n'avons rien décidé pour le moment.

III.3. Que pensez-vous de l'effet de mode OSGi ?

Jevgueni : C'est effectivement tendance. OSGi n'est qu'utile aux développeurs de frameworks et de serveurs, les applications ne devraient pas à avoir à s'en préoccuper. C'est une abstraction bas niveau utile, mais trop générique pour les applications. La bonne façon de l'utiliser consiste à construire une couche modulaire spécialisée par dessus.

J'ai également un problème avec la façon dont les class loaders sont utilisés. Il est bien connu que les dépendances circulaires avec OSGi peut occasionner des interblocages (deadlocks) de class loader. Et je suis assez convaincu qu'OSGi favorise les leaks de class loader (ce n'est pas vraiment de sa faute, mais le modèle du class loader en Java n'a jamais été pensé pour être utilisé avec un graphe).

IV. A venir ...

IV.1. Espérez vous voir se développer une communauté autour de votre système de plugin, où tout un chacun hébergerais, peut être chez vous, ses propres plugins à destination du public ?

Jevgueni : Oui, c'est l'objectif :) Nous envisageions quelque chose de ce genre, mais nous avons constaté que sans notre attention, les pages communautaires tendent à rapidement stagner. Maintenant que l'adoption de JRebel progresse de manière exponentielle, nous avons vraiment besoin de relancer cette communauté de plugins rapidement.

IV.2. LiveRebel, actuellement en beta privée, est-il la suite logique de JRebel ? Pouvez-vous nous parler un peu de ce nouveau produit ?

David : Nous avons eu énormement de demandes de nos clients pour transposer la technologie JRebel du domaine du développement vers celui de la production et des applications en production. Cela a du sens pour nous d'étudier ce besoin de manière très sérieuse et de voir ce que nous pouvons proposer. J'ai relevé une citation quelque part qui disait que si Amazon.com venait à tomber, cela leur coûterait 31 000 $ par minute, et j'ai connaissance d'entreprises pour lesquels le coût serait plus élevé - donc nous aimerions aider les entreprises à conserver leurs applications en ligne même dans le cadre de procédures de mise à jour mineure. Pour ceux qui sont interessés, nous avons un groupe pour la beta privée de LiveRebel, auquel nous allons porter toute notre attention sur l'année à venir : http://groups.google.com/group/liverebel-private-beta

IV.3. Pourrait-on voir apparaître dans l'offre de ZeroTurnaround des JRebel like pour d'autres plateformes, comme par exemple DotNET ?

Jevgueni : J'aimerai pouvoir répondre oui à cette question :) Nous avons étudié la plateforme .NET et il lui manque les éléments nécessaires à la mise à disposition de fonctionnalités que nous avons pour Java. Cela est principalement dû à des manques dans le classloader qui est une formidablement puissante abstraction qui peut devenir dangereuse lorsqu'on en abuse.

V. Conclusion

V.1. Un message à faire passer à la communauté francophone Java ?

David : Bien sûr -- allez vous impliquer dans vos JUGs (Java User Groups) locaux. Au cours de ces dernières années, les communautés françaises de JUG ont réellement percé dans de nombreuses villes de France. C'est formidable de voir tant de gens se réunir pour parler de Java et s'aider mutuellement !

V.2. Remerciements

Merci à David et Jevgueni d'avoir pris le temps de répondre à nos questions.
Merci également à ellene pour la relecture de la présente restitution.

V.3. Liens