Discussion :

[Pill_S]

hello ,

est-ce que l'un d'entre vous à une idée concernant la date de sortie du
JDK 1.5 final ? parce que bon, à l'origine c'était prévu pour fin 2003... Et
maintenant on est en août 2004 et moi je n'ai toujours qu'une
beta...

[lunatix]

roooooooooo depuis aujourd'hui tu as une release candidate http://java.sun.com/j2se/1.5.0/download.jsp et la date voulue est le 30 septembre (sauf bug majeur qui retarderait la sortie)

[TheSeb]

Je voudrais savoir : dans la version 1.4 il y a eu un nouveau mot clé : assert
Dans la version 1.5, qu'est ce qu'il y a come nouveau mots clés ?
enum ?

[Bison_Ravi_33]

pour ma part, j'ai essayé d'utiliser la méthode enum, mais sans succès... pour l'instant...

[RanDomX]

TheSeb , va lire l'article sur mon domaine.

C'est un apercu général des nouveautés.

@+

[Bicnic]

La Release 1.5 est enfin disponible !!

[Glob]

La Release 1.5 est enfin disponible !!

Retour(s) d'expérience? Comment ça tourne? Gros bugs? Compatibilités jvm et classes compilées 1.4 <-> 1.5?

[Kangourou]

salut,

j'ai pu faire tourner sans probleme des anciens progs,

mais j'ai eu qlq soucis avec JUnit (la version 3.8) sous Eclipse.
je suis revenu en 1.4, mais des que je suis a jour je repasse a la 5.0, les ouveautes m'ont l'air bien pratiques.

A+

[VincenzoR]

Et bien moi je dis PAS CONTENT

enum, j' utilisais ca un peu partout dans mes progs arrrrggggg !!!!

Première surprise, ensuite ça :

Code :

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

1
2
3
4
5
6
7
Uncaught error fetching image:
java.lang.NullPointerException
	at sun.awt.image.URLImageSource.getConnection(URLImageSource.java:97)
	at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:106)
	at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:240)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)

Qqn sait me dire d'où ça vient ?

[c-top]

J'ai eu exactement le même erreur avec une image contenue dans un jar executable. Avec la 1.4 tout fonctionnait très bien avec la 1.5

Code :

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

1
2
 
fetching blablabla

Si quelqu'un à la solution je suis preneur aussi...

[Katyucha]

J'ai developper avec les Swings une petite appli de 1 kiloLignes pour un utilisateur interne a mon service

L'appli n'est pas lente du tout. Je la passe en 1.5 et je vous avoue qu'a chaque bouton de pressé... y a un temps de latence.. Ca ne gene pas l'utilisateur...par contre j'ai peur pour mes autres programmes....

Donc pour l'instant, je suis déçu.

[rozwel]

Personnellement je suis en train de migrer un projet assez conséquent (dans les 32Klignes) pour utiliser les joyeusetés du Tigre et je dois avouer qu'on y gagne vraiment en lisibilité et en maintenabilité. Pour l'efficacité je sais pas et si vraiment c'est un problème ça va pas le rester longtemps connaissant Sun.
Il y aura forcément un temps d'inertie, de rodage, mais perso je pense que c'est vraiment un investissement sur le long terme que de migrer tout de suite un projet qui démarre à peine.
En tout cas moi je dis chapeau bas à Sun qui à mon avis fait preuve d'une stratégie de développement tout à fait remarquable sur Java (spéciale dédicace à James GOSLING, mon idole ! :-)

[Katyucha]

Après divers tests, je me suis apercu que le gros du ralentissement vient du chargement des drivers JDBC Informix ....
Sinon, je suis plus déçu.

[rozwel]

Je crois que c'est ça le plus gros problème en fait avec cette nouvelle version. Ils ont tellement fait évoluer les choses qu'ils ont un peu sacrifié la compatibilité ascendante (et je ne les en blame pas loin de là). Du coup, pas mal d'outils qui tournaient très bien avec la 1.4, montrent des signes de fatigue avec Tiger.

Moi j'ai des problèmes avec ant qui ne reconnait plus certaines taches optionnelles, avec JavaNCSS qui plante tout simplement, quant à IzPack il me fait des choses... étranges. Mais ce n'est pas grave. Encore une fois je suis persuadé que ça vaut le coup d'adapter... pour un projet qui n'a pas de contraintes financières et temporelles surtout. Parce que pour les autres, c'est dommage que Sun n'ait pas un petit peu mieux géré la sortie groupée en insistant sur la communication avec les développeurs d'outils pour Java.

M'enfin ça viendra...

[Righetto Dominique]

Slt,
Je viens de tester NetBean 4.0 avec le JDK 1.5 en mettant en place une simple appli web avec Struts, pas moyen de la faire marcher, il m'indique à chaque fois que la classe Converter de commons-beanutils.jar est introuvable alors que :
1. Cela marche en 1.4 avec la même configuration Struts (Jar + tld)
2. Je ne vois nulle par cette classe Converter ?

Donc je cherche encore....

@+

Dom

[James85]

Marre

J'étais en train de porter une applet compatible JRE 1.1 vers 1.4 et ses Swing.

Je viens d'installer la MV 1.5. Resultat : L'ancienne applet bug là ou tout larchait avant, et la nouvelle plante carrément le navigateur et la console JAVA lorsque je recharge la page contenant l'applet. Et durant le peu de temps où elle marche elle met quatre fois plus de temps à se lancer, et elle est plus lente.

J'espère que chez SUN ils ne sont pas partis au Ski !

Deçu.



James

[Pierrot Le Ouf]

JDK 1.5, la mort du Tigre !!!

J'avoue directement, je n'ai encore rien compilé en "Tiger", cependant j'ai matté les changements synthaxiques et les packages du JDK 1.5.

Ma première impression :


Ma seconde impression :
Heureusement qu'on a évité le "define", le "struct", la classe Stdio_h, String_h, Windows_h... Il faut bien en garder pour la 1.6.
Il faut seulement se contenter de "printf", "enum", "class SuperGeneric < T <E, F> extends G <H>, F extends H < I extends J, K < E> > >" ...

Bon voyons ce que MOI, je souhaite dans une nouvelle version d'un JDK :
1) une JVM toujours plus rapide (heureusement, c'est normalement le cas de la 1.5) pour permettre aux applications java de s'imposer dans tous les domaines.
2) un enrichissement des APIs standards (c'est encore le cas pour la 1.5)

Donc après ce bref passage, on pourrait penser que je suis content du nouveau JDK.

Seulement, j'ai un truc à dire sur la nouvelle synthaxe si vous voyez ce que je veux dire...

NOUVELLE SYNTHAXE TIGER



Quelques remarques sur la synthaxe 1.5 :


A) Dans la série, je fais du C en java :

La plupart des javaistes viennent du première expérience en C ou C++, domaines dans lesquelles la culture procédurale est forte. Une des forces majeures de Java, c'est les valeurs Objets de ses développeurs.
Hors il n'est pas souhaitable à mon goût d'ouvrir des "bastions" procéduraux aux nouveaux arrivants dans le Java car ça les confortera dans leurs habitudes non Objets au lieu de les pousser vers une réflexion sur comment développer plus Objet.
Moi-même (je sais que c'est pas une référence...), mes premiers programmes java ressemblaient à du C... Et je pense que certaines évolutions du 1.5 ne peuvent que retarder les gens à faire du java qui ressemble à du java.

Exemples des nouveautés de la série :
-/*@deprecated since FORTRAN*/
Le "static import", on peut se demander si ils ont pas hésité un instant à changer le "import java.lang" en "include<C.java.lang.h>"... passons... Le "static import" permet la collision dans tous les sens des constantes et méthodes statiques ... Génial ... Mais mieux encore ça permet de manipuler les membres statiques des classes comme si ils n'étaient pas encapsulés... Mais à quoi ça sert l'encapsulation? A rien ! Si ce n'est à faire de la programmation objet (/*deprecated since JDK1.5*/) ...

- /* @deprecated since C*/
Le "printf", c'est pas dramatique mais c'est mauvais signe de faire son premier programme "Hello World" en java avec la même fonction que son premier programme C.

- /*@deprecated since C++*/
Le "enum", mouais... ça sert juste à faire la même chose qu'une autre chose qui existe déjà... Ainsi y'aura ceux qui font du "enum" et ceux qui la font à l'ancienne (en java quoi)... Vive l'homogénéité du code!

Pour finir mes commentaires sur la série "je fais du C en java", il ne faut pas que les concepteurs du JDK 1.5 oublient que le Java ne fera jamais aussi bien du C que le C ou le C++. Alors c'est pas la peine d'essayer de se rapprocher du C ! D'autant plus que c'est pas la tendance, Microsoft l'a bien compris en rapprochant C et C++ du Java (et non le contraire!) en créant ses C# et J#.

B) Dans la série, parce que j'ai rien à dire :

-// Level.INFO
Passer de "for( ; ; )" à "for( : )" et "for( ; ; )" ... mouais, deux choses pour à peu près la même chose... D'ailleurs "for( : )" me fait plus penser à "while( )" que "for( ; ; )"...

-// Level.WARNING
L' "autoboxing/unboxing", sympathique à première vue car ça réduit le volume du code. Cependant pour les applications "Full Java" qui moulinent des gros tas de Mo de types primitifs et qui souhaitent des temps d'exécution véloces, il y a un petit danger à masquer automatiquement aux développeurs les instanciations et utilisations des "Wrappers" associés aux types primitifs... Effectivement, mon point de vue est extrémiste mais enfin je me nomme pas "Pierrot Le Ouf" pour rien...


C) Dans la série "plus générique que moi tu meurs" :

- Les arguments variables, le super "public void fonction(int ... valeurs){ }"

Le truc, c'est que certains vont être tenter de remplacer un ensemble de méthodes :
"public void fonction(){ }
public void fonction(int param){ }
public void fonction(int param1, int param2){ }
public void fonction(int[] valeurs){ }"
par la méthode "super générique" :
"public void fonction(int ... valeurs){ }"
Et cela qu'il y ait un intérêt ou non (et d'ailleurs cela sera très souvent mauvais...).

Ensuite question à deux centimes :

public class NewSynthax
{
public static void fonction(int param1, int param2){ }
public static void fonction(int ... valeurs){ }
}

NewSynthax.fonction( 1, 2 ); // De quelle méthode parle-t-on?

- Les generics

Les generics par l'exemple :
"import pierrot_est_ouf.generic_de_mdr.*;
import pierrot_est_ouf.monnaie.*;
import pierrot_est_ouf.monnaie.devalue.*;
import pierrot_est_ouf.interface.*;
import pierrot_est_ouf.inteface.jdk.*;

public class ValeurGeneric< ? extends Generic<Deux, Centimes, Euros>>
extends MonnaieDeSinge<Rouble, Franc>
implements InterfSample<Change, FromJDK_1_5, ToJDK_1_4_2>
{
// Je vous passe l'implémentation de la classe...
} "

L'exemple reste simple car j'aurais pu composé la classe ValeurGeneric avec des classes elle-même "<generic>" et là ça aurait commencé à être lourd...

C'est pas que je suis contre des "ArrayList<String> list;" qui ne tolère à la compilation que des String pour l'ajout par exemple... Mais à mon avis en ce qui concerne les déclarations de classe ou interface "generic" (parameterized type), ça va :
- créer de la divergence dans les styles de programmation java, d'où une baisse de la compréhension entre développeurs
- rendre le développement java moins "tout public", certes ça va attirer des matheux en mal de programmation fonctionnelle et déclarative s'extasiant devant les qualités formelles de leurs déclarations de types (de classe, pardon...) cependant les nouvelles complexités "generic" risquent de durcir le premier contact entre java et le futur développeur, celui-ci risque donc de consacrer ses premiers "amours" de programmation à autres choses que du java et de garder ses préférences un bon moment d'où à terme une perte de vitalité de la communauté des développeurs java.

Donc pour résumer mon point de vue, MORT à la nouvelle synthaxe du Tigre de papier.

Bon, c'est pas tout ça de critiquer mais il va peut être falloir que je compile quelque chose avec mon nouveau 1.5. d'avoir perdu votre temps jusqu'ici.

[lunatix]

je comprends bien ton point de vue, mais je vois ca differement !

le printf : pratique je trouve les sorties formatés... mais en meme temps, dès que on fait un peu de java, on utilise common-loggin ou log4j direct. c'est un plus qui ne sert pas a grand chose quand meme.

l'autoboxing : les IDE vont (eclipse commence) a marquer les boxings cachés afin de prevenir les problemes de perfs. Et par contre, ca permet quand meme de simplifier l'ecriture du code.

Enum, plutot bien, ca va permetre de faire la meme chose qu'avant, en type Safe. une bonne avancée

le import static : oui, alors la va pas falloir faire n'importe quoi. Mon avis perso, a part import static system et Math... faut pas trop toucher.

les generics : je me demande quel serra leur niveau d'utilsation dans 2ans, je ne suis pas sur que cela va etre un truc super utlisé en fait.

[Pierrot Le Ouf]

Lunatix

Je continue mes explications sur ma position en reprenant sur ce dont tu parles : "printf", "autoboxing", "Enum", "static import" et les "generic". Je vais les traiter dans l'ordre car celui-ci exprime grosso modo l'ordre croissant de la sévérité de mes jugements.

A) Les choses insignifiantes

1) "printf"
En fait, l'ajout d'une méthode, je m'en tape... C'est juste le symbole du "printf", la fonction mythique C par excellence qui m'interloque. D'ailleurs, si la méthode "printf" de java avait eu un autre nom mais avec les mêmes fonctionnalités, je n'aurais rien eu à dire. Cependant cette méthode C mythique apparaît comme par hasard dans la même version qu'un autre ensemble de nouveautés amenant une "C"isation de Java à savoir le "enum" et le "static import".

2) "autoboxing"
Si les nouveaux IDEs prennent en charge l'expression explicite le "autoboxing" alors no problem, car effectivement dans le cas général l'"autoboxing" est plutôt pratique.

B) Les choses que je juge sévèrement :

1) "enum"
Si le "enum" répond bien à une forme concise de programmation, ce qui me trouble, c'est la réintroduction dans la synthaxe Java d'un des ancêtres incomplets de l'Objet. Je trouve que c'est une régression malsaine au sein du Java qui est purement Objet.
J'aurai souhaité que le comportement "enum" soit réalisé par héritage explicite par exemple de classe la "Enum" mais non par un mot clé qui génère implicitement des classes "Enum" en ayant des airs explicites de type "ni-classe, ni-primitif".

2) "static import"
Selon une documentation Sun, il paraît que ça sert à corriger certains qui pourrissent leurs codes en faisant du "Constant Interface Antipattern", cependant la doc conclut que le "static import" est lui-même franchement merdique.
Bravo... Pour contrer le conceptuellement très merdique, ils inventent des synthaxes spéciales merdiques mais pas trop, juste ce qu'il faut.
"import static javax.swing.*" "include <javax.swing.*>"

De mon point de vue de mec négatif , les nouveautés qui mènent à la "C"isation du Java n'ont pas d'intérêt au niveau du langage mais plutôt des désavantages, par contre je les soupçonne d'avoir pour but de draguer le plus de développeurs possibles des langages moribonds C et C++, afin que ceux-là ne se tournent pas naturellement vers du C# . Stratégie quand tu nous tiens ...

3) "generic"
Pour les "generics", le problème est d'une autre nature car justement, il n'y a pas vraiment de problème 8) , c'est là que c'est vicieux et perfide , enfin je me comprends...

Un peu plus sérieusement, les "generics" ouvrent de larges horizons à une programmation formelle et extensible mais pour une version de java commune au maximum de domaines ça risque d'être un peu trop pointu. Quand je parle de pointu, je ne parle évidemment pas du <typage basique> des "collection" pour éviter les erreurs de cast à l'exécution (l'arbre qui cache la forêt) mais de la multiplication des "MyClass<E extends Container, F extends Component, G < F, String, Component, ? >>" qui pourront se retrouver dans les déclarations :
-des classes
-des arguments et valeurs de retour des méthodes
-...

Certes, la semaine prochaine, les "MyClass" n'érigeront pas de barricades dans Paris mais dans deux ans beaucoup de développements auront mis leurs touches de "MyClass" et ça risque de réduire l'attractivité pour les entrants dans le domaine Java. Il ne faut pas oublier, je pense, que si Java a du succès c'est parce qu'il est objet, multi-plateforme mais aussi SIMPLE...

Pour résumer pour la millième fois :
MOI PAS CONTENT NOUVELLE SYNTHAXE JDK 1.5

Moi vouloir JVM rapide très rapide et APIs puissantes pas synthaxe changeante

[remika]

Je suis assez d'accord sur le fait qu'avec les generics la syntaxe risque de paraître compliquée, mais pour les programmeurs Java confirmés, les casts à tout bout de champ ça devient vite pénible.
Justement, si ça continue, les nouveaux entrants ne sauront même pas ce qu'est un cast...
A part ça la boucle for simplifiée elle est bien pratique...
Les imports statiques c'est plus dangereux qu'autre chose à part si on préfixe ses noms de variables, ce qui revient presque au même du point de vue syntaxe (RMK_cste vs RMK.cste ?).