Discussion :

[g_rare]

Hello,

Voilà la question est vaste (vague...) mais elle "mérite" éclaircissement à mes yeux : quelle sont les différences PRINCIPALES et/ou la raison d'être du JDK IBM par rapport au JDK Sun ?
Je dis ça pasque quand on voit par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
/*
 * @(#)src/classes/sov/java/net/URLEncoder.java, net, as1411, 20030925 1.11.2.1
 * ===========================================================================
 * Licensed Materials - Property of IBM
 * "Restricted Materials of IBM"
 *
 * IBM SDK, Java(tm) 2 Technology Edition, v1.4.1
 * (C) Copyright IBM Corp. 1998, 2003. All Rights Reserved
 * ===========================================================================
 */
 
/*
 * ===========================================================================
 * Copyright 2002 Sun Microsystems, Inc. All rights reserved.
 * ===========================================================================
 */
 
/*
 * Change activity:
 *
 * Reason  Date   Origin   Description
 * ------  ----   ------   ----------------------------------------------------
 * 004235  310100 hdmaw    EBCDIC
 * 041015  110202 kwb      Remove 4235 optimization
 * 056111  301002 stalleyj Merge 1.4.1 changes 
 */

on se demande si c'est juste de la recopie avec du tuning par ci par là ou si c'est une réimplémentation complète made in IBM respectant les normes Sun !
Bref si vous avez un point de vue macroscopique ; je suis preneur.

A+

[lunatix]

pas de point de vue precis, mais disons que la jvm publique d'IBM est en partie basée sur celle de sun, c'est d'ailleurs la raison pour laquelle ils ne peuvent pas la rendre open source.

ils en ont deux autres : une en java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://jikesrvm.sourceforge.net/

bon, la l'objectif c'etait de la recherche (une jvm en java...)

et une autre qui n'est pas publique d'apres les echanges sur la mailing liste d'harmony.

En général, les objectifs sont divers (tuning pour un os donné comme aix, os2 etc)

[g_rare]

Donc si jamais je cherche une fonctionnalité en dev, et que je regarde dans la JAVADOC online "officielle" (cf java.sun.com) : c'est garanti par IBM qu'elle se retrouve dans sa JRE et qu'elle respecte scrupuleusement les specs ?!...

Le but c'est de savoir si je peux faire un travail complet sous une JVM quelconque et le livrer sans aucun problème de compatibilité au déploiement ou à l'exécution, alors que je ne connais pas sa "marque" mais juste sa version (JDK 1.4 par exemple) ?


merci_davance

[Satch]

Le but c'est de savoir si je peux faire un travail complet sous une JVM quelconque et le livrer sans aucun problème de compatibilité au déploiement ou à l'exécution, alors que je ne connais pas sa "marque" mais juste sa version (JDK 1.4 par exemple) ?


merci_davance

Malheureusement ce n'est pas garanti.

Il y avait un post récemment de quelqu'un qui avait une JVM différente qu'il avait eu je ne sais plus trop où. Et juste la concaténation de String posait un problème parce dans cette "version" de JAVA, il y avait un problème avec la classe StringBuilder apparemment.

Mais bon, dans les faits, IBM ou SUN ça tournera sans problème.

[adiGuba]

Malheureusement ce n'est pas garanti.

Si justement : sauf bug bien sûr...
C'est d'ailleurs pour cela que Microsoft a du retirer sa JVM : elle ne respectait pas l'API de référence...

Il y avait un post récemment de quelqu'un qui avait une JVM différente qu'il avait eu je ne sais plus trop où. Et juste la concaténation de String posait un problème parce dans cette "version" de JAVA, il y avait un problème avec la classe StringBuilder apparemment.

