Java est maintenant disponible sous licence open source.
Le nom du projet: OpenJDK.
Je vous invite à commenter l'annonce dans ce fil.
Il ne sert plus à rien de voter.
Envoyé par christopheJ
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
GPL
LGPL
Apache
CDDL
BSD
Mozilla
EPL
MIT License
Autre license
Pas de préférence
Java ne devrait pas être Open Source
Sous quelle licence Java devrait-il être disponible ?
Java est maintenant disponible sous licence open source.
Le nom du projet: OpenJDK.
Je vous invite à commenter l'annonce dans ce fil.
Il ne sert plus à rien de voter.
moi je pense que Sun devrait s'inspirer de trollteh (avec QT) ou de mysql
double license GPL et enterprise. Comme ca java en GPL et aussi dans un mode plus habituel pour ceux qui sont pret a payer
La license Apache me parait être un bon choix. Elle est suffisamment souple, et a fait ses preuves, aussi bien du coté des developpeurs Open-Source que des commerciaux....
Bonjour
A mon avis, Sun va sortir la JVM sous licence CDDL qu'elle a elle-même crée.
Il me paraît exclu qu'elle opte pour la licence Eclipse (derrière Eclipse, on trouve IBM) ainsi que les autres.
@++
GLDavid
Consultez la FAQ Perl ainsi que mes cours de Perl.
N'oubliez pas les balises codeni le tag
Je ne répond à aucune question technique par MP.
+1
Je suis aussi d'avis que Sun va mettre la JVM sous licence CDDL.
Pourquoi pas GPL ou LGPL, histoire que Stallman ne fasse plus de coup de gueule contre Java.
-"Tout ça me paraît très mal organisé. Je veux déposer une réclamation. Je paye mes impôts, après tout!"
-"JE SUIS LA MORT, PAS LES IMPÔTS! MOI, JE N'ARRIVE QU'UNE FOIS".
Pieds d'argile (1996), Terry Pratchett 1948 - 2015
(trad. Patrick Couton)
Salut,
Pour moi peu importe la licence, mais ce qui est important c'est que le code des classes de l'API standard puissent être utilisé "simplement" dans d'autres projets opensources (le principal défaut des JVM libre étant l'implémentation incomplète des classes de l'API, alors que l'interpréteur de bytecode est pleinement fonctionnel).
Par contre, là où je serais plus attentif c'est sur la manière dont Sun va protéger Java.
Je pense qu'avoir plusieurs JVM est une chose très intérressante, non seulement car on pourrait voir arriver des JVM mieux optimisé pour un type de système particulier, mais également car on pourrait voir arriver de nouveaux principes/idées d'optimisations du tout (la JVM Multi-tâches -et non pas multithread- de Sun se fait encore attendre).
Par contre il ne faut pas qu'elle dénature le langage en ajoutant/modifiant des fonctionnalité non-standard !
Même si ce n'est pas le but des projet opensource, la tentation d'ajouter des packages pour couvrir des besoins spécifiques à un système pourrait être assez dommageables...
a++
PS : Plutôt que d'essayer de deviner le choix que fera Sun, je pense qu'il serait intérressant de donner votre avis personnel sur la licence ainsi que vos craintes/espoirs concernant le passage en Opensource de Java. non ?
Salut,
On peut donc comprendre toute l'inquiétude de Sun.
En tout cas si Sun ne garde pas le contrôle sur Java cela risque bien de devenir un fameux bordel... avec le temps.
Je partage cet avis, il serait effectivement très intéressant d'avoir des JVM dont la différence se ferait principalement sur l'optimisation, ainsi on pourrait choisir la JVM la plus adaptée au besoin.Je pense qu'avoir plusieurs JVM est une chose très intérressante, non seulement car on pourrait voir arriver des JVM mieux optimisé pour un type de système particulier, mais également car on pourrait voir arriver de nouveaux principes/idées d'optimisations du tout (la JVM Multithread de Sun se fait encore attendre
Encore une fois je plussoie, il est, à mon avis, primordial que les différentes JVM restent 100% compatibles (un code exécuté sur l'une doit pouvoir l'être entièrement sur une autre).
Voilà mon avis, mais ne connaissant pas très bien les licenses (et ne pouvant donc pas en déduire celle qui conviendrait le mieux à mes envies), je m'abstientrais pour l'instant de voter.
Je ne répondrai à aucune question technique par MP.
Pensez aux Tutoriels et aux FAQs avant de poster(pour le java il y a aussi JavaSearch), n'oubliez pas non plus la fonction Rechercher.
Enfin, quand une solution a été trouvée à votre problème pensez au tag
Cours Dvp : http://ydisanto.developpez.com
Blog : http://yann-disanto.blogspot.com/
Page perso : http://yann-disanto.fr
+1
+1, le risque de fork qui aboutissent à des VM non-standard reste la plus grande crainte
Une petite info comme ça en passant, Apache travaille dessus (attention: c'est un projet qui est TOUJOURS dans l'incubateur)
http://incubator.apache.org/harmony/
Je ne connait pas toutes les licences open-sources, mais à mon avis aucune n'empèchera la création de fork (bien au contraire) de la JVM avec l'ajout de fonctionnalité non standard. Ce sera à la communauté JAVA de se responsabiliser et de ne pas créer de variante, rien n'empéchera par exemple Apache de fournir une JVM contenant tout les commons-util en standard et optimisé. Et donc on risque de voir de voir un retour de la JVM windows qui intégrera des package spécifique à l'OS par exemple.
Je crains vraiment que l'ouverture du code soit la mort de la portabilité de JAVA. Peur qui a d'ailleurs longtemps frainé SUN.
De plus je vois un risque important sur la gestion des bug possible de la JVM, comment savoir si entre 2 machine l'erreur est du à une erreur de code ou à 2 JVM différentes dont l'une est buggé ?
Edit:
Peut-être faudra-t-il un label du style JDK sun Compatible
Une autre chose que l'ont peut risquer avec des modifications de la JVM, c'est une perte de la portabilitéCe serait vraiment dommage d'en arriver là
Effectivement la perte de la portabilité serait terrible.
Sinon niveau licence laquelle serait la plus à même de "préserver" le capital de Sun tout en faisait "plaisir" (donnant plus de liberté) à la communauté ?
J’ai voté que je n’avais pas de préférence.
Actuellement, le système de licence me convient :
- ma société peut vendre du développement Java pour me payer,
- je peux donner gratuitement ce que je développe en Java avec les sources si je le souhaite,
- Java est présent sur les OS que j’utilise (Windows et Linux),
- je suis libre de satisfaire ma curiosité en lisant les sources du framework,
- J’ai la garantie (moyennant le respect de quelques règles de codage) que mon application s’exécutera sur toutes les JVM d’une version équivalente ou supérieure à celle du JDK que j’utilise et ce quel que soit l’OS.
Un des arguments que j’ai vu en faveur du passage de Java en open source, c’est la possibilité que l’on aura de corriger les bugs existant dans le framework ou soumettre des évolutions. Cet argument n’est pas valable puisque cela est déjà possible : https://jdk6.dev.java.net/collaborate.html
Par contre il deviendra possible de contribuer à la JVM, le compilateur ou encore le Garbage Collector pour en améliorer encore les performances, ce qui peut être un plus.
Enfin une grande peur est celle du fork. C'est-à-dire par exemple que je trouve que le JRE est trop gros, je décide de distribuer un JRE sans Corba, RMI que je n’utilise pas, pour en réduire la taille. Par contre comme j’utilise toujours les Jakarta Commons, je les inclus dans mon JRE. Si tout le monde fait comme moi, on se retrouve alors potentiellement avec autant de JRE que de distributeurs de programmes et plus aucune garantie que nos programmes fonctionneront sur les machines. Là encore il s’agit d’une peur déraisonnée. En effet l’appellation Java est soumise à deux conditions :
http://weblogs.java.net/blog/robogee...itation_a.html
- le passage des tests du TCK, c'est-à-dire l’implémentation complète de la spécification
- un sorte de licence ou accord avec Sun pour l’utilisation de la marque déposée Java.
L’hypothèse d’un JRE allégé n’est alors plus possible. Quand à l’ajout d’APIs dans le JRE, cela n’aura pas d’incidence si vous ne les utilisez pas (tant qu’elles n’entraînent pas de problèmes dans les APIs standards, mais alors les tests du TCK ne passent plus et l’appellation Java n’est plus possible). Et comme vous n’avez pas de garantie que la machine destinataire de votre application possède un JRE modifié avec les bonnes APIs, il vaut mieux les livrer avec votre application….
En résumé, la situation actuelle me convient parfaitement. Donc je n’ai pas de préférence sur la future licence de Java, tant que les cinq points cités au début restent vrais.
Vous pouvez aussi lire l’interview à ce sujet de Vincent Brabant, Java Champion : http://java.developpez.com/interview...urce/vbrabant/
Multi-tâches, pas multi-thread! :-)(la JVM Multithread de Sun se fait encore attendre
Oui en effet
Merci pour la rectification
Salut,
J'ai voté "Pas de préférence".
Je trouve que c'est interessant d'avoir le code de Java en open source afin de pouvoir s'en servir, pour implémenter ses propres classes en Java, sans risque de casser un copyright.
Pour le reste, voir des JVM concurrentes ne me semble pas primordial; Sun est capable de produire des JVM performantes et en constantes évolutions, ainsi que de faire évoluer son langage, sans que d'autres viennent y mettre le nez; Le risque d'incompatibilité, de problèmes de portabilité, et de bugs est à mon avis trop important pour faire confiance à un autre vendeur que Sun à ce niveau là, en tout cas pour ma part.
A+
K
Bonjour,
je ne connais pas assez les licenses pour me faire un avis. Mais concernant le risque de fork, j'ai l'impression que d'autres sociétés s'en sont bien sorties (par exemple Apache). Et il est clair que personnellement je n'installerai que des JVM depuis le site de Sun (si disponible).
Le risque existe bien sûr, tout comme il existe entre deux versions de la JVM de Sun...
De plus, mis à part la JVM de Microsoft, les principales autres JVM (IBM, BEA ou Apple) respectent bien les spécifications de Java et son API. Je ne vois pas pourquoi les JVM OpenSource poseraient plus de problème de ce coté là.
Par contre un test de compatibilité est bien sûr nécessaire (je pense que Sun doit se creuser la tête pour là dessus, et que la réussite de ce "test" permettra peut-être à d'autre VM d'utiliser le nom "Java")...
Enfin l'OpenSource pourrait permettre de faciliter le développement de JVM expérimentales, qui pourraient préfigurer ce qui existera en standard dans 10 ans (les JVM ont déjà énormément évolué depuis 10 ans : on est passé d'un bytecode interprété à une compilation à la volée qui permet un grand nombre d'optimisation).
Le gros problème pour le développement d'une JVM vient plus de la quantité de code de l'API standard ! Même si le projet GNU/Classpath avance vite, il a toujours un train de retard (l'API 1.4 est "presque" totalement supporté). Le fait de pouvoir réutilisé le code de Sun pourrait fortement faciliter la tâche (si la licence le permet
Sun ne peut pas développer à lui tout seul des JVM pour tous les systèmes et tous les types d'architectures matériels (et cela ne serait sûrement pas très rentable pour lui), surtout avec l'essor de Java ME (ne l'oublions pas
Or si l'API est très riche, il y a le risque de voir des VM propriétaire basé sur le langage Java mais qui n'implémente qu'une partie de l'API (pour éviter des coûts de développement trop important)le marché pourrait se retrouver fragmenté...
Avec une API en OpenSource, il devient plus facile de "porter" une JVM sur un matériel spécifique en respectant les spécifications et l'API.
Ainsi la devise "Write once, run anywhere" n'en sera que plus vrai...
a++
Pour ma part, j'ai bien peur qu'on arrivera dans le cas où la fondation eclipse (poussée par IBM) ne pourra résister à créer son propre JDK et JRE, en y intégrant leurs APIs maisons, comme SWT et d'autres trucs du genre.
Et comme Eclipse est un EDI très connu et qu'IBM possède la force markéting nécessaire, j'ai bien peu qu'on arrive à avoir un EDK et un ERE.
Vincent Brabant
Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.
Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager