Discussion :

[Petrus]

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

Code :

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

1
2
Properties.loadFromXML( FileInputStream )
Properties.storeToXML( FileOutputStream, String )

http://java.sun.com/j2se/1.5.0/docs/...roperties.html

[thebubble]

Les propriété XML sont déjà dans jdk1.4 me semble t'il

[B@tman]

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%

La compatibilité ascendante doit toujours être assurée (aux deprecated près), mais pas descendante, c'est évidemment impossible.

[Petrus]

Les propriété XML sont déjà dans jdk1.4 me semble t'il

http://java.sun.com/j2se/1.4.2/docs/api/index.html

Je vois pas en tout cas :

[RanDomX]

Ca ressemble à l'intégration de JAXB ca ???
c'est le cas ?

[thebubble]

Petrus : Je vois pas en tout cas

ici

[iceman]

La notation utilisée pour les generics ne risque-t'elle pas de poser problème avec les notations JSP ('<', '>') ? :

[divxdede]

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...

[grishka]

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.

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.

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.

[adiGuba]

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.

En tout cas ce n'est pas encore le cas dans la version beta d'où le message de knotty...
L'utilisation des nouveauté de java 1.5 impliquait le -target 1.5

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.

Sauf en cas de compilation avec -target 1.5, dans ce cas des optimisations peuvent être effectué.
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) :

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.

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...

a++

[staul]

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) ;-)

[adiGuba]

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à.

Pour le ping() on peut utiliser la nouvelle méthode isReachable() de InetAddress mais il n'utilise pas forcement ICMP :

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.

a++

[edit] La balise [ url ] n'était pas bien fermé...

[staul]

en effet ces méthodes semblent assez interessantes, merci bien.

[fdouilly]

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.

[fdouilly]

Pour les outils de ping tu peux voir les API Commons de jakarta.

[Mister Nono]

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.

[adiGuba]

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...

[manusweb]

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 !!!!!

[xhonnor]

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 !!

[Twofy]

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! )