Trois ans après l'annonce initiale, IronRuby est fier d'annoncer sa version 1.0. Microsoft propose ainsi une implémentation alternative de Ruby qui tourne au-dessus de .NET. La version 1.0 d'IronRuby est compatible avec Ruby 1.8.6 (pas complètement : le langage est très bien respecté, mais pas quelques parties de la bibliothèque standard). Il permet notamment de faire tourner Ruby on Rails 2.3.5.
La prochaine étape est de s'attaquer à la compatibilité de Ruby 1.9 et de permettre de faire fonctionner Rails 3, comme annoncé dans l'interview de RubyInside.
Le futur de Java
Oracle a racheté Sun, et on peut se poser la question de savoir quelle direction Oracle souhaite-il donner à Sun. Le départ de James Gosling laisse à penser que Java n'est pas un enjeu prioritaire pour Oracle, mais en l'absence de communication officielle, il est difficile d'en savoir plus. Rappelons que Java 1.7 devrait sortir en septembre, sauf problème majeur.
Le compte github de twitter
Twitter a publié sur son compte github deux projets intéressants (tous les deux sous licence Apache 2.0) :
- Gizzard est un framework pour faire de la répartition de données (sharding) entre plusieurs stockages. Écrit en scala, ce framework sert à développer des middlewares qui se placent entre vos applications et les bases de données pour assurer la distribution des données et garantir une certaine tolérance aux erreurs.
- Flockdb est une base de données de type graphes. Twitter s'en sert pour stocker son graphe social (13 milliards d'arcs tout de même) et est en train d'en faire un projet libre à part entière. Un client Ruby est disponible pour communiquer avec la base de données.
SpringSource, une filiale de VMWare, a racheté Rabbit Technologies Ltd., la société derrière RabbitMQ. RabbitMQ est une solution complète et fiable d'échange de messages entre systèmes hétérogènes, sous licence Mozilla. Elle implémente le standard AMQP (standard décrié par ses créateurs).
Aller plus loin
- Annonce de la sortie d'IronRuby 1.0 (4 clics)
- James Gosling commente sa démission d'Oracle (3 clics)
- Gizzard (2 clics)
- Flockdb (9 clics)
- Le communiqué de presse de SpringSource (3 clics)
- Le communiqué de presse de RabbitMQ (2 clics)
# Petite erreur
Posté par mgoeminne (site web personnel) . Évalué à 2.
Sinon, ça aurait été super d'avoir un peu d'information sur les nouveautés de Java qui semblent assez conséquentes, avec (entre autre) la possibilité de surcharger les opérateurs (enfin!) et un nouveau garbage collector qui sera capable de faire des balayages "légers", ce qui permet de libérer souvent de la mémoire sans avoir recours à un balayage "lourd", d'où un gain de performance.
[^] # Re: Petite erreur
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Oui, mais je ne connais pas assez bien Java pour ça. S'il y a un volontaire, qu'il n'hésite pas à nous proposer une dépêche.
[^] # Re: Petite erreur
Posté par ckyl . Évalué à 7.
J'ai pas suivit les discussion ces trois derniers mois et la liste n'est pas encore finale. Donc y'a peut être des erreurs. Pour faire très vite:
On commence par le côté bibliothèque standard
- NIO2 (new new I/O): Ca continue le travail et ca corrige les défauts de conceptions des NIO. Notamment une nouvelle interface pour l'accès au système de fichier et la possibilité de faire des opérations asynchrones sur des sockets et des descripteurs de fichiers. Et peut être qu'on va enfin avoir les sorties de processus forké en selectable channel (oui actuellement il faut 3 threads par processus forké...)
- Nouvelle API Date / Time. L'ancienne était très casse gueule à utiliser (surtout de manière thread safe) et ajout de nouvelles fonctions (intervalles etc.)
- JSR166y: revision de la l'API concurrency. On ajoute un module pour le fork & join et pas mal de classe encore et toujours plus utiles. La JSR166 y'a que du bon dedans mangez en
- XQJ: Une api XQuery pour java (XML). Pas joué avec donc pas d'avis
Après au niveau langage:
- Support des fermetures. Y'a eu tellement de discussions que j'ai meme pas cherché à suivre...
- Nettoyage automatique des ressources à la sortie d'un bloc. On déclare en début de bloc les ressources que l'on utilise et quand on sort du bloc les méthodes de nettoyage sont automagiquement appelées. Le but est d'éviter le code relou de nettoyage dans les finally et d'éviter les leaks
- Extension des annotations pour pouvoir les placer un peu plus partout. Un des buts est de pouvoir placer des annotations pour aider les analyseurs statique (indiquer qu'un champ peut être nul ou pas par exemple)
- Inférence de type (ami du CAML pas la peine d'hurler :p ) plus besoin de doubler la déclaration des generics lors d'un new. Map<List, Integer> map = new Map<>(). Merci pour nos petits doigts !
- Possibilité de faire des switch/case sur des string
Et enfin au niveau de la VM (Open JDK):
- Nouveau garbage collector G1 qui envoit du bois. Fini les stop the world & co. Il peut travailler par région et donc tourne en un temps prévisible. Pas mal configurable. C'est du tout bon mangez en (et regardez comment ca marche)
- Ajout d'invokedynamic à la JVM. Le support des langages dynamiques va être beaucoup plus aisé.
- Modularisation du JRE/JDK en petit paquets.
J'ai pu oublier des choses, et certaines choses viendront certainement s'ajouter d'ici la release. Donc non pas de surcharge d'opérateur (et ca n'a jamais été imaginé, pas dans l'esprit de Java et impossible que ca soit backward compatible). On peut noter qu'un des plus grand absent de Java 7 sont les superpackage (équivalent d'OSGi). Et aussi que le null safe handling (invocation d'une méthode uniquement si l'objet n'est pas nul) ne semble pas avoir fait son chemin. De même le multicatch à l'air mort (exécution d'une même action pour différent type d'exceptions), et ca ca craint !
Pas de révolution donc, quelques APIs retravaillées, et une VM qui s'affine toujours plus.
[^] # Re: Petite erreur
Posté par hsyl20 (site web personnel) . Évalué à 5.
côté bibliothèque standard [...] au niveau de la VM (Open JDK) [...]
Scala a accès à la bibliothèque standard Java et utilise la JVM donc bonne nouvelle.
- Support des fermetures. Y'a eu tellement de discussions que j'ai meme pas cherché à suivre...
Scala les supporte. Exemple :
val maListe = List(1,8,34,74,785,16)
val uneValeur = 18
val maClosure = (a:Int) => a + uneValeur // <-- La closure est ici
val maListePlusUneValeur = maListe.map(maClosure)
On peut raccourcir :
val maListe = List(1,5,4,78,8)
val uneValeur = 17
val maListePlusUneValeur = maListe.map(_ + uneValeur)
- Nettoyage automatique des ressources à la sortie d'un bloc. On déclare en début de bloc les ressources que l'on utilise et quand on sort du bloc les méthodes de nettoyage sont automagiquement appelées. Le but est d'éviter le code relou de nettoyage dans les finally et d'éviter les leaks
La question a encore été posée aujourd'hui sur #scala :-) Ça s'implémente facilement sans modifier le langage.
http://stackoverflow.com/questions/2395984/scala-using-keywo(...)
- Extension des annotations pour pouvoir les placer un peu plus partout. Un des buts est de pouvoir placer des annotations pour aider les analyseurs statique (indiquer qu'un champ peut être nul ou pas par exemple)
En Scala il est préconisé de n'utiliser "null" que pour la compatibilité avec des classes écrites en Java. Sinon on utilise le type algébrique Option pour remplacer les types "nullables".
Pour les annotations, à priori ça doit être équivalent à celles de Java au moins.
- Inférence de type (ami du CAML pas la peine d'hurler :p ) plus besoin de doubler la déclaration des generics lors d'un new. Map<List, Integer> map = new Map<>(). Merci pour nos petits doigts !
Scala utilise massivement l'inférence de type (et surtout avec des types paramétrés qui peuvent être bien plus compliqués qu'en Java). Ton exemple donnerait :
val map = new Map[List, Integer]() (enfin il faudrait paramétrer List aussi, mais bon c'est un exemple)
- Possibilité de faire des switch/case sur des string
Scala supporte le pattern-matching. Par exemple avec le type Option cité plus haut :
val a:Option[Integer] = Some(5)
...
a match {
case Some(x) => //code qui peut utiliser "x" qui vaut 5 ici
case None => // cas où "a" serait "null" (enfin l'équivalent avec Option...)
}
Avec les strings ça fonctionne pareil :
str match {
case "brol" => ...
case "troll" => ...
}
Pour les exceptions, on utilise du pattern-matching aussi (comme en Java sauf qu'ils ne le disent pas explicitement). Du coup on peut faire du "multicatch" :
try {
...
} catch {
case e:SQLException => println("Database error") //Comme en Java
case e:MalformedURLException
| case e2:URLenBois => println("Bad URL") //multicatch
case e => { //catch par défaut
println("Some other exception type:")
e.printStackTrace()
}
}
Pour la surcharge des opérateurs, en fait le concept d'opérateur n'existe pas en Scala, ce sont des méthodes de classe :
5 + 7 est équivalent à 5.+(7)
Du coup on peut définir les opérateurs qu'on veut (à quelques limitations près). Exemple :
monActeur !! monMessage
(envoie un message à l'acteur avec une syntaxe qui reprend celle d'Erlang).
Ça permet de faire des choses concises comme :
(0 /: maListe)(_ + _)
qui est plus lisible (une fois habitué...) que : maListe.foldLeft(0)((a:Int,b:Int) => a +b)
Voir aussi les parsers du type :
val parser = "void" ~ ident ~ "(" ~ repSep(param, ",") ~ ")" ~ ";" ^^^ {
println("Déclaration de procédure parsée !!!")
}
Bref, Scala c'est bon, mangez en. Et c'est déjà dispo. En plus, la prochaine release (2.8) apportera les paramètres nommés, les valeurs par défaut, etc. Et la beta est assez stable :-) http://www.scala-lang.org/node/1564
http://www.codecommit.com/blog/scala/roundup-scala-for-java-(...)
[^] # Re: Petite erreur
Posté par ckyl . Évalué à 4.
Toutefois, comparer bêtement point à point Java et scala, serait une erreur. C'est comparer des pommes avec des oranges; et ne pas avoir compris que ces deux langages offrent des choses fort différentes même si il repose sur le même socle technique.
Le langage Java est vieux, pas sexy, s'enlise de release en release par ce qu'il y a un souhait très fort de ne pas briser la rétrocompatibilité. Les choix initiaux resterons et à chaque release il devient de plus en plus difficile de faire avancer les choses en dehors de l'API et de la VM. Dans l'état actuel des choses, il ne faut pas avoir l'espoir de voir arriver de grosses nouveautés dans le langage. Java est un bon choix pour les projets importants, qui ont besoin de stabilité, de pérennité, d'outillage et de compétences. C'est un langage de grosse entreprise ou de fournisseur de lib/framework.
Scala est neuf, part de zéro, se permet de casser la compatibilité quand nécessaire. L'outillage reste en développement, avec des plâtre à essuyer et les compétences sont plus rares. Ca peut être un très bon choix pour des bases de code plus modeste, qui peuvent évoluer plus facilement, dans des environnements plus ouvert, ou les clients mettent moins de pression sur les technos. Pour un produit interne, raisonnable et dynamique c'est jouable.
Bref le publique des deux langages est différent. Le langage Java s'enlise, mais la plateforme est fleurissante avec des nouveaux langages et s'ouvre donc à de nouveaux utilisateurs. Mais en général ce ne sont pas la souplesse d'un langage ou tes préférences personnelles qui te feront choisir un langage. Tes contraintes vont déjà fortement élaguer les différentes possibilités.
PS pour dredi: Cette remarque ne vise pas à Scala, mais je préfère avoir un langage de merde mais des documentations complètes, de bons outils et de bonnes bibliothèques; qu'un langage top, mais qui pète la compatibilité tout les ans, ou la doc est faible, ou le compilateur est encore en dev, sans bon debugger/profiler, et ou 4 libs se battent en duel. Le plaisir de développer ce n'est pas seulement le langage en lui même ;)
[^] # Re: Petite erreur
Posté par hsyl20 (site web personnel) . Évalué à 2.
comparer bêtement point à point Java et scala, serait une erreur
Je ne pense pas. Les deux langages offrent effectivement des choses fort différentes mais avec l'un des deux il est possible de faire exactement ce que fait l'autre (avec le même style, les mêmes concepts, les mêmes bibliothèques) sans être cependant limité à ça. Donc on peut tout à fait les comparer.
Java est un bon choix pour les projets importants, qui ont besoin de stabilité, de pérennité, d'outillage et de compétences. C'est un langage de grosse entreprise ou de fournisseur de lib/framework.
Les développeurs de Scala essaient au maximum de conserver la stabilité de l'API et de l'ABI (au niveau du bytecode) avec quelques exceptions inévitables lors de certains changements majeurs. Pour la pérennité, Scala est sous license type BSD. Pour l'outillage, ça se développe (plugins pour Maven, Eclipse, NetBeans et autres IDE) mais ça n'est bien sûr pas au niveau de Java pour l'instant. À noter que le plugin Maven permet de mixer du code Java et Scala facilement. Pour les compétences, ça se développe petit à petit ;-)
Les libs/frameworks écrits en Scala sont utilisables à partir d'application Java, Clojure, Groovy ou autres...
Je ne sais pas ce qui caractérise un langage de grosse entreprise.
Mais en général ce ne sont pas la souplesse d'un langage ou tes préférences personnelles qui te feront choisir un langage. Tes contraintes vont déjà fortement élaguer les différentes possibilités.
Justement mes contraintes sont d'écrire un compilateur pour un DSL (Domain-Specific Language). Donc les options sont soit de le faire à l'ancienne (C/C++, Yacc, Bison, etc.) et d'y passer 10 ans, soit d'utiliser les facilités de certains autres _langages_ (parser combinator, embedded DSL...). J'ai vite choisi ! Mais effectivement je n'ai pas de contrainte provenant de clients.
[^] # Re: Petite erreur
Posté par Vincent . Évalué à 1.
[http://blogs.amd.com/developer/2010/04/12/better-uptime-for-(...)]
# le futur de MySQL
Posté par vida18 . Évalué à 1.
# Java
Posté par Dring . Évalué à 3.
Je vois pas pourquoi cela "laisse à penser" un truc pareil. Les outils qui accompagnent un Oracle sont tous en Java. Java fait clairement partie des éléments qui intéressaient Oracle.
Il va falloir attendre encore un peu plutôt que de faire des hypothèses aussi hasadeuses.
[^] # Re: Java
Posté par claudex . Évalué à 2.
Je peux me tromper, mais il n'y a rien qui a besoin de performance dans ces outils, c'est-à-dire qu'un statut quo ne les dérangeraient pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Java
Posté par GeneralZod . Évalué à 3.
Si Oracle était une boite très con, peut-être mais tu oublies que face à Java/Oracle/MySQL tu as .Net/SQL Server qui commence à les titiller donc autant on peut s'inquiéter de l'avenir de JavaFX, autant Java reste critique pour Oracle.
[^] # Re: Java
Posté par daemontux . Évalué à 3.
Larry Ellison avait je crois déclaré qu'il aimerait refaire l'UI d'OpenOffice en JavaFX, donc ils ne vont pas le laisser tomber. Le libérer comme c'était prévu par contre j'ai des doutes.
Sinon pour Java c'était une de leurs principales raisons de racheter Sun donc ils ne l'abandonneront pas, mais la philosophie d'Oracle est très différente de celle de Sun (en gros c'est des cons), ce qui explique peut-être le départ de James Gosling. La question est de savoir s'ils maintiendront un peu d'ouverture dans le processus de développement de Java et s'ils continueront à tout mettre sous licence libre (ils avaient déjà tenté de fournir un garbage collector uniquement aux utilisateurs ayant souscrit du support, cf http://tech.slashdot.org/story/09/05/29/1711203/Java-Gets-Ne(...)
[^] # Re: Java
Posté par fredix . Évalué à 3.
[^] # Re: Java
Posté par Buf (Mastodon) . Évalué à 4.
Et il ne faut pas oublier les autres produits développés ou rachetés par Oracle ces dernières années, on trouve entre autres parmi eux Weblogic (un des serveurs d'application JEE les plus utilisés), TopLink (mapping objet-relationnel)
Bref, Java est clairement une pièce centrale dans le business d'Oracle, dont les performances sont critiques.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.