Les pieds dans le code

Après avoir déménagé le gestionnaire de projet de CodeHaus à Kenai (la forge selon Sun), JRuby change de gestionnaire de version pour passer de Subversion à Git

L’annonce de Headius: JRuby moves to Git

ça va forker !

C’est pas tout frais, mais Jruby vient de sortir en version 1.2.

Au menu:

• Un bon support des fonctionnalité de Ruby 1.9
• Le compilateur marche (cela permet de compiler des classes Ruby en byteCode Java)
• Amélioration des performances (un classique) sur le parseur, et le runtime
• Un début de support pour Android (le projet est nomé Ruboto)
• Un gros paquet de bugs sont fixés (un peu trop long pour être listé ici :-))

Ce projet avance vite et bien. Je ne sais pas à quel niveau de compatibilité sont arrivé les autres VM aujourd’hui,je pense à Rubinius et IronRuby surtout (vous en connaissez d’autres ?), mais certainement aussi bien. Je fais parti de ces gens qui pense que c’est une bonne chose, et vous ?

J’ai raté ça, mais le 17 décembre, Thomas E Enebo annonçait la sorti de JRuby 1.1.6.

Cette version corrige pas mal de bug, notemment sur l’objet IO (qui ces dernier mois a été l’objet de pas mal de remonté de bug). Cette version prépare également le support de la version 1.9 de Ruby: le parseur est complet, la pluspart des objets du core, des standard lib sont supporté.

Le projet est toujours aussi actif. C’est bon pour Ruby et c’est bon pour les développeurs. J’espère que les entreprises frileuses qui ont déjà adopté Java accepterons plus facilement l’utilisation de Ruby par ce biais.

La nouvelle version de JRuby viens de sortir: Jruby 1.1.4 .

Au programme, pas mal de chose dont

• Un gros refactoring de la couche d’intégratiohn java.
• de 2 à 20 fois plus rapide sur la plus part des fonctionnalitées
• Les exceptions java peuvent être maintenant récupérer directement dans Ruby
• Amélioration de la gestion mémoire
• Début du support de Ruby 1.9 (vivement les fibres dans jruby ! je veux voir ça)
• Amélioration des performances
• Pool de Thread amélioré
• Accès concurent sur les tableaux amélioré
• Et 72 bug résolu depuis la version 1.1.3

Dans les prochain mois, l’équipe va travailler pour essayer de sortir des release plus fréquement (quelque chose comme une fois par mois). Le but étant de corriger au plus vite les divers problème, et apporté les évolutions plus rapidement aux utilisateurs.

Un bon projet toujours sur un bon rythme :)

Jruby vous connaissez ? C’est l’implémentation Java du langage de programmation Ruby. Une implémentation qui à mon avis séduit ou séduira la plus part des entreprise ayant déjà une infrastructure basé sur la technologie Java.

Et bien cette semaine, c’est la dernière ligne droite, Tom a déclenché les hostilitées en annonçant la sortie d’ici la fin de semaine de la nouvelle version 1.1.3 de cette implémentation, et du coup propose à tous de signaler ce qu’ils souhaitent voir dans cette version (archives de l’annonce: JRuby 1.1.3 by end of week…Nominate problems here…. Charles Oliver Nutter a surenchéri en faisant suivre le message sur la mailing list User (The reason we’re pushing 1.1.3 now is so we can finally branch 1.1 into
full maintenance mode and start hitting Java integration hard.

Les demandes pleuvent, je vous prévient un peu tard peut-être pour participer, mais essayé toujours. Au pire on fera les tests sur cette nouvelle mouture.

Bien que le projet OpenJDK porte doucement ces fruits afin de permettre la mise en place de l’environnement Java sous licence libre. Et bien qu’"OpenBSD":http://www.openbsd.org propose pour la 4.4 et en 4.3-current un paquet pour la jdk 1.7. On a des fois besoin d’acceder à une plus ancienne version du JDK, j’ai nomé la 1.5 (assez courante dans les applications pas toute neuve ;-)).

C’est toujours possible dans OpenBSD, il suffit de passer par les ports. Il faut également, pour des problèmes de licence, télécharger un tas de path supplémentaire après avoir accepter la dite licence.

Mais surtout, surtout ! ce qu’il ne faut pas oublier, c’est de mettre à jour son arbre des ports !!! Ca évite de ne pas comprendre pourquoi ça ne veut pas compiler, et pourquoi la version requise d’iconv est la 4.0 alors que la 5.0 à été trouvé sur la machine grrrbbllll

Alors pour mettre à jour l’arbre des ports, rien de plus facile:

$ cd /usr/ports
$ sudo cvs -q -d anoncvs@some.anon.server:/cvs up -r OPENBSD_4_3 -Pd

Le -r est le tag Cvs qui correspond à la version 4.3, quand on suit -current, il faut l’enlever.

Une liste des serveurs anoncvs est disponible sur le site officiel à l’adresse http://www.openbsd.org/anoncvs.html#CVSROOT

Et je peut vous dire qu’avec l’arbre des ports à jour, ça marche vachement plus meilleur la compilation de la JDK sur Open :)

PS: A noter que la jdk 1.3 et 1.4 seront supprimer prochainement. C’est dans le rapport hebdo sur l’état des ports dans l’arbre chez undeadly.org

L’annonce ce Sun commence à dater un peu, mais les effets se font doucement ressentir.

Du coté OpenBSD, qui contrairement à ce que dit ce trolleur RMS ;-), faitr très attention au licence utilisé sur chacun des paquets mis à disposition, l’installation de Java se simplifie !

