IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Idelways
12 commentaires

14PARTAGES

0  0 
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 ?
Vous avez lu gratuitement 19 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

12 commentaires
Commenter Signaler un problème
Traroth2
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 23/03/2011 à 14:25
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 !
4  1 
bouye
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 23/03/2011 à 23:33
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 ?
3  0 
_skip
Avatar de _skip
Expert éminent https://www.developpez.com
Le 24/03/2011 à 9:16
Citation Envoyé par bouye Voir le message

Ç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é.
1  0 
eclesia
Avatar de eclesia
Rédacteur https://www.developpez.com
Le 23/03/2011 à 13:03
Citation Envoyé par Idelways Voir le message

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.
2  2 
_skip
Avatar de _skip
Expert éminent https://www.developpez.com
Le 23/03/2011 à 13:04
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é.
0  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 23/03/2011 à 14:10
@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++
0  0 
_skip
Avatar de _skip
Expert éminent https://www.developpez.com
Le 23/03/2011 à 14:42
Citation Envoyé par adiGuba Voir le message

@_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é.
0  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 23/03/2011 à 19:12
Citation Envoyé par adiGuba Voir le message
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?
0  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 23/03/2011 à 20:57
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++
0  0 
Philippe Bastiani
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 24/03/2011 à 9:51
Citation Envoyé par bouye Voir le message
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 !
0  0 
Commenter Signaler un problème