Discussion :

[adiGuba]

Salut,

J'ai testé le JDK 1.5 beta et voici mes premières impressions :

J'ai bien aimé :

• - Le nouveau style du look par défaut (Metal) qui donne un coup de jeune aux programme Swing. Comparer par vous-même : Metal 1.4 et Metal 1.5.
  - Le retour du System.getenv() !
  - Le printf() pour formater les textes de sorties !!! (surtout lorsqu'on vient du C comme moi)
  - Les Générics et les boucles for étendu bien pratique pour éviter plusieurs cast ! D'ailleurs les générics sont utilisé dans un grand nombre de classe et d'interface de l'API.
  - L'Autoboxing pour ne plus s'embrouiller entre type primaire et classe...
  - Les énumérations orientées objets qui permettent des trucs sympa...

Ce qui peut également servir :

• - Les static import bien que je ne trouve pas ca super utile.
  - Les varargs pour des méthodes avec arguments multiples (même si on pouvait déjà le faire avec un tableau en arguments. D'ailleurs à l'intérieur de la méthode cela revient à utiliser un tableau d'Object).
  - Le WindowsClassicLookAndFeel qui correspond au look classique de Windows et le SynthLookAndFeel qui est entrièrement modifiable par fichier de config (pas testé...)
  - Le jFrame.add() qui est équivalent à jFrame.getContentPane().add...
  - etc... (il y en as surement beaucoups plus que je n'ai pas vue )

En ce qui concerne la compilation

• - Pour utiliser les nouveautées du langage, il faut utiliser l'option -source 1.5 comme Replouf66 l'a dit plus haut. Mais du coups nos .class ne peuvent être exécuté que par des MV 1.5 !!!
  Pas de portabilité avec les MV précédentes si on utilise les nouveautées du language (dans un sens c'est normal)...
  - Lorsqu'on compile un code qui utilise une classe qui désormais utilise les générics (par exemple ArrayList) on a un warning du genre :
  

  Code :

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

  1
  2
  Note: Main.java uses unchecked or unsafe operations.
  Note: Recompile with -Xlint:unchecked for details.

  Cela fonctionne quand même comme avant mais il est préférable d'utiliser les générics...
  - Sinon rien de bien méchant...

Et voilà, personnellement je trouve que la plupart de ces nouveautées facilitent la saisie et la lecture du code !

a++

PS: je n'ai pas trop saisie la notion de Metadata, si quelqu'un pouvais expliquer ca vite fait... merci

[fredericL]

merci

et tu connaitrais pas un lien pour le JRE 1.5 (même beta) pour HP UX? si existe..... (pas certain)

[knotty]

Metadata, en 2 mots, ca te permet d'ajouter un tag a, par exemple, une methode.
Le but, c'est de permettre le developpement d'outils externes, qui feront tout un tas de choses.

Exemple concret, si tu connais EJB, tu sais que pour chaque classe d'implementation, il faut entre 2 et 4 interfaces, plus un descripteur.
La plupart des IDE facilite le travail, tous a leur sauce.
Il existe aussi xDoclet, qui te permet d'utiliser Javadoc pour generer les classes automatiquement.
Metadata, c'est un peu comme xDoclet, sauf que ca deviendra plus standard, et avec un peu de chance, tous les IDE utiliseront cette methode.
En l'occurrence, pour EJB, je parle vite, car une des idees, c'est de separer le code des descripteurs, et la tu ferais exactement l'inverse.

J'espere que c'est plus clair.

[adiGuba]

knotty : Merci de ses précisions...

[knotty]

Pour utiliser les nouveautées du langage, il faut utiliser l'option -source 1.5 comme Replouf66 l'a dit plus haut. Mais du coups nos .class ne peuvent être exécuté que par des MV 1.5 !!!
Pas de portabilité avec les MV précédentes si on utilise les nouveautées du language (dans un sens c'est normal)...

-target 1.4 jette une erreur.
Je ne vois pas pourquoi. Y a meme pas de nouveau mot clef. Si j'ai bien compris, les trucs genre:

Code :

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

1
2
 
 for(String str : words )

Sont transformes en Iterateur automatiquement, donc je ne vois pas le probleme de compatibilite. (idem pour le reste, ce ne sont que des problemes de compilation, pas de runtime)

Si qqun peut m'expliquer pourquoi on ne peut pas faire -target 1.4, je suis preneur.

Ou bien est-ce seulement pour la beta?
Ca m'ennuie, parce que vu que les 3/4 des app serveurs en sont encore a 1.3, y a le temps avant qu'on puisse utiliser les nouvelles fonctionalites de la 1.5

[knotty]

ok, je me reponds moi-meme,

c'est en gros dans la doc: (doh!!)

The -source 1.5 option is required for compiling with the new language features.
The -target 1.4 option is the default, which generates class files that are compatible with 1.4 or 1.5 VMs. A new option -target 1.5 is available for compatibility only with 1.5 VMs.

Ce qui veut dire qu'a priori, on peut faire marcher sur 1.4
(c'est juste -target 1.4 qui n'est pas supporte, curieusement)

Je verifie ca des que j'ai une machine avec 1.5.

[adiGuba]

Ce qui veut dire qu'a priori, on peut faire marcher sur 1.4
(c'est juste -target 1.4 qui n'est pas supporte, curieusement)

Je verifie ca des que j'ai une machine avec 1.5.

Avec le JDK 1.5, si je compile avec :

Code :

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

javac *.java

Il me fait un code compatible avec une JVM 1.4 (pas testé avec une JVM inférieure mais avec l'option -target il ne doit pas y avoir de problème)
Mais il ne me prend en compte aucune des nouveautées du language (erreur de compilation comme si je compilais avec un JDK 1.4)

Et lorsque on utilise -source 1.5 on ne peut pas modifier le target :

Code :

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

1
2
D:\Java>javac -source 1.5 -target 1.4 *.java
javac: source release 1.5 requires target release 1.5

Donc si on utilise les particularitées de Java 1.5 on est ensuite obligé d'utilisé une JVM 1.5...

Maintenant je ne sais pas si se sera la même chose avec la version finale...
Je vais jeter un oeil sur le site de sun...

[knotty]

compile comme ca:

Code :

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

1
2
3
4
5
6
7
8
 
 public class Essai {
 
  public static void main(String[] args) {
    Integer i = 42;
}
 
}

javac -source 1.5 Essai.java
Avec un javac 1.5

Ensuite, avec un java 1.4, essaie ca:
java Essai

Et ca devrait fonctionner. L'idee, c'est que 1.5 compile par defaut pour une target 1.4.
J'essaie ca ce soir, promis.

[adiGuba]

Et ca devrait fonctionner. L'idee, c'est que 1.5 compile par defaut pour une target 1.4.

Sauf si tu utilises -source 1.5...

J'ai compilé ton code, et ca donne :

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
28
29
30
D:\Java\knotty>javac Essai.java
Essai.java:4: incompatible types
found   : int
required: java.lang.Integer
                Integer i = 42;
                            ^
1 error
 
D:\Java\knotty>javac -source 1.5 Essai.java
 
D:\Java\knotty>java Essai
 
D:\Java\knotty>C:\j2sdk1.4.2_02\bin\java.exe Essai
Exception in thread "main" java.lang.UnsupportedClassVersionError: Essai (Unsupp
orted major.minor version 49.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12
3)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
 
D:\Java\knotty>

Quel que soit le code que tu compiles avec -source 1.5, le bytecode obtenu ne marche qu'avec la JVM 1.5

a++

[knotty]

http://forum.java.sun.com/thread.jsp...essage=1524991

Bon, apparemment, c'est mort.

Il semble que certaines personnes ait downloade des prototypes chez qui ca fonctionnait, mais pareil que toi, ca ne fonctionne pas pour moi.

C'est vraiment dommage. Pour certaines choses, on comprends, pour d'autres, vraiment pas.
En l'occurrence, j'ai regarde le bytecode de la classe ecrite plus haut:

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
 
import java.io.PrintStream;
 
public class G
{
 
    public G()
    {
    }
 
    public static void main(String args[])
    {
        Integer integer = Integer.valueOf(42);
    }
}

Faut me dire pourquoi ca ne pourrait pas tourner sous 1.4

C'est une grosse erreur de Sun, a mon avis, mais il ont le temps de changer d'avis.

[knotty]

ah oui, un vieux prototype sortait an utilisant -source 1.5 une major version = 48. (java 1.4)

Aujourd'hui, la version est 49, d'ou le UnsupportedVersionException.

J'essaie d'autres trucs ...

[knotty]

ok, pour le fun, voici la classe suivant, compilee avec -source 1.5

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
 
 
import java.util.ArrayList;
 
public class G {
 
    public static void main(String[] args) {
	Integer i = 42;
 
 
	ArrayList<String> liste = new ArrayList<String>() ;
	liste.add("Hello");
 
	printMe(liste);
 
 
    }
 
    public static void printMe(ArrayList<String> liste) {
	for(String s : liste) {
	    System.out.println(s);
	}
 
    }
 
 
}

Et voici son bytecode:

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
28
 
import java.io.PrintStream;
import java.util.ArrayList;
import java.util.Iterator;
 
public class G
{
 
    public G()
    {
    }
 
    public static void main(String args[])
    {
        Integer integer = Integer.valueOf(42);
        ArrayList arraylist = new ArrayList();
        arraylist.add("Hello");
        printMe(arraylist);
    }
 
    public static void printMe(ArrayList arraylist)
    {
        String s;
        for(Iterator iterator = arraylist.iterator(); iterator.hasNext(); System.out.println(s))
            s = (String)iterator.next();
 
    }
}

Remarque plusieurs choses:
- C'est 100% compatible 1.4.

- j'ai mis un Generics comme argument d'une fonction publique. Et c'est compile en ArrayList de base.

Probleme:
Appli 1) : je compile une lib ecrite avec des Generics.

Appli 2 utilise la lib de appli 1. Comment le compilateur peut-il verifier a la compilation que le type passe en argument est le bon?
Apparemment, pas possible. C'est bete, non?
Du coup, a quoi servent les Generics?

Si qqun peut m'expliquer...

[bulbo]

A mon avis il y a confusion, ce que tu nous montre ne ressemble absolument pas a du bytecode mais plutot a du bytecode qui aurait ete decompile ...

Question ton decompilateur supporte t'il la version 1.5 ?? Si non (ce qui est probablement le cas) il a surement ignore le generic et n'a montre que ce qu'il avait pu reconnaitre...

Enfin c'est ce que moi je crois ..

Bulbo

[adiGuba]

Salut

J'ai édité le .class et j'ai modifié le numero de version ( changer le premier 49 en 48 ) afin d'executer le code avec le 1.4.

Voilà ce que ca donne avec la JVM 1.4:
(Je parle bien entendu de code compilé avec -source 1.5 dont le numero de version du bytecode a été modifié puis qui a été executé sur une JVM 1.4)

• - Les Generics marchent.
  - Le for étendu marche.
  - L'import static marche.
  - Les Varargs marche mais il faut faire attention avec les types primaires à cause de l'autoboxing (cf plus bas)

Par contre :

• - L'autoboxing ne marche pas avec tous les types : il faut que la methode valueOf() avec le type primaire correspondant en paramètre existe dans l'API 1.4 (c'est le cas pour Boolean seulement je crois, pour les autres il y a seulement valueOf(String)).
  - Les Enumerations ne marche pas (ils implementent l'interface java.lang.Enum inexistante dans le 1.4)
  - L'operateur '+' entre des String a changé, avant il utilisait des StringBuffer mais dans le 1.5 il utilise des StringBuilder (+ rapide, ne gere pas la synchronization des threads).
  Du coup le code suivant plante :

  Code :

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

  System.out.println ( "valeur :" + 10);

  - System.out.printf() ne marche evidemment pas, tous comme les nouvelles methodes du 1.5...

Attention, il y a surement d'autres problèmes...
Ceci n'est qu'a but informatif je ne garantis rien...

a++

PS: si vous voulez le code je le posterais...

[Piolet]

Rien a voir avec tous vos tests, moultes et nombreux, mais moi par exemple je fais un chtit logiciel, pdt que je fais un peu de conception, je m'appercois de l'existence de la 1.5, content je deviens...alors je mets sur mon fixe la version beta de java 1.5....et je laisse sur mon portable une version de la 1.4 pour etre sure de garder une version stable...
bon bref je code mon ptit bonhomme de logiciel grace a la 1.5 (deja première deception, jikes OUT, peux plus compiler avec jikes et javac est tjs aussi lent... , pas grave jsuis au chomage jsuis pas pressé )
donc je code, disais-je (en 1.5 donc, sans utiliser toutes les dernières nouveautés, juste un code normal comme avec la 1.4) et pis hier j'exporte mon code vers mon portable (donc je m'adonne de nouveaux aux joies de jikes) mais HO stupeur plein d'erreur avec jikes (mais c normal, c d erreur dites "ambiguous" donc je rajoute qq this par ci par la et ca passe...et hop a l'execution ca passe plus...un NullPointerException qui m'pète a la gueule...
je regarde mon code, je me dis je suis ptet mauvais, c ptet pour ca que jsuis au chomage ...hein y a pas de raison...
Et donc la portion de code qui pète ressemble a ca :

Code :

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

1
2
3
4
5
6
7
8
 
_antecedentsTable = new JTable(synthesisTableModel) {
     public void valueChanged(ListSelectionEvent evt) {
          super.valueChanged(evt);
          _removeAntecedent.setEnabled(_antecedentsTable.getSelectedRow() != -1);
          _modifyAntecedent.setEnabled(_removeAntecedent.isEnabled());
     }
};

Précision, mes éléments _removeAntecedent et _modifyAntecedent (qui sont des JButton classique) ne sont pas encore instancier...
d'ou le nullPointerException, jusque la je suis OK avec la runtime 1.4
mais alors, et c la ma question, pkoi le 1.5 ne braille-t-il pas de la meme manière a l'execution et pourkoi me laisse-t-il faire un code aussi risqué , alors que le 1.4 m'averti bien gentillement...

voila bizarre ne trouvez vous point..???

et g testé en mettant entre commentaire c 2 satanés JButton dans le morceau de code ci-dessus et ca passe sur 1.4 comme sur 1.5...
enfin ca passe...la précision c que pour ca passe il faut je compile mon code sur mon fixe avec -target 1.4 que j'exporte mes class sur mon portable et que je lance direct avec java sans recompiler...sinon c la merde, y a aussi des erreurs d'appréciations avec les classes imbriquées du type :

Code :

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

1
2
3
4
5
6
7
 
public class Primaire {
  ..
 
  private class Secondaire {
  }
}

le private ne passe pas avec le compilo 1.4 mais passe avec le compilo 1.5 et l'option -target 1.4 ... enfin bref...on peut plus passer sereinement du VM a une autre meme si on ne se sert pas des nouveautés de la dernière...c dommage non?

[RanDomX]

c pe pour ca que c encore une beta....
Normalement il y a compatibilité ascendante... normalement.

@+

[Piolet]

normalement...
mais apres avoir mon posté mon message, g modifié un peu mon code, et force est de constater que ca peut marcher...il faut juste que je pense a tester en 1.4, car la 1.5 ne me dira rien...alors que la 1.4 braille pour un rien

[adiGuba]

c pe pour ca que c encore une beta....
Normalement il y a compatibilité ascendante... normalement.

@+

Oui mais pas descendante :

http://java.sun.com/j2se/1.5.0/compatibility.html[/url]]Functionality releases and major releases (such as 1.3.0, 1.4.0, 1.5.0) maintain upwards but not downwards source-compatibility.

Par contre est-ce qu'on pourra utiliser -source 1.5 et -target 1.4 dans la version finale ???

[knotty]

A mon avis il y a confusion, ce que tu nous montre ne ressemble absolument pas a du bytecode mais plutot a du bytecode qui aurait ete decompile ...

Question ton decompilateur supporte t'il la version 1.5 ?? Si non (ce qui est probablement le cas) il a surement ignore le generic et n'a montre que ce qu'il avait pu reconnaitre...

Enfin c'est ce que moi je crois ..

Bulbo

Y a du vrai, mais en fait si tu regardes le bytecode donne par javap, c'est la meme chose. Donc je pense que c'est simplement que dans la beta, javap n'a pas ete upgrade. Car en fait, le Generic devrait apparaitre dans la signature.

Et effectivement, il n'y aura compatibilite que dans un sens.

donc -source 1.5 -target 1.4 ne marchera pas, conformement a la version beta.
Il y a eu des versions beta anterieures, pour lesquelles cela fonctionnait. (ou du moins, -source 1.5 sortait major version = 48)

[MasterMic]

En gros, la 1.5 serait une avancé majeure comme nous l'avions eu entre java 1.1 et 1.2...

Bête question: nos codes sources 1.4 ils fonctionnent en 1.1? Pas sûr
Je crois qu'on s'y fera finalement mais c'est dommage que la compatibilité soit pas asuré à 100%

D'un autre côté c'est utopique de penser à une compatiblité à 100% permanente d'une version à l'autre. Déjà nous avons la chance d'avoir des warning "deprecated"... connais pas d'autres langages qui fait çà

Les autres ils disent simplement: "BUMP syntax error"

Et puis c'est une beta donc on peut rester confiant en Sun Microsystem qui s'est toujours soucié de ses communautés de développeurs , pour nous sortir un truc suffisamment compatible... allez, 99% et je râlerais pas