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
pour
contre
indifférent
Pour ou contre Java en open-source ?
Merci de ne répondre que par "pour", "contre" ou "indifférent" : maintenant que le passage de Java en open-source est confirmé.
Ce message n'est pas là pour susciter un débat sur le forum ; ce message est juste un moyen d'avoir un aperçu rapide des opinions dans les 1ers instants !
" Jag blev dömd för fildelning och allt jag fick var en sketen t-shirt. " (tankafritt.nu)
PAS DE REPONSE PAR MESSAGE PRIVE ! Penser au bouton Résolu en bas de la discussion...
Indifférent, car dans les deux positions il y a avatages et inconvénients
La forme actuelle permet de maintenir une grande cohérence au niveau des JVM et donc de ce fait de ne pas avoir à trop se soucier de celle que l'on va utiliser pour le projet. PAr contre il est sur qu'elle "bride" au niveau de l'inventivité des devs qui doivent passer par le community process et respecter des normes particulières pour effectuer des modifications
Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.
Apparament d'après ce que j'ai cru comprendre, Sun chercherais à éviter qu'il ne se produise la même chose qu'avec les distributions Linux, c'est pour cette raison qu'ils réfléchissent encore aux dispositions sur le passage à l'open source bien que celui-ci ait été annoncé.
Sinon moi je suis plutôt pour car ça assurera un support plus important de la communauté et garanti plus la pérénité de Java surtout face à son principal concurrent .NET.
-"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)
Pour !!!
Perso je ne vois pas le fork comme un inconviénient ! Au contraire cela pourrait permettre d'optimiser un peu plus les JVM pour le système cible... et c'est exactement le but de la JVM !!!
Maintenant c'est sûr qu'il faut impérativement conserver des implémentations respectueuses de l'API et du langage, et évité toutes dérives avec des classes non-standard et/ou des "évolutions" du langage spécifique à une JVM...
Je suis à la fois persuadé que Sun va faire tout son possible pour éviter cela (même si j'ignore comment, peut-être en protegeant les appellations java et jvm), et que de toutes manières les divers fork n'iront pas de ce coté là...
a++
indifférent
j'ai du mal à me construire un avis, je pense aux avantages que cela pourrait apporter mais j'ai également peur d'une diversification trop importante...
Histoire de relancer : perso je suis "contre"...
- pas pour l'arrivée probable de différentes versions optimisées de JVM en fonction de chaque plateforme (d'accord avec <<adiGuba>> sur ce coup) ;
- mais pour le risque de divergences sur des implémentations ne respectant pas la Javadoc (voire le comportement non documenté) de l'API initiale 'made in' Sun, car pour moi la seule raison valable de changement du code est son amélioration en qualité (mais pas en quantité comme des rajouts de classes/méthodes qui si elles sont positives seront de toute façon intégrées dans la future version du JDK officiel et cela plutôt tôt que tard d'ailleurs).
En plus à ma connaissance d'un point de vue légal l'UTILISATION d'un langage non-OpenSource (même sur une plateforme OpenSource) ne pose aucun problème, le seul possible étant la MODIFICATION d'un langage non-OpenSource ?!
" Jag blev dömd för fildelning och allt jag fick var en sketen t-shirt. " (tankafritt.nu)
PAS DE REPONSE PAR MESSAGE PRIVE ! Penser au bouton Résolu en bas de la discussion...
Il n'y avait pas besoin d'attendre le passage en open source pour cela, sous Linux il existe déjà des implémentations libres bacales. L'ouverture des sources va peut être permettre de remettre de l'ordre là dedansEnvoyé par g_rare
question bête : on peut les trouver où les sources ?
Des implémentations Java (ou C++) ?!...
" Jag blev dömd för fildelning och allt jag fick var en sketen t-shirt. " (tankafritt.nu)
PAS DE REPONSE PAR MESSAGE PRIVE ! Penser au bouton Résolu en bas de la discussion...
Java (pourquoi C++Des implémentations Java (ou C++) ?!...).
De tête il y a SableVM mais il en existe au moins 3-4 en plus.
Ceux sont des implémentaions non officiels mais pour avoir essayé d'installer tomcat sous Linux je peux te dire que gcj est pénible : impossible de faire fonctionnner tomcat correctement et pour le remplacer par le Java de sun c'est pas simple (avec les systèmes de paquets, des liens planqués un peu partout) alors que si Java est open source, il pourrait être inclue dans les distributions et remplacer les pseudo-java.
En effet, si Java n'est pas opensource, rien n'empêche à n'importe quiDes implémentations Java (ou C++) ?!...
Java est décomposer en trois grand éléments dont les spécifications sont publiques :
"N'importe qui" peut très bien implémenter cela afin de proposer un JRE (JVM+API) ou un JDK (+compilateur et outils). IBM et Apple propose d'ailleurs leurs propre JRE (et JDK pour IBM).
- Le langage ( http://java.sun.com/docs/books/jls/t...tml/j3TOC.html )
- La Machine virtuelle ( http://java.sun.com/docs/books/vmspec/ )
- L'API ( http://java.sun.com/j2se/1.5.0/docs/api/index.html )
Coté opensource, les plus connu sont Kaffe et SableVM. Leurs plus gros problèmes vient de l'implémentation de l'API qui est plutôt incomplète et qui pose problème...
L'objectif de ces JVM n'est pas d'étendre Java ou son API, mais de proposer une alternative ou à des fins de recherche...
Le problème c'est que comme la JVM de Sun n'est pas opensource, ce sont ces JVM "incomplète" qui se retrouve dans les distributions Linux...
a++
PS : Et le fait que Java ne soit pas ouvert n'a pas empêché Microsoft de sortir une JVM non-compatible...
Je crois même qu'il est possible d'officialiser ses jvm en leurs faisant passer une série de testes mais le problème c'est que ces testes doivent être achetés auprès de Sun et coute chère.
Tout en sachant que sun viens une énième fois de modifier la license de java, et de ce fait la nouvelle version permet d'utiliser directement la JVM sur une debian ou une gentoo (voire sur le site de javaone, je ne sais plus trop où)
Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.
Pour car je rêve d une "vraie" version pour les *BSD d'une part et d une vraie optimisation pour toutes les plateformes tout en gardant son indépendance de l OS...
Contre
parceque si ca passe OpenSource , Microsoft va transformer son .NET en java3 avec la portabilité et tout ,en piquant les sources
Un "fork" fait référence à une dérivation incompatible d'un point de vue API.
Par contre des implémentations différentes d'une même spécifications, c'est déjà une réalité avec les JVM de Sun, BEA, IBM, Apple, ....
Si il respecte les spécification Java alors quel est le problème ???Contre
parceque si ca passe OpenSource , Microsoft va transformer son .NET en java3 avec la portabilité et tout ,en piquant les sources
Dans le cas contraire il y aurait un nouveau procès que Microsoft aurait de forte chance de perdre une nouvelle fois...
Pas forcément... Un "fork" peut très bien respecter les spécifications Java tout en optant pour une autre implémentation (par exemple pour mieux prendre en compte les spécificités de l'OS cible)...
Il n'y a pas forcément un besoin de "cassure" avec l'API de Java (et c'est sûr qu'il faudra éviter cela à tout prix).
C'est une question de vocabulaire, mais "Fork" a une connotation négative, et en particulier dans le cas de Java.
On parle plutôt d'implémentations différentes de la même spécification et c'est bien ce que font les JVM non-Sun et Apache Harmony (travail en cours).
Tous ces produits passent les tests de compatibilité qui ne seraient probablement plus nécessaires si Java était en Open Source.
Sun n'a qu'a donner une licence spéciale pour les distributions
de Linux. Ainsi celles-ci pourront etre packagées avec la JVM de Sun
et donc offrir du Java standard... Et le problème sera reglé !
Ca ne sert à rien de mettre Java en Open Source si c'est pour
perdre la standardisation de Java. Ce serait un crime logiciel !
De plus Sun donne des specifications... N'importe qui est libre
d'en faire sa propre implementation... meme si ce ne seront pas des
versions officielles de Java.
Mercenaire du code
Je crois que ça vient d'être fait justement cf mon dernier post
Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.
Effectivement, la redistribution de JVM est simplifiée avec la DLJ (Distro licence).
Ubuntu, Debian et d'autres ont déjà annoncé leur support: Java: Hot and Spicy for GNU/Linux
Pour mes clients en entreprise, cela me parrait beaucoup plus significatif que l'annonce de Java en Open Source.
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.
Partager