Articles : Une licence plus permissive pour Java
Posté par Alexandre (page perso, ). Modéré le 17 mai 2006.
Cette nouvelle licence, nommée « Distro Licence for Java » (DLJ), permet aux distributions de proposer des paquets (.deb, .rpm, etc..) contenant les JDK et JRE, ce qui posait problèmes avec la licence précédente (« Binary Code License » - BCL).
En particulier, la DLJ permet :
- d'utiliser le JDK sur n'importe quel OS pour créer, développer, tester et utiliser des programmes Java, comme auparavant,
- de distribuer le JDK sur tout type de média et le pré-installer dans des distributions,
- de distribuer le JDK directement ou indirectement à travers des distributeurs, revendeurs et en OEM.
À cette annonce, de nombreuses communautés se sont montrées enthousiastes et ont déjà commencé la création de paquets, notamment pour Debian, Ubuntu et Gentoo pour GNU/Linux et BeleniX, NexentaOS et Schillix pour OpenSolaris.
Notons qu'il ne s'agit absolument pas d'une licence libre puisqu'elle ne garantit que le droit de redistribution verbatim du JDK. De plus, elle ajoute des contraintes à cette redistribution (la compatibilité totale doit être assurée par le distributeur pour respecter le principe du "write once, run everywhere"). Cette annonce ne met donc pas fin aux projets libres gravitant autour de l'environnement Java, tels que Gcj, GNU Classpath et les "runtimes" tels que CACAO, JamVM, Jikes RVM, Kaffe et SableVM.
NdM: à noter également que Jonathan Schwartz, nouveau CEO de Sun Microsystems, a également déclaré : « La question n'est pas si nous allons rendre Java open source, mais comment ». Sun ne précise pas de date et ne fait pas de promesse ferme, mais il lance une consultation auprès des développeurs sur « comment open-sourcer Java » à travers le Java Community Process.
NdM 2 : merci à fredx pour avoir proposé la nouvelle.
![[en]](../images/en.png)
Site officiel Jdk-distros (180 hits)-
La licence DLJ (81 hits)
-
La FAQ DLJ (59 hits)
-
GNU Classpath (63 hits)
-
Le projet GCJ (66 hits)
-
Le JDK open source ? (102 hits)
> Lire la dépêche (54 commentaires, moyenne: 2,5).
Vous avez demandé le commentaire #713815.
Run by 
Cette page a été générée par Templeet en 0.0912s (dont 0.0093 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Plop
Je rajoute ce lien qui donne (à mon avis) une bonne idée de la vision du projet JDK Distros de l'intérieur : http://weblogs.java.net/blog/robogeek/archive/2006/05/distri(...)
Pour éviter les trolls comme sur Slashdot, on peut dores et déjà dire que distribuer le JDK et JRE de Sun par ce biais n'empêche absolument pas de distribuer les autres implémentations libres.
La DLJ interdit par contre de faire et de distribuer un produit 'batard' mélangeant l'implémentation de Sun et une autre : Sun se pose encore la question de savoir comment libérer Java sans permettre à des concurrents "hostiles" (au hasard IBM ou Microsoft) de se baser dessus pour le concurrencer.
[^]Re: Plop
Si les implémentations concurrentes commencent à ne plus être compatibles entre elles, on peut les comprendre, ça mettrait sérieusement à mal le principe fondamental de Java. Je dois donc bien dire que cela ne me dérange pas plus que ça que Sun prenne son temps en la matière.
[^]Re: Plop
la belle affaire, quand on regarde le bazar apporté par les changements de versions de Java SE par Sun lui même...
Windows has no users. It has hostages.
[^]Re: Plop
Ce n'est pas si évident que cela.
Tout d'abord le fait qu'il existe plusieurs implémentations de machine virtuelle ne remet pas nécessairement en cause le principe "write once, run anywhere".
Je m'explique en prenant un exemple : J2EE. Il n' y a pas d'implémentation par Sun de serveur J2EE, juste une spécification. Les produits qui implémentent cette spécification peuvent être certifiés par Sun ce qui garanti qu'une application J2EE développée peut être déployée (simplement) sur n'importe quel serveur certifié.
Secondement le fait d'ouvrir le code souce, permettra certainement d'augmenter la qualité du code, et donc l'efficience de la machine virtuelle (Sans vouloir remettre en cause les qualités des developpeurs de Sun) Là encore un exemple (mais je ne retrouve plus la source :(, si quelqu'un sait ). IBM a commencé à s'interesser fortement à l'open-source, lorsque pour aider au developpement de leur machine virtuelle java, ils ont décidé de mettre à disposition leur code source, et de demander à la communité d'apporter des améliorations. En 1 week-end les modifications modifiaient tellement le coeur du programme, que les ingénieurs de chez IBM ont du se pencher un certain temps sur le code pour comprendre l'ensemble des modifications.
[+] [^]Re: Plop
Le principe "write once, run anywhere", il n'y a bien que Sun qui y croit parce que ceux qui font du Java tournant sur plusieurs systèmes savent quel merdier monstrueux il faut faire pour que ça marche vraiment...
[^]Re: Plop
Je m'insurge contre ce genre de propos :)
On ne fait pas de swing mais pour tout le reste (dev web, xml, webservices, serveur applications....) on développé sous linux et c'est aussi déployé sous Windows et on a jamais eu AUCUN problème.
[^]Re: Plop
Je me souviens d'un bete application bateau en java mais écrite visiblement par des gens qui ne connaissait que windows. Elle ne marchait pas sous linux parce que... elle cherchait un fichier avec le chemin en \ et pas en /. C'est idiot non.
Donc à mon avis, il est aussi facile en java de faire une application qui marche partout que dans n'importe quel langage. Donc il n'y a pas à s'embêter avec des histoires de compatibilité.
[^]Re: Plop
Je me souviens d'un bete application bateau en java mais écrite visiblement par des gens qui ne connaissait que windows. Elle ne marchait pas sous linux parce que... elle cherchait un fichier avec le chemin en \ et pas en /. C'est idiot non.
C'est prévu:
http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#se(...)
mais même avec le langage le mieux conçu pour être indépendant de la plateforme, si tu ne veux pas l'être tu y arrivera toujours.
[^]Re: Plop
Dans le même genre, il y a encore plus con. Je me souviens, lors du test sous Linux d'une application développée sous MS-Windows, d'avoir eu un problème avec un fichier de configuration... dont le nom figurait tout en minuscules dans mon code et, sur le système de fichiers, avait sa première lettre en majuscule. Evidemment ça ne posait aucun problème sous MS-Windows, mais ça générait une erreur sous Linux.
this != '|' ;
[+] [^]Re: Plop
tiens, si quelqu'un peut m'expliquer pourquoi ces foutus FS sous linux sont case sensitive?
Ca m'a pourrit la vie aussi au boulot, et apres un test rapide, on ne peut pas creer 2 fichiers avec le meme nom dans des casses differentes (ce qui serait de toutes facons une connerie sans nom qu'il faut interdire a l'utilisateur).
Sinon, pour l'histoire des \ a la place des /, par experience, ca ne gene pas le constructeur de File qui s'en tamponne a allegrement et retrouve ses petits sans problemes.
Bon, c'est sur que si tu lui donnes un c:\\Program Files et que tu lance sous linux, il va tirer la gueule...
[^]Re: Plop
bon ok, j'ai parle trop vite :
j'ai reussi a creer deux fichiers avec des casses differentes (je mantiens que c'est une connerie sans nom ce truc).
et effectivement la classe file se vautre avec un \\ a la place du / (dans l'autre sens ca marche bien, ie / a la place de \\ sous windows).
Excusez le derange.
/me inconditionnel de File.pathSeparator et surtout des classes static utilitaires pour manipuler les paths
[^]Re: Plop
Tien, si quelqu'un peut m'expliquer pourquoi ces foutus FS à la windows s'emmerdent à faire une conversion sur chaque nom de fichier pour faire une comparaison case-insensitive alors que ce serait plus facile de comparer caractère par caractère.
En plus il y a plein de caractères qu'ils n'acceptent pas dans les nom de fichier (bon, OK, pour les caractères de contrôle c'est judicieux).
[^]Re: Plop
Sans doute pour des raisons historiques de compatibilité avec Unix (tout comme pour NTFS sous MS Windows et HFSX sous Mac OS X) et parce que quand Unix a été créé, c'était plus simple de faire comme ça.
[^]Re: Plop
Je ne sais pas comment vous développez, mais je n'ai jamais eu de problèmes pour faire des applis portables.
La compilation d'un .jar sous windows et son déploiement sur un Unix quelconque a toujours réussi.
[^]Re: Plop
Moi y a pas trop longtemps, ma ptite amie qui est en médecine viens avec un cd qu'elle à «reçu» (fallais le payer quand même) à la fac et me demande si elle peu voir ça sur mon laptop. Donc bien sur, première réaction, est ce que ce truc va marcher sur ma debian? Donc je monte le cd, je regarde un peu, et la je vois des archives jar! Génial me dis-je, du java! Donc je lance l'appli, ouais, ça marche et... ha bein non, tiens un message d'erreur! Ha oui il trouve pas le fichier "images\trucmuch.jpg"...
Et oui, un jolie chemin avec un bon gros "\" bien gras. Bien entendu, l'image était le principale intéret de l'appli (photo de coupes de cellules avec possibilité de "zoomer" [chargement d'une autre image] sur certaines zones). Bon voyant que ma copine s'impatienter à me voir trafiquer tout ça, j'ai rebooté sous win... Quand même c'est con, à un chemin de fichier prêt c'était bon, je maudit le gars qui a pondu cette appli.
D'ailleurs détail amusant, bien que les photos étaient accessible directement au lancement de l'appli, pour avoir la description de se qui était visible sur l'image (le plus interessant donc), il fallais taper un mot de passe! (fourni lors de l'achat)
Franchement trop con XD
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plop
Oui... ça arrive, certaisn font des bétises, j'en ai meme vu faire un exec de la commande env pour récupérer des infos systèmes... faut pas pousser non plus :)
Pour le slash, c un peu pareil... il faut utiliser File.separator
[^]Re: Plop
En même temps, le problème du "\" ne vient pas de Java mais des codeurs incompétents du soft en question. Les chemins vers les fichiers dans Java sont transparents par rapport au système sous-jacent; après évidemment, rien n'empêche un développeur un peu porc de mettre ses chemins en dur... Mais c'est porc.
Debian GNU/Linux unstable user
Kernel panic: <EOF> from device: /dev/brain0
[^]Re: Plop
Euh... normalement les objets utilisés pour accéder aux fichiers en java acceptent '/' et '\' comme séparateur de fichier. En tout cas, je n'ai jamais vu ce problème, et pourtant je mets systématiquement des '/' dans mon code et au boulot je suis sous windows :-(
En revanche, le problème peut venir, soit d'un chemin absolu qui commence par "D:\", soit d'une erreur minuscule/majuscule. Le problème de casse sur les noms de fichiers est le problème majeur que l'on rencontre lorsque nos applications au boulot sont déployées sur des *NIX. Dans l'autre sens, quand je code chez moi sous linux, il faut que je fasse attention de ne pas avoir deux fichiers qui ne diffèrent que par la casse du nom... sinon ça ne passe pas sous windows.
[^]Re: Plop
C'est parce que dans une uri, même sous Windows, le séparateur officiel est le /.
[^]Re: Plop
Il me semble que c'était pour jikes, le compilateur d'IBM écrit en C++. Je n'ai pas retrouvé la source, mais je sais que je l'ai lu il n'y a pas longtemps...[^]Re: Plop
Desolé de te contredire, mais il y a bien une implémentation de J2EE par Sun: Sun Java System Application Server (ou JSAS pour les intimes) [1] qui maintenant est même distribué en Open Source (CDDL) sous le nom du projet GlassFish [2].
Wikipedia en francais ecrit ceci [3]:
Je confirme avoir lu la même chose que toi sur la libération du code source de Jikes par IBM, et les modifications intenses que la communauté leur a apporté par la suite.
[1] http://en.wikipedia.org/wiki/Sun_Java_System_Application_Ser(...)
[2] http://en.wikipedia.org/wiki/Glassfish_Application_Server
[3] http://fr.wikipedia.org/wiki/Java_et_logiciel_libre
[^]Re: Plop
Ce qu'il veut dire, c'est que J2EE est une norme et pas un produit fini comme peut l'être PHP. PHP, c'est PHP, un point c'est tout, il peut ya voir des forks mais à vos risques et périls.
J2EE est une norme, donc, il y a des implémentations, (JBoss, JOnAS, Websphere, weblogic...) et du moment que la norme est respectée, peu importe l'lmplémentation choisie.