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.

[_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é.

[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]

Ç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 ?

Swing avait sans doute besoin d'une remise à neuf mais visiblement, SUN était trop occupé à pondre toutes sortes de "bullshit specification" pour J2EE. Maintenant je suppose qu'il a été considéré comme mort avec l'annonce de javaFX, qui est encore à ce jour, sauf erreur de ma part, inutilisable.

Maintenant on dit qu'Oracle pourrait avec la version 2.0, faire passer javafx du rang de plaisanterie marketing de mauvais goût à celui de Swing2. Actuellement, du côté de jDesktop et Swinglabs sur java.net, franchement ça fait peur, (lenteur, mauvais certificats, liens morts dans tous les sens) là Oracle s'est vautré.

[Philippe Bastiani]

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 ?

Swinglabs n'est pas un projet Oracle ni même un projet SUN depuis 3-4 ans !
Comment veux-tu que politiquement et techniquement ce projet qui est maintenant libre puisse être intégré dans Java ?

Swinglabs était une belle idée et peut-être même une utopie pour certains alors que Java s'ouvrait sur l'OpenSource: si mes souvenirs sont bons SUN a quitté cette pépinière de projets au profit de JavaFX un projet interne (comme quoi le libre et Java n'ont jamais fait bon ménage)... mais ni en tant qu'intégrateur de solutions communautaires ni en tant que promoteur de solutions internes SUN n'a été capable de monter une solution qui tienne la route...

A la décharge de SUN, le cœur de métier de l'entreprise était centré sur la partie serveur (hard et soft); et, SUN n'avait visiblement pas les moyens de ses ambitions !

[bouye]

Quel est le rapport ? Sun a bien intégré Derby dans le JDK ! Sans parler de toutes les autres contributions d'Apache, du W3C ou même de l'OMG. Ah oui et Netscape aussi, vous savez un truc qui s'appelait l'Internet Foundation Classes AKA... je vous le donne en mille : Swing !

Le projet SwingLabs a été créé, spécialement en OpenSource, JUSTEMENT pour être la pépinière de choses qui seraient intégrées aux runtimes. Et d'ailleurs JUSTEMENT, 2 composants (enfin au moins un, le JXLayer, parce que bon d'ici à Java 8 le statut du JXCalendar peut encore être revu à la baisse) vont ENFIN être intégrés.

Si la license de SwingLabs le permet (c'est du LGLP non ?), il n'y a AUCUN problème pour le mettre dans un JRE/JDK propriétaire (rappel : les sources Java des runtimes sont dispos depuis des lustres bien avant que les gens ne s'entichent à rendre Java "libre").

[Philippe Bastiani]

Quel est le rapport ?

Le rapport c'est que le Swinglabs a été complètement abandonné par SUN depuis près de 4 ans (plus de commiters plus de soutien financier, ...)! Et, que je vois mal Oracle en être un simple partenaire: Oracle cherche des solutions dont ils ont les leaderships... l'histoire récente des projets ouverts (OpenOffice, Hudson, ...) qui tentent de s'affranchir de cette main mise d'Oracle montre bien comment Oracle fonctionne vis-à-vis de la communauté du libre.

On parle ici d'un 'OracleLabs'... qui peut très bien reprendre à son compte des concepts du SwingLabs!

Comment réagirait la communauté si Oracle avait l'intention de prendre le gouvernance des projets SwingLabs ?
Oracle souhaite avant tout travailler et bénéficier du travail de groupes qui soutiennent sa vision de Java...

C'est bien dommage, quels gachis, ... Je te l'accorde ! Mais, Oracle restera Oracle !

Soit dit en passant
Entre SUN qui nous a dit "travaillons ensemble" et qui lance en parallèle un projet interne,
et, Oracle qui dit "aidez nous"
je me dis que la position d'Oracle est un moindre mal si au final il en sort quelque chose pour nous développeurs Java !