Plus la peine d’installer la JDK via les ports depuis la version 1.7 de cette dernière. Effectivement, en préparation d’OpenBSD 4.4 et donc dans la 4.3-current, nous disposont maintenant d’un paquet , directement !

Pour les versions antérieur, et toujours distribué sous licence Sun, il faut continuer à aller accepter la licence sur le site de sun et télécharger quelque 5 paquet pour compléter l’installation…

Je me demandais ce qui me pousserais à tester cette dernière version de VM, mais c’est tout vu !

ps: C’est en fait une vieille news de "Kurt Miller (kurt@) sur journal officiel d’OpenBSD":http://www.undeadly.org/cgi?action=article&sid=20080321023803

Quel est le plus performant ? Quel est le plus sécurisé ?

Aujourd’hui, nous utilisons principalement un frontal web qui redirige ensuite, au travers d’un bien souvent, les requêtes sur un serveur d’application. C’est le cas des techno Java avec les Tomcat et Glassfish, et par les techno Ruby avec Mongrels entre autres, mais même les petits nouveaux s’y mette: thin, ebb.

Ebb justement est le serveur d’application auquel je m’interesse ces dernier temps, c’est apparement un des plus performants. Ce qui m’interesse également c’est la possibilité d’utiliser les socket unix.

J’ai un peu de mal à mettre en place cette solution pour le moment, dès que c’est fait, je pourrais faire des test de performance.

Mais une question me harcèle: Est-ce qu’il est mieux d’utiliser les sockets ou bien les redirection de ports ? En mettant à part cet histoire de chrootage.

Le petit OS qui avance dans l’ombre de BeOS commence doucement à s’étoffer. Après les avancés du port du webkit Haiku lance un projet de portage de la JVM ouverte de Sun: OpenJDK.

Je ne suis pas sur qu’Haiku vise à être une grande plateforme de développement (quoique pourquoi pas ;-)), mais quoiqu’il arrive, avoir une machine virtuel java porté pour votre OS est quasi indispensable ! Et contrairement à Adobe qui garde sont FlashPlayer bien fermé, Sun, en ouvrant la JVM permet à des équipes divers de la porter sur les OS passé, présent et futur.

Pour ceux qui serais interessé, je vous laisse lire la news officiel de la création de l’équipe Haiku-OpenJDK pour en savoir plus.

Un projet bien interessant, je vais m’y interesser de prêt… Peut-être même plus vu mon profil :)

Pour certain c’est une évidence, mais un vieux mail sur la liste de diffusion de ruby_core ma donné envie de me pencher sur la question.

Venant du monde Java (enfin je n’en suis pas encore sorti), je suis un habitué du:

MacLasse monObjet = MacLasse.new();

pour Ruby ça devient:

mon_objet = Mac_lasse.new

Bon à part le typage dur de java versus le typage dynamique de ruby, pas de gros changement sur l’interprétation de la façon d’instancier un objet entre ces deux langages.

Par contre c’est sur la classe elle même que ça change pas mal.

En java MacLasse ressemble à ça:

public class MacLasse {
  public MacLasse(){
    // code a executer lors de l'instanciation de l'objet
  }
}

et en ruby on se retrouve avec ça:

class Mac_lasse
  def initialize
    // code a executer lors de l'instanciation de l'objet
  end
end

Cette methode en java s’appel un constructeur (ça c’est pour ceux du fond qui suivent pas hein ! ). On l’obtient en définissant une methode portant le même nom que la classe.

Pour ruby, peut importe le nom de la classe, on utilise une methode initialize.

Alors initialize est-elle une methode de type constructeur ?

Non. et en Java non plus finalement. Ces deux methode ne construisent pas l’instance, elle l’initialise. Elles permettent de préparer l’instance avant de la rendre. En java comme en Ruby, on peut très bien ce passer de ces methodes.

Maintenant on va s’éloigner de Java…

En Ruby on pourrais définir une methode new en lieu et place d’@initialize@. Non mais qu’est-ce que je raconte, heureusement y’en a au premier rang qui suivent. Merci.

Je reprend. En ruby on peut surcharger la methode new (Object#new) en plus de la methode initialize. Le seul hic, c’est qu’il faut faire attention. Cette methode new est censé créer l’instance de la class. Il faut donc penser à renvoyer la bonne instance en fin de methode (new pour les voisins du radiateur).

Voyons plutôt un petit bout de code:

class Test_initialize
    def initialize
        "test_initialiaze"
    end
end

class Test_new
    def self.new(*args)
        "test_new"
    end
end

class Test_new_2
    def self.new(*args)
        "test_new_2"
        Object.new
    end
end

test = Test_initialize.new
puts test.class   # Test_initialize

test = Test_new.new("args")
puts test.class   # String

test = Test_new_2.new("args")
puts test.class   # Object

On le voit assez bien je pense: Surcharger new ne doit pas se faire à la légère. Utilisé initialize pour initialiser l’instance semble bien plus logique.

Là dessus Ruby montre bien un de ces principe de base qui veux que le langage soit simple et logique. Contrairement a Java ou l’on parle de constructeur en lieu et place de methode d’initialisation.

C’est de la sémantique c’est sur, mais le principe est là. J’aime ruby et j’aime bien java quand même :-)