Ce serait plus un problème de version (StringBuilder n'est apparut que dans Java 5.0).


Bien sûr il reste conseillé d'utiliser la même JVM que le client lorsque c'est possible

a++

[Deadpool]

Je crois que le post évoqué par Satch parlait de gcj qui n'est pas une JVM.

[plegat]

Je crois que le post évoqué par Satch parlait de gcj

Je confirme... ça se passait là: http://www.developpez.net/forums/sho...d.php?t=140490

C'était pour une version gcj équivalente à une JVM 5.0, mais évidemment, pas mal de classes ne sont pas implémentées à 100% avec gcj, donc il arrive que ça plantouille un peu...

[vbrabant]

Malheureusement ce n'est pas garanti.

Il y avait un post récemment de quelqu'un qui avait une JVM différente qu'il avait eu je ne sais plus trop où. Et juste la concaténation de String posait un problème parce dans cette "version" de JAVA, il y avait un problème avec la classe StringBuilder apparemment.

Mais bon, dans les faits, IBM ou SUN ça tournera sans problème.

Ce post concernait GCJ si mes souvenirs sont bons. Qui n'est pas certifié TCK. Or la JDK d'IBM est certifiée selon ce TCK.
Donc, cela devrait marcher, sauf bogues d'implémentations.

Attention que selon les "marques" des JDK, il peut exister des paramètres différents pour le compilateurs javac et l'exécution java. les fameux -X. Mais les paramètres dits 'standards' doivent être supportés par le JDK quelqu'en soit la provenance.

Pour ce qui est de Microsoft, le problème n'était pas vraiment qu'ils ne respectaient pas l'API, mais qu'ils l'avaient étendus en rajoutant certains packages et même en rajoutant certaines méthodes à des classes existantes. Or, quand tu livres une JRE, t'es obligé de livrer tout ce qui se trouve dans les packages java.* ou javax.* Et leur implementations. Et t'as pas vraiment le droit de rajouter quelque chose d'autres. Ainsi, IBM ne pourra jamais livrer un JRE avec SWT intégré dedans. Sauf si Sun rend Java Open Source et abandonne ses droits. Mais je ne suis pas sûr que cela serait une bonne chose. Si Sun avait rendu Java Open Source et abandonné ses droits, Java n'aurait plus été portable, vu que Microsoft aurait pu continuer à faire son propre JRE qui n'aurait été compatible qu'avec lui-même. Au moins, maintenant les choses sont clair. Si tu veux faire un semblant de Java qui s'intègre parfaitement à Windows, tu fais du C#. Pas de conflit de nom.

Aussi, attention que ce qui se trouve dans les packages com.sun ne se trouvent bien évidemment pas dans les JDK d'IBM. Et inversément, dans le JDK d'IBM tu retrouves des packages com.ibm.
Et la seule chose que peuvent contenir ces packages, sont les implémentations des API Java. Ainsi, tu as l'API Sax ou Dom (jaxax.xml....) qui fait partie de ta JRE. Mais l'impleméntation pourrait être Saxon, ou Xalan, ou un parseur propre à IBM, par exemple. Selon le bon vouloir de celui qui crée sa propre JRE.
La seule chose qui est demandée, pour ceux qui veulent dire que leur JRE est du Java, c'est que cela doit passer le TCK. Il faut donc que, quelque soit l'implementation, elle réagisse comme l'API l'a prévue.

Vincent

[adiGuba]

Pour ce qui est de Microsoft, le problème n'était pas vraiment qu'ils ne respectaient pas l'API, mais qu'ils l'avaient étendus en rajoutant certains packages et même en rajoutant certaines méthodes à des classes existantes.

Oui c'est ce que je voulais dire

Ainsi, IBM ne pourra jamais livrer un JRE avec SWT intégré dedans. Sauf si Sun rend Java Open Source et abandonne ses droits. Mais je ne suis pas sûr que cela serait une bonne chose. Si Sun avait rendu Java Open Source et abandonné ses droits, Java n'aurait plus été portable, vu que Microsoft aurait pu continuer à faire son propre JRE qui n'aurait été compatible qu'avec lui-même.

Je pense qu'on pourrait très bien avoir une JVM et un JDK opensource tout en conservant des spécifications et une API stricte comme actuellement...


a++

[g_rare]

Bon, de toute façon (et je le savais) : le sujet me dépasse !
Mais comme éclaircissement il y a eu ; je passe le tout en "résolu" pour ne pas polluer le forum...

Par contre ça ne pourrait pas faire partie de la FAQ Java ???
car j'ai eu beau Googleliser un max j'ai rien trouver de simple et en français pour expliquer les différences de version et/ou de propriétaire selon les JVM

Bref sans vouloir interrompre le débat (intéressant d'ailleurs) je propose de tirer les conséquences du fait que cette simple question fait en réalité ressortir les écarts de perception, connaissances, compréhension même chez des membres émérites

A+