Discussion :

[Idelways]

Java : Oracle lance un appel à contribution pour OpenJDK 8
Et prépare un processus de collecte plus simple et plus ouvert



L'essentiel du travail sur JDK 7 étant fait, Oracle lance à présent un appel à contribution pour définir ce que sera, en détail, la version 8 du Kit de Développement du langage Java. Voir des versions ultérieures.

Sur la mailing liste d'OpenJDK, Mark Reinhold, architecte en chef du groupe de travail sur la plate-forme Java, invite l'ensemble de la communauté à définir un processus simple pour collecter, trier, analyser et organiser les priorités sur les propositions de nouvelles fonctionnalités.

Ce nouveau processus devra être, d'après Heinhold, le plus léger possible, offrir des mécanismes simples et ouverts à tous les intervenants, avec un processus de « prise de décision transparent ».

En attendant qu'un système avec base de données soit réalisé par la communauté, les contributions peuvent être déposées dans le dépôt Mercurial d'OpenJDK au format TEXT structuré dans le pseudolangage Markdown.

Oracle, qui investit massivement dans l'avenir du langage Java, a été récemment très critiqué suite à la publication des premières versions d'OpenJDK 7 sous une licence qualifiée par certains développeurs d'inadmissible pour un projet open source.

Reste à savoir si le nouveau processus de contribution arrivera à apaiser les esprits et à renforcer l'unanimité que l'entreprise semble faire au demeurant autour de ses efforts pour faire progresser Java.


Source : Mailing List de l'OpenJDK

Et vous ?

Quelle(s) propositions feriez-vous pour OpenJDK 8 ?

[eclesia]

Quelle(s) propositions feriez-vous pour OpenJDK 8 ?

Aucune. Java c'est arrété a la version 1.6.
Il n'y a pas de jvm certifié au dela de cette version qui soit sous controle de la communauté ou d'une fondation open-source.

Je ne vois pas de raison d'aider au dévelopement de OracleJDK-Express.

[adiGuba]

@eclesia : c'était déjà le cas avant...


@_skip : j'ai des doutes sur les property. Les propositions du projet Coin qui allaient dans ce sens était soit basique (et donc avec peu d'intérêt) soit totalement incompatible avec l'existant (et donc peu utilisable).

Par contre le projet Lambda avance bien et devrait apporter pas mal de chose avec le trio "Expressions Lambda / Method references / Defender methods"


a++

[Traroth2]

Si vous avez envie de travailler gratuitement pour qu'Oracle (et exclusivement Oracle ! Personne d'autre ne pourra en faire quoi que ce soit de profitable, puisqu'on est obligé de céder la propriété intellectuelle de son code à Oracle quand on contribue à Java. Et pas la peine non plus d'attendre la moindre réciprocité de leur part...) puisse gagner plein d'argent avec vos idées, surtout n'hésitez pas !

[_skip]

@_skip : j'ai des doutes sur les property. Les propositions du projet Coin qui allaient dans ce sens était soit basique (et donc avec peu d'intérêt) soit totalement incompatible avec l'existant (et donc peu utilisable).

Parce que les propositions avec l'opérateur " ->" étaient nulles, pour moi un sucre syntaxique suffirait. Même si derrière ce sont effectivement des getters/setters qui sont générés et utilisés, au moins tu peux ne documenter qu'une seule fois ta propriété.

[Uther]

j'ai des doutes sur les property. Les propositions du projet Coin qui allaient dans ce sens était soit basique (et donc avec peu d'intérêt) soit totalement incompatible avec l'existant (et donc peu utilisable).

Les proposition de gestion des propriétés que j'avais vues sur le projet Coin n'étaient que de très vagues ébauches pour présenter l'idée. Il y en a eu d'autre aprés?
Je ne pense pas que quelquechose de très avancé soit nécessaire. Qu'est ce que tu vois de manquant dans les propositions que tu as vues sur les propriétés?

[adiGuba]

J'ai vu deux principales propositions :

1. Small property support, qui correspond ni plus ni moins à du sucre syntaxique qui génèrerait implicitement les getters/setters.
   
   En gros i->x serait transformé à la compilation en i.getX().
   
   Simple et compatible (puisqu'au final on utilise toujours les getters/setters), mais qui n'apporterait finalement que peu de chose (pas de "property reference", pas de bindings).
   
2. Lightweight Properties, qui propose une nouvelle syntaxe et une API complète pour gérer les property pour le bindings...
   
   Mais cela sera rendu obsolète par les "method references"...

a++

[bouye]

Déjà perdu trop d’années a servir de beta-testeur pour Sun (sans trop d'effet d'ailleurs vu l'age de certains rapports de bugs soumis qui sont restes sans correctif).

En plus c'est marrant de vouloir mette en place un processus pour collecter des changements de specs... si au final rien ne change.

Ça me rappelle un peu SwingX et autre jdesktop.org, les incubateurs OpenSource pour les développements futurs de Swing... déjà ça n'a pas eut trop le succès escompté même si les projets ont aboutis a des réalisations intéressantes (et fort utiles ma fois).
Mais 7 ans après on a... rien : 1 composant inclus dans Java 7 et 1 second repousse a Java 8... Waaaah trop cool, pourtant une bonne partie du reste du projet me semble déjà fonctionnel ; c'est quoi le problème alors ?

[_skip]

S'il y avait encore de la place pour quelque chose, cela fait des années que j'attends les "property" en java.
Le modèle javabean nous oblige actuellement à écrire trop de code "boilerplate".

Ce serait mon rêve de voir ça en java les prochaines années, même si je sais que ça fait pas l'unanimité.