Que pensez-vous des nouveautés de Java 7 ? Qu'auriez-vous aimé de plus ?
Le 2006-05-29 13:30:16, par Baptiste Wicht, Expert éminent sénior
Bonjour,
Ce débat est destiné à parler des nouveautés du JDK 7 (pas seulement le projet Coin).
Qu'en pensez-vous ?
Qu'auriez-vous aimé d'autre dans cette nouvelle version de Java ?
Qu'aimeriez-vous voir dans les futures version de Java ?
Ce débat est destiné à parler des nouveautés du JDK 7 (pas seulement le projet Coin).
Qu'en pensez-vous ?
Qu'auriez-vous aimé d'autre dans cette nouvelle version de Java ?
Qu'aimeriez-vous voir dans les futures version de Java ?
-
UtherExpert éminent séniorCet article ne couvre que le projet Coin. Tout ceci ne correspond pas a des évolution du langage même mais a des évolutions de la JVM ou de ses API, ce qui ne concerne pas le projet Coin.
Pour ce qui est du listener en réponse au kill, ca existe déjà.-a quand un delete possible (comme pour flash), on pourrai enfin avoir un code java reproductible en temps ?
L'idée peu paraitre intéressante pour certain cas particulier. Mais pour le coup ca deviens dangereux car sa casserait un principe fondamental en java : toute référence a un objet est toujours valide.
L'impact de ce genre de chose me parait énorme et ca pourrait potentiellement entrainer beaucoup de problèmes.-pourquoi une méthode/champs protected est toujours en visibilité pacquet ?-pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
-pouvoir compiler une chaîne de caractère autrement que ""+""+"". Impec pour des requêtes SQL, l'écriture XML ou d'un code assembleur/C pour un shader.-a qd un preprocesseur en standard javac ?
Par curiosité, pour quel genre de chose aurait tu besoin de ça.le 04/09/2009 à 15:50 -
r1-1024Membre du ClubSi tu change ça, tu pete toutes les applications existantes qui supposent qu'un champ protected doit etre accessible aussi depuis le paquet. On pourrait ajouter un nouveau mot clé, mais chez sun ils aiment pas ajouter de nouveaux mots clés . Puis comme on l'a dit, ca changerais le bytecode et c'était visiblement pas le but
C vrai que l'incompatibilité serait génante.Tu veux dire la sortir de sa parent class pour la stocker dans un .java indépendant?Au choix tu a stringbuilder, stringbuffer, stringformat
Code : 1
2
3var monXML:XML = new XML (); monXML = <balise><test/></balise>;
mais plus générique du type
Code : 1
2
3
4StringBuilder ou String s={mon texte de n'importe quoi encodé dans l'encodage du source java qui prend donc pas trop de place mais qui est très pratique pour faire des requête au xml ou ... maintenable}
Il me semble que, sous unix, par exemple, il est impossible de renommer une application une fois lancée, que ce soit en java ou autre
Et puis je pense que ça peut poser des problèmes avec jconsole (mais la je m'avance).
C qd même pas la mort de permettre ça. Ils en ont bien conscience car la majorité des IDE font un lanceur home made.shutdownHooksJe peux comprendre que ca permet de contourner le problème des zozos qui font du catch(Throwable), mais le problème de base là, c'est le mauvais codage dans l'appli en question, pas le role du copilateur de tourner autour de ces erreurs. De plus on peux envisager des cas ou ce catch est légitime (bien que limite). Tu lancer un calcul gourmand mais rapide, tu catch le OutOfMemory et en cas de déclenchement tu calcul autrement avec moins de mémoire.
Par ex :
Un plugin déclare une vue (une JTable par ex). Après passage d'un algo, le coeur de l'appli gère les mises à jours. Et là le plugin se viande et une belle NullPointer revient dans le coeur. Là il est indispensable de faire un truc du genre :Code : 1
2
3
4
5
6
7
8
9
10
11
12
13for(View view:Views) { try { view.update(); } catch(Throwable t) { //on fait un truc en conséquence } }
Si le security manager pouvait aussi gérer les catch ...Je vois bien l'idée mais ca poserais en pratique d'énorme soucis en raison du principe de délagation des classloader (va-t-en savoir qui doit être le propriétaire de la String machin qu'on viens de créer). A la rigeur une zone mémoire par threadgroup ce serait peut être gérable (et encore)
Nouvel argument à new alors.le 04/09/2009 à 16:41 -
r1-1024Membre du ClubTu voudrais un delete à la C++ qui détruirait immédiatement l'objet sans passer par le garbage collector?
L'idée peu paraitre intéressante pour certain cas particulier. Mais pour le coup ca deviens dangereux car sa casserait un principe fondamental en java : toute référence a un objet est toujours valide.
L'impact de ce genre de chose me parait énorme et ca pourrait potentiellement entrainer beaucoup de problèmes.Code : 1
2
3
4
5
6
7delete obj; //serait équivalent à obj=null; System.gc(); //si System.gc() était déterministe //ici rien ne garanti que notre objet soit effacé
Jamais je l'espère. Java s'en passe très bien pour le moment et si tu en a besoin pour un usage très particulier, rien ne t'empêches d'en utiliser un.
Par curiosité, pour quel genre de chose aurait tu besoin de ça.
Mais son utilisation intelligente est à benir.
C'est en regardant le source de GIMP (je crois que c gimp) que j'me suis souvenu du preprocessor et de sa puissance.
Bien souvent les IDE proposent de générer du code automatiquement, qu'il faut reprendre généralement. Une macro permet de faire la même chose en mieux.
Ca permet de façon très concise d'avoir un résultat équivalent qu'à du xml qui passe dans du xsl pour faire du java et un autre source java car le xml ne suffit jamais en soi.le 04/09/2009 à 17:05 -
adiGubaExpert éminent séniorProblème #1 : System.gc() est super lourd et doit être évité !
Problème #2 : ce n'est pas parce que tu mets une référence à null que l'objet correspondant peut être libéré.
Problème #3 : si tu veux un comportement déterministe il faut revoir complètement la gestion de la mémoire, afin qu'une référence que tu "supprimes" avec delete ne soit pas partagé... sinon on va se retrouver avec des références invalides ce qui est une abbération en Java
Tout cela pour pas grand chose en fait...
a++le 04/09/2009 à 17:24 -
tchize_Expert éminent séniorSi tu change ça, tu pete toutes les applications existantes qui supposent qu'un champ protected doit etre accessible aussi depuis le paquet. On pourrait ajouter un nouveau mot clé, mais chez sun ils aiment pas ajouter de nouveaux mots clés
. Puis comme on l'a dit, ca changerais le bytecode et c'était visiblement pas le but
-pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
-pouvoir compiler une chaîne de caractère autrement que ""+""+"". Impec pour des requêtes SQL, l'écriture XML ou d'un code assembleur/C pour un shader.
-possibilité de renommer java.exe et de le sortir de java/bin (impec pour le déploiement et le kill d'une appli java)
-Pouvoir ajouter des listeners en réponse au kill pour libérer des ressources par ex.
- Avoir des exceptions qui ne puissent être rattrapées que par certaine classe.
(par ex le OutOfMemory ne devrait pas être rattrapable par n'importe qui).
- Pouvoir faire un pull de mémoire configurable par classloader.
le 04/09/2009 à 15:36 -
r1-1024Membre du ClubL'invocation dynamique c'est le seul truc que je retiendrai. Pour le reste, une bonne completion / indentation fait l'affaire.
Par contre j'aurai aimé qu'ils se penchent sur des points importants :
-accélérer les fonctions trigos qui sont 10 fois plus lentes qu'en C (donc toujours pas de code de calcul en java : vive la fft et le traitement de signal)
-a quand un delete possible (comme pour flash), on pourrai enfin avoir un code java reproductible en temps ?
-intégrer jogl en standard et porter swing en jogl. Sun s'offrirerai enfin le luxe de couper l'herbe sous le pied à Adobe à propos de la 3D native (qu'ils sont visiblement pas près d'avoir).
-accélérer le temps de chargement des applets javafx pour faire enfin décoller ce petit bijoux.
-pourquoi une méthode/champs protected est toujours en visibilité pacquet ?
-pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
-pouvoir compiler une chaîne de caractère autrement que ""+""+"". Impec pour des requêtes SQL, l'écriture XML ou d'un code assembleur/C pour un shader.
-a qd un preprocesseur en standard javac ?
Des moins importants :
-corriger l'implémentation douteuse des JDialog et les weakreference de leurs enfants (ça c très merdique et très décevant de la part de Sun).
-configuration automatique possible du garbage collector (xmx dépend de la machine cible)
-possibilité de renommer java.exe et de le sortir de java/bin (impec pour le déploiement et le kill d'une appli java)
-Pouvoir ajouter des listeners en réponse au kill pour libérer des ressources par ex.
-Il était question d'extraire le window manager de netbean et de le mettre en std !
Et un truc qui serai franchement top :
- Avoir des exceptions qui ne puissent être rattrapées que par certaine classe.
(par ex le OutOfMemory ne devrait pas être rattrapable par n'importe qui).
- Pouvoir faire un pull de mémoire configurable par classloader.
Avec ces deux trucs (et le SécurityManager) , une appli à plugin pourrait gérer complètement les défaillances de ses petits.le 04/09/2009 à 15:09 -
r1-1024Membre du ClubProblème #1 : System.gc() est super lourd et doit être évité !
Problème #2 : ce n'est pas parce que tu mets une référence à null que l'objet correspondant peut être libéré.
Problème #3 : si tu veux un comportement déterministe il faut revoir complètement la gestion de la mémoire, afin qu'une référence que tu "supprimes" avec delete ne soit pas partagé... sinon on va se retrouver avec des références invalides ce qui est une abbération en Java
Le "delete" n'est pas fait pour effacer l'objet sans vérif (je crois que c'est le cas dans flash).
En fait delete n'est pas approprié, il faudrait plutôt l'appeler gcOn(obj)
Le but est simplement de notifier au gc que l'objet en question ne devrait plus être référencé et si tel est le cas de l'effacer.
Cette opération ne serait pas effectuée si l'objet était référencé ailleurs.
Exemple :
Dans une application MDI j'effectue les opérations suivantes :
-Open project
-Do something costly
-Save & close project
Moi en interne je n'ai plus aucune référence sur le projet mais le gc ne s'est tjrs pas déclanché et le projet est à coup sûr encore en RAM. Même si il s déclanche ou que j'invoke le gc, comme mon projet est de nième génération, il ne sera pas libéré.
-New project (et là j'attends que le gc fasse son boulot car j'ai plus de mémoire)le 04/09/2009 à 18:03 -
tchize_Expert éminent séniorsi tu regarde la manière dont fonctionne le gc en interne, tu verra que on ne peux jamais supprimer 1 objet. On travaille toujours sur des calculs de l'ensemble des objet. Ton problème est un problème de performance, et un mot clé delet eest une fausse solution. Ce qu'il faut c'est simplement des GC plus performant. Sinon lors du delete, tu va parcourir toute la heap pour tester si 1 objet peut être libéré, alors qu'il faudrait au contraire libérer tout ce qui est libérable à ce moment là.le 04/09/2009 à 18:49
-
r1-1024Membre du ClubC surement pour ca que flash doit effacer l'objet sans vérifier le graphe objet.
J'ai eu pas mal de retour clients qui se plaignaient de ce comportement sur des applis gourmandes, et là malheureusement ya rien à faire.le 04/09/2009 à 19:03 -
tchize_Expert éminent séniortu peux lancer la jvm en mode server. Ceci utilise un algorithme de garbage collector qui réduit les blocage dus au GC.le 05/09/2009 à 12:29