Version imprimable
Remarquons également la nouvelle implémentation des fichiers propriétés, qui permet, au lieu de stocker les fichier dans un *.prop à la façon *.ini, de stocker dans un fichier XML.
Le moyen sera certes un moins léger en mémoire que l'ancien système, mais trés pratique.
A voir donc les méthodes
http://java.sun.com/j2se/1.5.0/docs/...roperties.htmlCode:
2
Les propriété XML sont déjà dans jdk1.4 me semble t'il
La compatibilité ascendante doit toujours être assurée (aux deprecated près), mais pas descendante, c'est évidemment impossible.Citation:
Envoyé par MasterMic
http://java.sun.com/j2se/1.4.2/docs/api/index.htmlCitation:
Envoyé par thebubble
Je vois pas en tout cas :?:
Ca ressemble à l'intégration de JAXB ca ???
c'est le cas ?
iciCitation:
Petrus : Je vois pas en tout cas
La notation utilisée pour les generics ne risque-t'elle pas de poser problème avec les notations JSP ('<', '>') ? :?:
bien bien bien,
La genericitée : Quelle bonne nouvelle, ca va etre genial :-D pour pouvoir implementer des Pools d'objets etc...
Les enums : Ouais, pourquoi pas, ce n'est pas une avancé majeur d'aprés moi
Les iterators implicite dans les for : Ca peut être cool, mais certains comprendrons encore moins comments les choses fonctionnent en interne
Les metas data : Ca c'est excellent, mais faut attendre de voir comment c'est utilisablent en pratique.
La surcharge des operateurs : Snif, J'aimerais tellement que Java puisse supporter la surcharge des operateurs !!! snif snif et re-snif
PS: certain ont fait des tests de performance entre 1.4 et 1.5 ?
Bien, Wait & See...
D'après les spécification du jdk 1.5, le bytecode généré doit aussi être exécutable par une jvm <1.5. Ainsi par exemple la généricité est elle remplacée à la compilation par du code compatible jvm <1.5. Cette technique est appelée Type Erasure.Citation:
Envoyé par knotty
Autres Conséquences : vu qu'il il n'y a aucune différence dans le bytecode, il ne faut pas s'attendre à une quelconque optimisation de performance (les casts sont effectués, les types primitifs convertis en wrap objects,etc... comme l'aurait fait le développeur en 1.4...). L'avantage réside dans l' amélioration de la qualité du code.
En tout cas ce n'est pas encore le cas dans la version beta d'où le message de knotty...Citation:
Envoyé par Grégory Picavet
L'utilisation des nouveauté de java 1.5 impliquait le -target 1.5
Sauf en cas de compilation avec -target 1.5, dans ce cas des optimisations peuvent être effectué.Citation:
Envoyé par Grégory Picavet
Par exemple, dans la beta les concaténations de String était géré grâce à la classe StringBuilder (au lieu de StringBuffer) optimisé car elle ne gère pas la synchronization.
De même, pour la convertion des type primitifs des méthodes optimisé ont été crées :
Par exemple c'est Double.valueOf(double) qui apparemment est plus optimizé que le constructeur Double(double) :
Donc le code restera compatible et les optimizations ne seront vraisemblablement possible que pour du code destiné au VM 1.5 ou supérieur seulement...Citation:
Returns a Double instance representing the specified double value. If a new Double instance is not required, this method should generally be used in preference to the constructor Double(double), as this method is likely to yield significantly better space and time performance by caching frequently requested values.
a++
Je change un peu le sujet mais vous avez des nouvelles de l'intégration du ping ou des socket raw aux api java ? Moi j'ai rien vu passer de ce côté là.
ps : si c'est pas le cas va falloir changer la faq pour le ping parce que la date de péremption arive (version 1.5) ;-)
Pour le ping() on peut utiliser la nouvelle méthode isReachable() de InetAddress mais il n'utilise pas forcement ICMP :Citation:
Envoyé par staul
a++Citation:
A typical implementation will use ICMP ECHO REQUESTs if the privilege can be obtained, otherwise it will try to establish a TCP connection on port 7 (Echo) of the destination host.
[edit] La balise [ url ] n'était pas bien fermé...
en effet ces méthodes semblent assez interessantes, merci bien.
J'ai hate de voir également toute la partie monitoring d'application, les beans qui permettent de jeter un coup d'oeil à la mémoire, au GC, etc....
A voir également la réaction des outils de monitoring.
Pour les outils de ping tu peux voir les API Commons de jakarta.
Je suis très content du java actuel : je travaille en tant que professionnel et franchement les templates du type C++, je n'en ai jamais eu besoin.
Ce n'est pas ce genre de nouveauté qui me fera apprécier la nouvelle version de java.
Cela permet pourtant de sécuriser le code en déplaçant à la compilation des erreurs qui pouvaient survenir à l'exécution...Citation:
Envoyé par Mister Nono
Hello tout le monde ....
Et pour les perfs ??? ça donne quoi ? on va gagner en rapidité ou pas ? on va gagner en occupation mémoire ?
ça, ça me parait le plus important !!!!!
Essayez la beta 2 ..
Pour les perfs, le demarrage des applis est quasi immediat maintenant ...
Les swing tres lourds et les grosses applis sont tres nettement acceleres ..
De plus le look natif des swings est aussi beaucoup plus joli et agreable à la vue ..
Les jar sont nettement plus compacts, mes applets sont beaucoup plus rapides ..
Bref que du bon !!
L'ideal, certains comme moi le demande, serait que Sun nettoie ses API Java, pour en diminuer le nombre de classe, eliminer les redondances dues à l'accumulation des versions ( par exemple simplifier la double existence de swing et de awt, la classe Vector devrait disparaitre etc ... ) .. Bon d'accord, il n'y aurait plus de compatibilité avec les anciennes versions, mais cela serait tellement plus propre !!
Ca signifirait un fork, et maintenir deux branches renderait les choix de développement hasardeux pour les entreprises. Or, nous le savons tous, ce qui fait le succès de Java c'est bien son utilisation en entreprise, pas les développeur du dimanche.
Les responsables de veilles techno n'auront pas envie de se prendre la tête à faire le pour et le contre d'une branche épurée pour la performance ou d'une branche lourde pour la compatibilité ascendante. Ils auront encore moins envie de réécrire des bouts de codes qui fonctionnent depuis Java1, du coup, l'élagage ferme en coupant directement d'une version à une autre ne me semble pas envisageable pour Sun.
(ce n'est que mon avis! ;) )
hello :lol: ,
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... :cry:
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)
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 ?
pour ma part, j'ai essayé d'utiliser la méthode enum, mais sans succès... pour l'instant...
TheSeb , va lire l'article sur mon domaine.
C'est un apercu général des nouveautés.
@+
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?Citation:
Envoyé par Bicnic
:roll:
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+
Et bien moi je dis PAS CONTENT :evil:
enum, j' utilisais ca un peu partout dans mes progs arrrrggggg !!!!
Première surprise, ensuite ça :
Qqn sait me dire d'où ça vient ?Code:
2
3
4
5
6
7
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
Si quelqu'un à la solution je suis preneur aussi... :evil:Code:
2
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.
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 ! :-)
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.
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...
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 :wink:
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.
:cry: :pleure: :( :ouin:
James
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 :
:arf:
Ma seconde impression :
:aie: 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. :ccool:
Seulement, j'ai un truc à dire sur la nouvelle synthaxe :furieux: si vous voyez ce que je veux dire...
:zekill: NOUVELLE SYNTHAXE TIGER
:lahola:
Quelques remarques sur la synthaxe 1.5 : :vomi:
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... :sm:
} "
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. :merci: d'avoir perdu votre temps jusqu'ici.
:salut:
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.
:salut: 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 :roll:
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 : 8O :? :x :furax: :furieux: :evilred:
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. :scarymov:
Bravo... Pour contrer le conceptuellement très merdique, ils inventent des synthaxes spéciales merdiques mais pas trop, juste ce qu'il faut. :nono:
"import static javax.swing.*" :chin: "include <javax.swing.*>"
De mon point de vue de mec négatif :twisted: , 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 :calin: le plus de développeurs possibles :love: des langages moribonds :aie: C et C++, afin que ceux-là ne se tournent pas naturellement :love2: vers du C# . Stratégie quand tu nous tiens ... :twisted:
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 :cfou:, enfin je me comprends... :fou:
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 :mouarf2: PAS CONTENT NOUVELLE SYNTHAXE JDK 1.5
Moi :mouarf2: vouloir JVM rapide très rapide :merci: et APIs puissantes :merci: pas synthaxe changeante :alerte:
:salut:
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 ?).