La fondation Apache a annoncé aujourd'hui se retirer du comité exécutif du JCP.
Le JCP (Java Community Process) est en gros le groupe de personnes/entreprises/associations qui décident des évolutions du langage Java.
En l'occurrence, Apache proteste contre le fait que la licencee de la suite de test de Sun/Oracle (TCK) n'est pas compatible avec la distribution sous licencee open source d'une implémentation Java. Hors, cette suite de test est celle qui permet de dire qu'une implémentation est effectivement du Java.
Lors du vote sur Java 7, Apache espérait qu'Oracle modifierait la licencee de la suite de test pour permettre des implémentations open source indépendantes. Ils ne l'ont pas fait.
Il faut savoir que Apache développe le projet Harmony qui est une implémentation open source de Java 5 et 6.
En 2007, Apache avait déjà envoyé une lettre à Sun pour protester contre la licencee de la suite de tests. Après la libération d'OpenJDK, Sun a fournit une licence qui permet à des développeurs d'une implémentation dérivée d'OpenJDK d'utiliser la suite de tests en interne pour valider leur implémentation. Seulement, Apache Harmony n'est pas dérivé d'OpenJDK et c'est là que le bât blesse.
D'après ce que j'ai compris à l'affaire, il n'est toujours pas possible pour une implémentation complètement indépendante de Java sous une licence open source d'utiliser la suite de test officielle de Sun/Oracle.
A mon avis, tout ça n'est pas très bon pour l'avenir de Java. La libération d'OpenJDK avait laissé espérer qu'on allait vers un développement réellement libre de Java et de ses spécifications, mais ça n'est malheureusement pas ce qui est en train de se passer.
Oracle semble définitivement avoir des problèmes avec tout ce qui est libre. Pourtant, énormément d'outils pour Java en entreprise sont des projets libres (JBoss, Hibernate, Eclipse). S'ils commence à se mettre à dos tous les développeurs, ceux-ci risque d'aller voir vers d'autres plateformes. Vu l'inertie des solutions entreprises, le tout Python ou Ruby n'est pas pour demain, mais peut-être à long terme.
N'étant pas familier avec tous les recoins de la communauté Java, j'espère n'avoir pas trop écrit de bêtises, mais si il y a des spécialistes, faites-vous plaisir pour les corriger :)
Journal Apache vs Oracle
10
déc.
2010
# Oracle pas très visionnaire
Posté par Davy Defaud . Évalué à 8.
Il me semble qu'ils n'en sont plus au commencement...
Pas besoin d'oracle pour prédire la suite des événements.
[^] # Re: Oracle pas très visionnaire
Posté par Ontologia (site web personnel) . Évalué à 8.
Au vu du nombre de ligne de codes écrites en Java, et le panurgisme de nombre d'ingénieurs de SSII et de leurs supérieurs qui sont eux-même d'anciens ingénieurs, je pense que Java a de beaux jours devant lui.
Tant que développer, vendre au client, utiliser les frameworks libres à la mode comme Spring (qui bouffent 20Go de mémoire de base) sera gratuit, ils continueront !
Il y aura juste un peu moins d'huile et ça grognera un peu.
La majeur partie de la spec de java est derrière nous. Et quand tu vois le nombre d'année qu'il a fallu pour que tout le monde passe à Java 1.5 (et encore c'est pas le cas partout), Java7 c'est pas pour demain.
Python ? Oui pourquoi pas, mais c'est pas à la mode chez les daïcidors.
Ruby ? Trop conceptuel pour eux, 80% des développeurs ont du mal à comprendre, déjà qu'ils ont du mal avec l'objet...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Oracle pas très visionnaire
Posté par Maclag . Évalué à 3.
déjà qu'ils ont du mal avec l'objet...
J'ai jamais bossé en SSII, et suis même pas développeur, mais y'a que moi que ça fait tiquer les deux phrases ensembles, là??
[^] # Re: Oracle pas très visionnaire
Posté par windu.2b . Évalué à 9.
Je conçois parfaitement que cela puisse être, au premier abord, antinomique, mais en fait pas tant que ça, quand on sait quel est le niveau de connaissance de la POO chez les développeurs de SSII !
Java est un langage objet, certes... Mais c'est pas pour autant qu'on voit partout fleurir du code propre, bien conçu, basé sur des design patterns éprouvés, ...
Bref, le code de porc est possible, même avec un langage orienté objet
[^] # Re: Oracle pas très visionnaire
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Oracle pas très visionnaire
Posté par totof2000 . Évalué à 1.
Ca aussi ça me fait rire : les design patterns : quand c'est bien utilisé, c'est efficace, par contre il y a des developpeurs qui veulent à tout prix caser leur design pattern là ou ça n'est pas adapté.
Sinon je suis d'avis que quand on rendra aux ingénieurs l'ingénierie, et aux codeurs le code, chacun fera son travail correctement.
[^] # Re: Oracle pas très visionnaire
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Document reponse = DocumentBuilderFactory.getInstance().newDocumentBuilder().createDocument()Cette classe DocumentBuilderFactory est un singleton fabrique de fabrique de documents XML…
[^] # Re: Oracle pas très visionnaire
Posté par Ontologia (site web personnel) . Évalué à 2.
Du coup, tu as un singleton naturel.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Oracle pas très visionnaire
Posté par gaaaaaAab . Évalué à 6.
En tant qu'ingénieur, ça me gaverait bien de pas pouvoir mettre les doigts dans le code.
[^] # Re: Oracle pas très visionnaire
Posté par totof2000 . Évalué à -6.
Tu vois beaucoup d'ingénieurs dans le batiment aller poser des briques ou couler du béton toi ? Chacun son travail.
En tant qu'ingénieur, ça me gaverait bien de pas pouvoir mettre les doigts dans le code.
Peut-être que tu t'es trompé de métier ? Ou alors tu as le titre d'ingénieur mais tu n'as pas le boulot d'un ingénieur (et on en revient à ce que je disais plus haut).
[^] # Re: Oracle pas très visionnaire
Posté par Shuba . Évalué à 9.
Tu vois beaucoup d'ingénieurs dans le batiment aller poser des briques ou couler du béton toi ? Chacun son travail.
Il me semblait qu'en informatique, le travail des ouvriers est fait par quelquechose appelé un compilateur.
Si, dans cette opposition codeur/ingénieur, tu considères que le rôle du codeur c'est cracher du code sans réfléchir (et c'est ce que je comprends de ce que tu dis), alors il y a un problème, les tâches où on ne réfléchit pas, ce n'est pas pour l'homme.
[^] # Re: Oracle pas très visionnaire
Posté par bubar🦥 (Mastodon) . Évalué à 5.
[^] # Re: Oracle pas très visionnaire
Posté par Shuba . Évalué à 2.
[^] # Re: Oracle pas très visionnaire
Posté par Gniarf . Évalué à 7.
[^] # Re: Oracle pas très visionnaire
Posté par totof2000 . Évalué à 2.
Tu déformes mes propos (ou je n'ai pas été clair).
Je pense que l'ingénieur doit faire son boulot d'ingénieur et spécifier ce qu'il veut. Charge ensuite aui codeur de coder les spécifications. Ca ne veut pas dire ne pas réfléchir, ca veut juste dire deux réflexions différentes. Si l'ingénieur a besoin de mettre son nez dans le code c'est parce qu'il n'a pas confiance en son développeur.
Après, dire qu'un maçon pose des briques sans réfléchir .... c'est pas moi qui l'a dit. être maçon c'est un métier qui nécessite un minimum de réflexion, et ce n'est pas moi qui ai comparé le maçon à un compilateur.
[^] # Re: Oracle pas très visionnaire
Posté par Gniarf . Évalué à 1.
[^] # Re: Oracle pas très visionnaire
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oracle pas très visionnaire
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Oracle pas très visionnaire
Posté par Gniarf . Évalué à 3.
faire faire des tâches à peine plus évoluées que du copier-coller (genre au pif réaliser des écrans de saisie Web avec toutes les briques déjà faites) par des BAC+5 + expérience c'est foutre de l'argent et des compétences en l'air
maintenant, si les clientes des SSII réclament absolument "des ingénieurs" parce que ça leur flatte le gourdin et que prendre "des techniciens" ça ne correspond pas à leur standing, je n'y peux pas grand chose
[^] # Re: Oracle pas très visionnaire
Posté par gaaaaaAab . Évalué à 2.
calquer des raisonnements du monde physique dans un domaine intellectuel, ça marche pas bien.
Mon boulot consiste à m'appuyer sur des compétences techniques pour imaginer et implémenter des solutions aussi simples que possibles à des problèmes complexes que je rencontre pour la première fois. Après, t'appelles ça comme tu veux :)
Dans mon expérience, la plupart du temps, les problématiques d'implémentation viennent aussi nourrir la réflexion. Si je ne devais qu'écrire des documents d'architecture ou des spécs techniques sans toucher une machine, les résultats seraient moins satisfaisants.
Si tu arrives à écrire en amont tout la documentation technique décrivant une solution adaptée aux problèmes qu'on te présente, chapeau bas, je n'en suis pas encore là.
(mais c'est pas non plus dans cette direction que je vais :)
[^] # Re: Oracle pas très visionnaire
Posté par totof2000 . Évalué à 2.
calquer des raisonnements du monde physique dans un domaine intellectuel, ça marche pas bien.
c'est dingue. Vous êtes comiques. C'est vous qui avez à l'idée qu'un maçon n'a pas à réfléchir. Pas moi. Je voulais juste signaler que spécifier et coder étaient 2 métiers différents (avec je vous l'accorde une limite difficile parfois à établir).
Mon boulot consiste à m'appuyer sur des compétences techniques pour imaginer et implémenter des solutions aussi simples que possibles à des problèmes complexes que je rencontre pour la première fois. Après, t'appelles ça comme tu veux :)
Je pense que c'est surtout un manque de confiance (parfois justifié, parfois non) vis à vis des gens qui savent. Parce que toi, tu rencontres des problèmes pour la première fois, mais les codeurs ont peut être déjà rencontrés le même type de problème.
Dans mon expérience, la plupart du temps, les problématiques d'implémentation viennent aussi nourrir la réflexion. Si je ne devais qu'écrire des documents d'architecture ou des spécs techniques sans toucher une machine, les résultats seraient moins satisfaisants.
... ou pas, tout dépend de la confiance que tu as ou peux avoir vis à vis des équipes de codeurs.
Si tu arrives à écrire en amont tout la documentation technique décrivant une solution adaptée aux problèmes qu'on te présente, chapeau bas, je n'en suis pas encore là.
(mais c'est pas non plus dans cette direction que je vais :)
Ben si tu arrives à spécifier dans les grandes lignes la solution de ton problème et que tu la présentes à un codeur, il pourra te dire ce qui marche ou ne marche pas dans ta solution. Toi si tu n'as pas la même expérience du codage tu ne pourras pas forcément fournir une solution des plus adaptées au problème mais juste un truc qui marche.
Je pense que vous n'avez pas compris le sens de ma comparaison avec le maçon et l'ingénieur en batiment (ou alors je l'ai mal exprimée).
[^] # Re: Oracle pas très visionnaire
Posté par gaaaaaAab . Évalué à 4.
c'est pas ce que je voulais dire. Pour moi, sur le plan technique, la séparation entre la réflexion et l'implémentation ne peut pas être aussi tranchée quand dans d'autres secteurs.
En s'intéressant à la question de la documentation, http://thedailywtf.com/Comments/Documentation-Done-Right.asp(...) décrit un processus de développement dans lequel je me retrouve pas mal.
Tu sembles regarder le code un peu de haut, ce en quoi je pense que tu te trompes (cf Code Complete http://cc2e.com/File.ashx?cid=334 page 5: "Why This Handbook Was Written"). Quand tu présentes un truc à un technique pour qu'il donne son avis, t'as quand même sacrément intérêt à ce qu'il soit ingénieur (ou qu'il aie une mentalité d'ingénieur, je connais un diplômé de BTS beaucoup mieux formé que certains ingé en titre).
Si je ne me trompe pas, la distinction que tu fais entre fonctionnel et technique correspond aux traditionnelles maîtrise d'oeuvre/maîtrise d'ouvrage. C'est marrant parce que ce vocabulaire vient directement du monde du BTP. Fut un temps, je cherchais à traduire MOA/MOE en anglais. Je n'ai pas réussi, et j'ai appris au passage que l'application de ces concepts à l'informatique est une pratique franco-française.
Parce que toi, tu rencontres des problèmes pour la première fois, mais les codeurs ont peut être déjà rencontrés le même type de problème.
Je ne vois personnellement pas d'opposition entre ingénierie et développement, d'ailleurs, je me vis comme ingénieur et développeur.
ah tiens, précision utile, je suis diplômé d'une école d'ingé spécialisée en informatique. Si tu viens d'une filière plus généraliste, ça peut expliquer aussi nos différences d'appréciation.
[^] # Re: Oracle pas très visionnaire
Posté par totof2000 . Évalué à 1.
Et malhereusement cet état d'esprit n'est pas propre à l'informatique, mais c'est peut-être un problème typiquement français. Beaucoup de décisions sont prise par des gens qui ne connaissent pas grand chose, en faisant fi de l'expérience et du bon sens des personnes qui sont confrontés tous les jours à ces problèmes. Et pour moi c'est typiquement un manque de confiance.
[^] # Re: Oracle pas très visionnaire
Posté par Jux (site web personnel) . Évalué à 7.
J'ai fais une formation d'ingénieur en informatique en Suisse (Bachelor/Master) et on a mangé du code mais aussi de la modélisation. Les "Software Architect" que je connais ben ils codent quand même (pas à 100%, mais ils participent aux projets). Mais globalement, la majorité des développeurs (architectes ou codeurs) sont ingénieurs en informatique.
[^] # Re: Oracle pas très visionnaire
Posté par totof2000 . Évalué à 2.
[^] # Re: Oracle pas très visionnaire
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est dommage que les "ingénieurs-codeurs-sysadmin-netadmin-*" ne viennent pas eux-mêmes dépanner leurs conneries ... bon remarque, j'aurais du sang sur les mains, mais au pire je reçois le prix Turing pour ça.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Oracle pas très visionnaire
Posté par gaaaaaAab . Évalué à 2.
celà dit, il n'y a pas lieu de restreindre aux seuls développeurs en SSII ...
[^] # Re: Oracle pas très visionnaire
Posté par campagnard . Évalué à 7.
Conversation type :
"T'as déja fait du Java ?
- Non. Enfin si, un tout petit peu, à l'ecole y'a 5 ans, mais c'etait un tout petit projet.
- OK, donc t'en as déja fait. Je rajoute une ligne sur ton CV, ca nous aidera toujours à te trouver une mission.
- .... (soupir de lassitude)"
Ce n'est pas un exemple inventé, mais du vécu (pas avec Java).
[^] # Re: Oracle pas très visionnaire
Posté par grid . Évalué à -3.
Un informaticien ne doit pas s'arrêter à un langage, une techno...
Parce que dans la réalité, le même mec qui soupire, s'il passe un jour coté client, il fera chier le même commercial parce que le gars n'a pas marqué le mot clef attendu qu'il a en tête.
[^] # Re: Oracle pas très visionnaire
Posté par Fopossum . Évalué à 6.
Rectification.
Merci de ne pas limiter l'informatique au développement !
cd /pub && more beer
[^] # Re: Oracle pas très visionnaire
Posté par gaaaaaAab . Évalué à 7.
[^] # Re: Oracle pas très visionnaire
Posté par Maclag . Évalué à 2.
[^] # Re: Oracle pas très visionnaire
Posté par gaaaaaAab . Évalué à 3.
Pis de toute façon, les commerciaux sont du côté obscur de la force ;)
[^] # Re: Oracle pas très visionnaire
Posté par Gniarf . Évalué à 5.
[^] # Re: Oracle pas très visionnaire
Posté par Maclag . Évalué à 2.
Si on recrute les développeurs n'importe comment, tu n'espères pas qu'on demande aux commerciaux de comprendre le principe du développement logiciel?
Je connais une étrangère en France qui s'est étonnée que la boucherie musulmane ne propose pas de porc ("ah? vous êtes une boucherie musulmane?! pourquoi faire, il suffit de ne pas vendre de porc aux musulmans, et pis voilà" réponse gênée des bouchers "non non non, ça marche pas comme ça").
Bref tu vois, ta comparaison est pertinente, il n'empêche que...
[^] # Re: Oracle pas très visionnaire
Posté par campagnard . Évalué à 6.
Après, le client va être mécontent (et il aura raison) parce qu'on lui a vendu quelqu'un qui n'a pas les compétences demandées (il a pas forcément la possibilité de laisser la personne s'auto-former pendant quelques semaines).
Heureusement les clients inteligents posent quelques questions pendant l'entretien pour évaluer ce genre de choses. Et la, le beau discours du commercial se casse la gueule. Ca n'aide pas à établir une relation de confiance.
[^] # Re: Oracle pas très visionnaire
Posté par Pierre Tramonson . Évalué à 0.
Elle doit s'adapter à ce qui existe sur le marché des logiciels, c'est rarement une SSII qui invente un logiciel ou qui permet aux développeurs de développer sur tout et n'importe quoi.
A partir du moment ou tu bosses pour un client, il faut bien accepter de faire ce pour quoi il te paie :)
[^] # Re: Oracle pas très visionnaire
Posté par Fabimaru (site web personnel) . Évalué à 3.
Et si le client a besoin de nettoyer les chiottes, faut bien le faire parce que c'est le besoin du client? Y a quand même une limite dans cette adaptation, on ne transforme pas d'un coup de baguette magique un admin DB en développeur Java (ou alors en développeur Java super-débutant) ou un dev Java en designer web. Ou en fait si, on le fait pour pouvoir virer l'employé pour incompétence.
[^] # Re: Oracle pas très visionnaire
Posté par 2PetitsVerres . Évalué à 2.
[...]
- Ou alors [plutôt que de réassigner des gens sur place pour finir dans les délais un outil interne] il nous faut une star en java, pour finir ça dans les délais [pour démarrer le projet X à temps]
- c'est possible aussi. Surtout qu'on trouve ça facilement, on appelle une SSII, ils en ont plein
[...]
Bon, j'ai trouvé ça [:flu1]xifiant. Et le pire (si j'ai bien compris) c'est qu'au final c'est moi (entre-autres, mais bon) qui vait devoir bosser sur cet outil (et que j'ai vraiment, mais vraiment pas envie de bosser dessus /o\ )(moi je dis qu'on ne peut pas finir dans les délais, même en mettant 42 fois plus de gens dessus, mais bon)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Oracle pas très visionnaire
Posté par Gniarf . Évalué à 2.
[^] # Re: Oracle pas très visionnaire
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Oracle pas très visionnaire
Posté par monde_de_merde . Évalué à 2.
Et dans mon labo, mais c'est en France :p
# Language
Posté par weonbin . Évalué à 6.
Dans ce cas je mise plutot sur le tout .NET
Ruby et python ne répondent pas aux mêmes besoins.
J'espère qu'on en arrivera jamais là.
Les développeurs pourraient techniquement porter leur code sur harmony pour se débarrasser du boulet qu'est oracle, mais avec le risque de procès liés aux brevets (cf google avec android), je ne suis pas sur que beaucoup d'entreprises suivent.
[^] # Re: Language
Posté par HardShooter . Évalué à 2.
Le futur est peut-être vers une extension de LLVM en lui rajoutant un garbage collector et sûrement d'autre chose que j'oublie (généricité ?)
[^] # Re: Language
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: Language
Posté par lasher . Évalué à 2.
[^] # Re: Language
Posté par HardShooter . Évalué à 1.
[^] # Re: Language
Posté par lasher . Évalué à 2.
[^] # Re: Language
Posté par HardShooter . Évalué à 2.
C'est ce que fait unladen swallow pour python ou même mono pour .NET (c'est expérimental mais ils ont bien un backend LLVM)
[^] # Re: Language
Posté par lasher . Évalué à 2.
[^] # Re: Language
Posté par rewind (Mastodon) . Évalué à 2.
[1] http://llvm.org/docs/LangRef.html#int_gc
[^] # Re: Language
Posté par Dellara . Évalué à 1.
feature: caractéristique
Je sais le deuxième est plus long à écrire en français, mais quand même ;)
[^] # Re: Language
Posté par Maclag . Évalué à 2.
[^] # Re: Language
Posté par El Titi . Évalué à 2.
Ils peuvent très bien forker Java en changeant juste le nom et les artworks pour ne pas rentrer en conflit avec Oracle. C'est toujours libre. Un peu comme les forks de FF qui ont donné Iceweasel
Là où c'est regrettable c'est que Apache, en tant qu'entité indépendante ne sera plus partie prenante dans les directions que prendra le langage (qui reste entre amis IBM, Apple et Oracle) et que le fork risque d'être à la traîne (comme Mono) ou de dériver complètement à terme mais ce n'est peut-être pas un mal.
[^] # Re: Language
Posté par claudex . Évalué à 4.
Demande à Google qui se sont basé sur Harmony pour Android et qui sont sous le feu d'Oracle via les brevets sur Java.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Language
Posté par Zenitram (site web personnel) . Évalué à 3.
[^] # Re: Language
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Language
Posté par Zenitram (site web personnel) . Évalué à 4.
Il y a toujours une forte différence au niveau brevets sur les deux projets, l'un est protégé, pas l'autre.
[^] # Re: Language
Posté par El Titi . Évalué à 2.
(C'est pas pour rien que M$ fudde sur Linux depuis des siècles)
Ca change rien au pb.
Le droit des marques n' a rien à voir avec le système des brevets.
Sauf qu'explicitement décrit (pas vérifié et pas contraignant juridiquement, je crois), ils peuvent très bien exiger la même chose de toute boîte qui utiliserait OpenJDK mais ne le font pas car ca leur permet de contrôler Java tout en virant la concurrence (et de fourguer des licences payantes de JavaME) .
C'est pas pour rien que la GPLv3 existe (et qu'on ne sait pas encore si elle est juridiquement solide).
[^] # Re: Language
Posté par j_kerviel . Évalué à 2.
Ben oui, les brevets pèsent sur n'importe code qu'il soit libre ou non.(C'est pas pour rien que M$ fudde sur Linux depuis des siècles)
Rien à voir. Là on parle de brevet sur le langage lui même, pas sur ce qui est codé.
Comme Kodak qui a soit disant des brevets qui couvrent la notion d'orienté objet : http://news.cnet.com/Kodak-wins-Java-patent-suit/2100-1014_3(...)
[^] # Re: Language
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Language
Posté par Gniarf . Évalué à 2.
# Point chaud
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 2.
http://www.jcp.org/en/jsr/results?id=5111
Je ne comprend pas pourquoi les sociétés/groupes comme red hat ou eclipse ont voté oui.
Seul 3 entités ont voté contre, dont google (qui utilise harmony sur android) et la fondation apache (qui développe harmony).
Les autres ont l'air de s'en foutre royalement.
[^] # Re: Point chaud
Posté par Benoit . Évalué à 10.
Keil, Werner :
While I'm equally dissapointed with the ongoing license dispute and the effect this and other issues had on the actual content and scope of Java 7
SAP AG :
While we are disappointed that Oracle has decided to deny Apache a TCK license for Java 7, SAP's vote is strictly based on the technical merits of the Java 7 specification, not on its license terms.
IBM :
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.
Eclipse Fundation :
Eclipse is disappointed with the continuing issues around Java licensing. [...]
Our vote is based entirely on the premise that improvements and evolution are required if the Java platform is to remain viable.
Red Hat :
Red Hat's vote is based solely on the technical merits of the JSR. We believe that this JSR is important for the industry at large and that further delays risk fracturing the Java landscape further. However, we are extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead.
Credit Suisse :
Credit Suisse's vote is purely on the technical content. We strongly demand open standards and an active community around Java as we selected Java SE & EE as primary pillars for our application development. [...] While we recognize Oracle’s intellectual properties around Java, we strongly encourage Oracle to re-think its current position around licensing terms.
A part VMWare, HP, Ericson, Intel, les membres se posent clairement des questions à propos de la licence.
Mais, de toute façon, le commentaire de Google résume bien ce qu'Oracle pense du JCP :
We were initially reluctant to vote no because we do not want to delay progress of the Java platform. But this concern was made moot by Oracle's statement at the JCP meeting of 10/4/2010 that they intend to move forward with the release outlined in this JSR with or without the approval of the JCP.
[^] # Re: Point chaud
Posté par Zenitram (site web personnel) . Évalué à 6.
Pas assez pour que soit un point bloquant, le libre passe en priorité faible par rapport à d'autres priorités, même chez RedHat (je suis le plus déçu par eux), dommage...
they intend to move forward with the release outlined in this JSR with or without the approval of the JCP.
Ouch... La, il faut se demander si ça vaut le coup de ne pas prononcer sa dissolution si le vote n'a plus du tout d'impact...
Au final, Java piloté par Oracle vs C# piloté par Microsoft, on est mal barrés. Bon, ben moi je reste au C++, c'est lent à évoluer, il manque plein de bibliothèques standard, mais au moins c'est démocratique ;-).
[^] # Re: Point chaud
Posté par vrm (site web personnel) . Évalué à 9.
Comme quoi Oracle a trop d'influence pour guider les specs de Java
# Voyons donc maintenant
Posté par pasBill pasGates . Évalué à 4.
Juste histoire d'etre honnete avec soi-meme...
[^] # Re: Voyons donc maintenant
Posté par Maclag . Évalué à 6.
Perso je m'en fous que Mono/C# soit dans Debian ou pas. Si quelqu'un râle, et ben qu'il râle!
En ce qui concerne le risque sur les brevets, il ne date pas de cette annonce, qui n'a rien à voir.
Rien n'empêche d'installer autre chose que le Java Sun/Oracle. Zut pour Java7, c'est tout!
Je crois que je n'ai presque rien sur ma machine qui dépende de Java.
Conclusion: Oracle confirme ce qu'il est un peu plus tous les jours. Java va prendre du plomb dans l'aile, ce qui est peut-être une bonne nouvelle finalement?
Merci Oracle!
[^] # Re: Voyons donc maintenant
Posté par ckyl . Évalué à 2.
Je suis déçu par cette décision qui n'est pas vraiment une nouvelle (ca fait juste des années que ca traine, et aucune raison pour que ca change maintenant surtout depuis que IBM s'est tiré d'harmony pour aller rejoindre son copain oracle sur OpenJDK (qui devrait fusionner avec JRockit). Mais il faut arrêter de rêver. Cette décision ne changera strictement rien. Tout ce que ca annonce, c'est que la réponse est officiellement non, alors que depuis quelques années c'était "oui peut être repassez dans six mois". Et si on regarde les VM qui sont utilisées dans le vrai monde, y'a pas des masses d'utilisateurs qui vont s'en offusquer...
[^] # Re: Voyons donc maintenant
Posté par DLFP est mort . Évalué à 2.
En tout cas je ne confierai rien d'important à une application Mono vu que je n'ai pas d'assurance quant à son avenir.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Voyons donc maintenant
Posté par mornik . Évalué à 4.
[^] # Re: Voyons donc maintenant
Posté par zebra3 . Évalué à 0.
À moins que tu ne confondes avec .Net ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Voyons donc maintenant
Posté par mornik . Évalué à -3.
Bref c'était un raccourci compris de tous ou presque (et ceux dans le presque et bien comment dire ? Non rien j'vais pas allumer une mèche à cette heure ci :D )
[^] # Re: Voyons donc maintenant
Posté par Dring . Évalué à 10.
Franchement, y'aurait du java dans Gnome ou KDE, je pense que tout le monde gueulerait depuis longtemps.
D'ailleurs, y'a du java dans OpenOffice, et tout le monde gueule depuis longtemps.
[^] # Re: Voyons donc maintenant
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Voyons donc maintenant
Posté par El Titi . Évalué à 2.
[^] # Re: Voyons donc maintenant
Posté par sifu . Évalué à 1.
[^] # Re: Voyons donc maintenant
Posté par j_kerviel . Évalué à 9.
Alors, va t'on voir tous ces gens qui descendaient Mono/C# demander le retrait de Java des distributions ?
Carrément.Juste histoire d'etre honnete avec soi-meme...
J'ai toujours été contre mono que ce soit dans Debian ou les autres distribution, dans Gnome, et contre Novell (encore un peu plus qu'avant quoi).
Mais je n'ai pas attendu cet épisode pour être contre java.
Je te refais l'historique :
Avant java ce n'était pas libre. J'étais donc très véhément contre, vu que par définition c'est pas libre, donc c'est de la merde.
Ensuite java a tenté une libération. Du coup, j'ai continuer à critiquer vu que, ne nous voilons pas la face, java reste merdique. Mais j'ai arrêté de le faire parce que ça n'est pas libre et donc de le déconseiller aux libristes.
Aujourd'hui retour à la case départ.
Et même mieux. Aujourd'hui, on peut dire « Alors les mecs, qu'est ce qu'on vous avait dit ? »
Alors google et apache (qui met du java partout, et encore pire : du svn), ils sont bien gentils, mais il fallait peut être réfléchir avant d'utiliser un langage de merde. C'est un peu tard pour venir chouiner.
C'est une nouvelle preuve qu'il faut promouvoir le libre et que parler de pérennité, c'est pas pour trois barbus dans une cave. C'est vrai pour tout le monde.
Visiblement, les histoires à la bitkeeper, java, etc. ne marquent pas les esprits. Peut être que demain on aura la même chose avec mono ou autre chose. Et il y en aura toujours pour se faire avoir.
(Super journal de trolldi, bien vu)
[^] # Re: Voyons donc maintenant
Posté par El Titi . Évalué à 0.
entre les
mais il fallait peut être réfléchir avant d'utiliser un langage de merde.
les histoires à la bitkeeper,
....
Java, ses spécifications et son implémentation sont toujours libres, que je sache.
On a une marque déposée et un kit de test qui n'est pas libre.
Fias gaffe quand même, le microcode de ton PC ne l'est peut-être pas non plus.
Et par ailleurs, on a des brevets qui sont complètement orthogonaux avec la définition de LL.
[^] # Re: Voyons donc maintenant
Posté par Zenitram (site web personnel) . Évalué à 2.
Pas si orthogonal que ça : la (L/A)GPL inclu des protection contre les brevets justement pour pas se faire avoir.
Certes ce n'est pas le libre en général (BSD et compagnie n'ont pas de protection contre les brevets), mais moi ça me motive à militer encore plus pour les licences de la FSF, pour se débarrasser de ces satanés brevets logiciels.
[^] # Re: Voyons donc maintenant
Posté par El Titi . Évalué à 2.
Tu ne conteste pas qu'un code sous (A/L)GPL puisse violer des brevets et ne protège en rien contre celui qui n'utilise pas ce code et attaque. Elle fait simplement perdre ces droits sur ce code à celui qui le ferait et conforte simplement entre eux ceux qui rentrent dans la danse. L'insécurité juridique reste entière par rapport à ceux qui en dehors.
(Sinon y'a qu'à passer Harmony en AGPL pour squizzer Oracle)
Tu ne contestes pas non plus que cette protection est toute relative et qu'il n'est pas sûr qu'elle résiste à l'épreuve d'un jugement.
Et enfin tu ne contestes pas non plus que les brevets ne sont pas valides partout.
[^] # Re: Voyons donc maintenant
Posté par Zenitram (site web personnel) . Évalué à 2.
Il me semble que la version de Java sous GPLv2 n'a pas ce problème, Oracle se permet d'attaquer Google parce que la licence protégeant des brevets n'a pas été utilisée par Google
Mais j'aurai dû préciser : les versions 3 des licences, c'est plsu clair avec les versions 3.
Tu ne conteste pas qu'un code sous (A/L)GPL puisse violer des brevets et ne protège en rien contre celui qui n'utilise pas ce code et attaque.
La version 3 des licences fait tout ce qu'elle peut pour protéger contre l'utilisation des brevets, à défaut des les éradiquer.
Et enfin tu ne contestes pas non plus que les brevets ne sont pas valides partout.
Rien à faire qu'ils ne soit pas valide partout, l'important c'est la où est le fric, le reste c'est de la masturbation intellectuelle. Et en pratique, 90% du fric est dans des (un) pays qui ont les brevets, faut vivre avec, que ça plaise ou non.
[^] # Re: Voyons donc maintenant
Posté par El Titi . Évalué à 2.
Il n'en demeure pas moins que cette assertion:
Avant java ce n'était pas libre.
...
Aujourd'hui retour à la case départ.
est fausse
et qu'en l'état actuel des choses, l'insécurité sur les brevets porte sur n'importe quel LL et qu'il soit en nGPLv3 ou non elle est toujours présente.
Avec le droit d'auteur, ceux qui sont en dehors du projet GPL n'interfèrent pas et la GPL protège, avec les brevets ce n'est pas le cas. Les brevets des autres m'emmerdent et pour être couvert, il faut je me renseigne et que je rentre malgré moi dans le système.
[^] # Re: Voyons donc maintenant
Posté par ZankFrappa . Évalué à 2.
[^] # Re: Voyons donc maintenant
Posté par zebra3 . Évalué à 4.
Pour ma part, je n'utilise pas d'application en Java.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Voyons donc maintenant
Posté par ZankFrappa . Évalué à 2.
# Hors != Or
Posté par Gui13 (site web personnel) . Évalué à 10.
Il faut éviter de confondre "hors" et "or"!
Je suis hors de moi;
Je suis hors de danger;
La machine est hors-service.
Sont des usages corrects de hors.
"Or" s'emploie dans un tout autre contexte, et dans la phrase:
Hors, cette suite de test est celle qui permet de dire qu'une implémentation est effectivement du Java.
C'est bien "Or" qui devrait être employé:
Or, cette suite de test est celle qui permet de dire qu'une implémentation est effectivement du Java.
J'ai vu cette erreur dans 3 journaux sur la semaine passée, c'est dingue!
[^] # Re: Hors != Or
Posté par Dabowl_75 . Évalué à 2.
==> DTC
http://fr.wikipedia.org/wiki/Conjonction_de_coordination
[^] # Re: Hors != Or
Posté par Maclag . Évalué à 5.
[^] # Re: Hors != Or
Posté par cram51 . Évalué à 3.
mais ou
[^] # Re: Hors != Or
Posté par j_kerviel . Évalué à 5.
[^] # Re: Hors != Or
Posté par dinomasque . Évalué à 2.
http://linuxfr.org/comments/1189258.html#1189258
Et après on luttera contre la pratique imbécile et webicide des liens en "note de bas de page" (l'hypertexte c'est pas fait pour les chiens).
BeOS le faisait il y a 20 ans !
[^] # Re: Hors != Or
Posté par El Titi . Évalué à 1.
Par contre si la note de bas de page ne renvoie qu'un lien et que dans le même temps l'hypertexte entoure quelques mots, que le lien est bien en rapport avec ceux-ci sans être trop généraliste, c'est autre chose.
Bref tout est affaire de dosage et de pertinence.
[^] # Re: Hors != Or
Posté par dinomasque . Évalué à 7.
Dans une balise de lien HTML on peut mettre un court descriptif à la place de l'URL vers laquelle pointe le lien.
Astuce : c'est la balise 'a' de HTML
Si un contributeur de LinuxFR n'a pas les capacités de raisonnement ou les invraissemblables connaissances techniques pour comprendre comment fonctionne cette technologie avant-gardiste, je suis sur qu'il trouvera un relecteur pour l'assister.
Pour le reste, le formulaire de soumission de dépêche fournit ce qu'il faut pour faire un récapitulatif des liens en bas d'article qui peut s'avérer pratique pour les lecteurs pressés.
BeOS le faisait il y a 20 ans !
[^] # Re: Hors != Or
Posté par JGO . Évalué à 0.
1. Elles dissimulent le lien. Obligé de passer en hover pour voir où ça pointe. Sachant que la plupart des sites ne règlent pas la balise « titre », le nom apparait seulement dans la barre d'état, qui avec mon navigateur actuel n'est pas lisible.
Exemple : dois-je faire confiance au lien hypertexte pour le cas suivant :
Oracle a [a href="http://forum.kikoolol-sms.com/thread-oracle.html"]décidé de ce changement[/a] en 2010
2. Les notes permettent de contextualiser le lien
Oracle a décidé de ce changement en 2010 [1].
[1] D'après une déclaration du CEO, voir http://...
ou bien
[1] Voir le très long article d'analyse de Machin Bidule, 5 paragraphes avant la fin de la 3e section, http://...
[^] # Re: Hors != Or
Posté par zebra3 . Évalué à 8.
Ça, c'est un problème du navigateur, pas de la méthode, qui elle est standard et adaptée à la problématique de l'accessibilité.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Hors != Or
Posté par totof2000 . Évalué à 6.
(je me demande si je dois être fier ou avoir honte).
[^] # Re: Hors != Or
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 5.
Cette faute est devenue hyper-fréquente non seulement dans les commentaires des forums, les blogs, etc. mais j'ai commencé à l'apercevoir également dans les articlescopier-coller AFP des journaux gratuits.
Sur la tribune, cette entorse à la leçon 123 est plutôt la règle que l'exception, à tel point que j'ai renoncé à poster systématiquement le lien ( http://lecons.ssz.fr/lecon/123 ). J'attends avec une horreur croissante le moment où je commencerai à l'écrire machinalement, par mimétisme, comme cela m'est déjà arrivé avec la leçon 1 ( http://lecons.ssz.fr/lecon/1 ). Mes yeux saignent et mon coeur pleure
[^] # Re: Hors != Or
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: Hors != Or
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# mais si il y a des spécialistes, faites-vous plaisir pour les corriger
Posté par totof2000 . Évalué à 4.
# Le poème du vendredi
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 4.
Démonter la lune et le SUN
Vider l'océan, arracher les forêts
Car rien de bon ne peut advenir désormais.
La gelée de coings est une chose à ne pas avaler de travers.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.