Discussion :

[Invité]

Ca commence bien...

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] command execution failed

Embedded error: @NotNull instrumentation failed for

[pseudocode]

Ca commence bien.

Don’t Use Java 7, For Anything

Java 7 GA was released today, but as noted by Uwe Schindler, there are some very frightening bugs in HotSpot Loop optimizations that are enabled by default. In the best case scenario, these bugs cause the JVM to crash. In the worst case scenario, they cause incorrect execution of loops.

(source)

[tulipebleu]

Bonjour,

Pour ceux qui veulent avoir la documentation mieux structuré, il faut aller ici :
http://download.oracle.com/javase/7/docs/
Avec cette page, vous avez accès directement aux nouveautés, à la Javadoc, etc...

Par contre, toujours pas de multitouch (ou même le tactile de base) dans Swing et je n'ai pas l'impression qu'il sera dans Java 8.

[Uther]

Ca commence bien.


(source)

Ca fait peur qu'ils décident de sortir Java 7 en sachant qu'il contient des bug si gênants.

Le problème n'apparait même pas dans les "known issues" des "releases note". Ca fait vraiment pas sérieux.

[tchize_]

Ca fait peur qu'ils décident de sortir Java 7 en sachant qu'il contient des bug si gênants.

Le problème n'apparait même pas dans les "known issues" des "releases note". Ca fait vraiment pas sérieux.

Toutes les version de java par le passé sont sorites avec des bugs actifs, les bugtracker de sun (maintenant oracle) n'a jamais été vide pour une release. Quand vous avec un gros système, faut faire des choix quand aux bugs qu'on fixe et ceux qu'on ne fixe pas. En l'occurence, pour ces bugs là, il suffit de rajouter un paramètre à la jvm si vous êtes face à un code qui en souffre. JE suppose que si il est passé inaperçu jusque là alors qu'il affecte aussi java 6, c'est probablement que les code qui en souffre sont rares.

Quand au known issues, ce truc est clairement mentionné dedans:

Area: HotSpot
Synopsis: In JDK 7 FCS (b147), Hotspot crashes with a segv while running PorterStemmer, which is part of Apache Lucerne.
The recommended workaround is to specify -XX:-UseLoopPredicate on the command line.
The problem has existed at least since JDK 6 Update 23 and JDK 7 build 102 when using -XX:+AggressiveOpts, but was exposed with no command line flags in JDK 7 build 134 with the combination of making a loop optimization that had only been enabled under AggressiveOpts the default, and the fix for 6942326.
An interim fix for this issue was pushed into the OpenJDK Hotspot source base for Hotspot 22 on July 27, 2011 under 7070134: those who wish to examine or use it can find the changeset at http://hg.openjdk.java.net/hsx/hotsp...v/4e761e7e6e12. CR 6831314 will track the final fix.
RFE: 6831314, 6942326, 7070134

Et manifestement, apache lucene semble le seul affecté ...

[Uther]

Autant pour moi j'ai du lire un peu trop vite les "Known issues".

Il est sur qu'il est impossible de sortir un JDK "bug free", mais d'après la description de l'article, le problème me parait quand même très gênant : ça va un peu plus loin qu'un simple crash de hotspost comme le mentionne le "known issue", vu que cela semble aussi pouvoir aboutir a un programme qui se comporte bizarrement dans certains cas.

Si seul Apache est touché pour le moment c'est qu'il sont probablement les premiers à essuyer les plâtres sur des gros projets. Et le fait qu'ils aient 2 projets différents impactés (Soir et Lucène d'après l'article) ne me parait pas très rassurant.
Si le bug est resté inaperçu sous Java 6 c'est sans doute surtout parce qu’il s'agissait d'une optimisation désactivée par défaut alors qu'elle est activée par défaut dans Java 7.
Je ne pense pas que grand monde connaissait ces options d'optimisations qui sont assez peu documentées.

[Tesing]

Y aurait il des nouveautés syntaxiques autres que celles du projet coin.
Comme des chaînes de caractère multi-lignes ou une manière de pas devoir échapper tous les \ dans les regex ?

[_skip]

Y aurait il des nouveautés syntaxiques autres que celles du projet coin.
Comme des chaînes de caractère multi-lignes ou une manière de pas devoir échapper tous les \ dans les regex ?

Pas si on se fie à cette liste. Ils ont juste autoriser quelques nouvelles syntaxes pour les numériques et les binaires, selon moi, dans un langage comme java très sollicité dans le domaine de la gestion il y avait plus urgent mais bon.

[Tesing]

Pas si on se fie à cette liste. Ils ont juste autoriser quelques nouvelles syntaxes pour les numériques et les binaires, selon moi, dans un langage comme java très sollicité dans le domaine de la gestion il y avait plus urgent mais bon.

Oui par exemple pour les requêtes SQL ça serait pratique.
Ça sera sans doute pour une prochaine fois.

[Uther]

Y aurait il des nouveautés syntaxiques autres que celles du projet coin.
Comme des chaînes de caractère multi-lignes ou une manière de pas devoir échapper tous les \ dans les regex ?

Non le projet coin sert justement a regrouper toutes les évolutions syntaxique mineure. Il n'y a pas d’évolutions majeure pour cette version.
Pour ce qui est des chaines de caractères multilignes ca a été refusé et pour échapper les "\", je vois mal comment faire autrement sans remettre en cause tout le langage.

La prochaine évolution majeure sera les lambda qui sont prévues pour Java 8. La deuxième partie du projet coin devrait également arriver avec notamment l'intégration des collection au langage ce qui devrait a mon avis être une évolution bien plus attendue.

[_skip]

Pour ce qui est des chaines de caractères multilignes ca a été refusé et pour échapper les "\", je vois mal comment faire autrement sans remettre en cause tout le langage.

Comme en c#

Code :

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

1
2
3
 
String file = "C:\\Temp\\app\\file.txt";
String file2 = @"C:\Temp\app\file.txt";

La prochaine évolution majeure sera les lambda qui sont prévues pour Java 8. La deuxième partie du projet coin devrait également arriver avec notamment l'intégration des collection au langage ce qui devrait a mon avis être une évolution bien plus attendue.

Je me suis toujours demandé pourquoi les lambdas et autres closures étaient si attendues en fait. Je vois pas ça comme quelque chose qui s'utiliserait vraiment au quotidien, j'y ai rarement recours en C# pourtant elles existent.
Et souvent lorsque je lorgnais les débats sur le net concernant les syntaxes a adopter, je me demandais si la plupart des participants ne voulaient pas en fait que java devienne du ruby ou du python.
Le truc qui me manque le plus au quotidien, personnellement ce serait un sucre syntaxique pour les get/set histoire d'avoir une façon propre et facile à documenter de laisser un membre de classe public.

[bouye]

Voyant ce que ça donne pour JavaFX (les closure étaient supportées dans JavaFX 1.x + JavaFX Script et sont remplacées par des listeners dans JavaFX 2.0 + Java), je ne peux que me rejouir de leur retour dans Java 8.

Et oui sinon avant FX 1.x, je me posait exactement la même question. Depuis FX 1.x, je ne me la pose plus, c'est bien plus pratique avec (même si la syntaxe proposée pour Java 8 reste lourde par rapport à ce qu'on avait en JavaFX Script).

Oui j'espère également une syntaxe permettant l'automatisation des propriété. Toujours pareil : leur fonctionnent dans JavaFX 2.0 est sensé être proche de ce qu'on aura dans Java 8 et +. Hors désormais ne ne sont plus de simple getters et setters qu'il faut écrire mais 3 accesseurs, utiliser un conteneur spécial et tout déclarer en final. Pour peu que l'on ait plus de 5 propriétés à écrire ça devient super lourdingue.

[pseudocode]

Je me suis toujours demandé pourquoi les lambdas et autres closures étaient si attendues en fait. Je vois pas ça comme quelque chose qui s'utiliserait vraiment au quotidien, j'y ai rarement recours en C# pourtant elles existent.

Personnellement, je trouve ca lourd de devoir définir et instancier une classe anonyme, alors que je n'ai besoin que d'un corps de méthode.

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
meteo.addTemperatureListener(new TemperatureAdapter() {
	@Override public void temperatureChangee(double oldTemperature, double newTemperature) {
		// exécution dans l'EDT
		SwingUtilities.invokeLater(new Runnable() {
			public void run() {
				// à chaque fois que la température change, on met à jour le textfield
				textField.setText(""+newTemperature);
			}
		});
	}
});

(source)

[air-dex]

Encore faut il que l'énumération ait un sens. S'il s'agit de créer une énumération qui ne sert que pour un switch c'est bidon.

C'est sûr que pour un switch, une énumération de sert à rien. Mais derrière une énumération, il y a aussi une entité qui a une signification dans un programme. Abuser des String dans les switch, c'est aussi perdre ces entités là avec tout ce qu'elles peuvent signifier. D'un point de vue conception, abuser des String dans les switch craint.

[bouye]

Bah, on continuera d'utiliser les enum pour les sets ave un nombre de valeurs finis et prédéterminés, qui ne changent pas trop souvent et qui demandent une cohérence forte (type) et on utilisera les strings pour les tests sur des sets qu'on prévoit d'élargir assez souvent. Enfin du moins en théorie, ça n'empêchera jamais ceux qui programment avec les pieds de continuer à le faire. Ce qui implique donc pour nous de continuer à éduquer les gens qui viendront poser des questions à ce propos dans les forums.

[adiGuba]

C'est sûr que pour un switch, une énumération de sert à rien. Mais derrière une énumération, il y a aussi une entité qui a une signification dans un programme. Abuser des String dans les switch, c'est aussi perdre ces entités là avec tout ce qu'elles peuvent signifier. D'un point de vue conception, abuser des String dans les switch craint.

Abuser des enums ce n'est pas tip-top non plus :/
Transformer une String en enum juste pour un switch, alors qu'on la créer juste pour cela ce n'est pas mieux...

Les String peuvent être considérés comme un type de base, à l'instar des type primitifs, du fait qu'elles sont intégrées au langage via les littéraux. Alors je ne vois pas de raison de ne pas utiliser cela... selon le cas bien sûr.

Surtout en environnement Web où tous les paramètres que l'on reçoit sont à la base des String...



a++

[Tommy31]

Surtout en environnement Web où tous les paramètres que l'on reçoit sont à la base des String...

Certes, mais la plupart des frameworks web java proposent une adaptation de type automatique, incluant les enums.

[Benferhat]

Jbuilder 2006 accepte Java 7 ???

[pseudocode]

Les String peuvent être considérés comme un type de base, à l'instar des type primitifs, du fait qu'elles sont intégrées au langage via les littéraux. Alors je ne vois pas de raison de ne pas utiliser cela... selon le cas bien sûr.

De plus, je crois bien que le bytecode généré pour un "switch" de string est plus performant qu'une cascade de "if-then-else". Si je me souviens bien, ca recrée un "switch" avec des entier en utilisant le hashcode des chaines comme clé.

[adiGuba]

Certes, mais la plupart des frameworks web java proposent une adaptation de type automatique, incluant les enums.

Oui mais ca revient à multiplier les enums pour chaque besoin, en utilisant les mêmes noms que les valeurs possibles. Le tout sans qu'il n'y ait forcément un besoin fort derrière.


Franchement quel intérêt de faire une enum juste pour un switch ?
Autant faire un switch directement sur les String.
Maintenant c'est sûr que si cette valeur représente une entité bien définis, le choix de l'enum sera à privilégier.

Tout cela c'est juste pour dire que le switch(String) n'est pas forcément inutile ni forcément une erreur

Et comme le dit pseudocode, le switch(String) est plus performant qu'une succession de if/else : http://download.oracle.com/javase/7/...gs-switch.html

Je me suis toujours demandé pourquoi les lambdas et autres closures étaient si attendues en fait. Je vois pas ça comme quelque chose qui s'utiliserait vraiment au quotidien, j'y ai rarement recours en C# pourtant elles existent.

Concernant Java 8 les lambdas vont permettre de nouvelles sortes d'APIs, donc indirectement cela finira par être utile


Sans compter comme cela a été dit que cela remplacera avantageusement de nombreuses classes anonymes.
L'exemple précédent de pseudocode pourrait s’écrire comme ceci :

Code Java :

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

1
2
3
meteo.addTemperatureListener(#{double oldTemperature, double newTemperature ->
	SwingUtilities.invokeLater(#{textField.setText(""+newTemperature)});
});

Voire comme ceci avec le Type Inference :

Code Java :

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

1
2
3
meteo.addTemperatureListener(#{oldTemperature,newTemperature ->
	SwingUtilities.invokeLater(#{textField.setText(""+newTemperature)});
});

Et il ne faut pas oublier non plus les fonctions qui tourneront autour :

• Les Method references qui permettront de référencer les méthodes via un libellé, ce qui permettra de faire des choses proches de la réflexion tout en ayant un code sécurisé à la compilation
• Les Defender methods qui permettront de faire évoluer les interfaces de manière portable, ce qui permettra ainsi de continuer à améliorer l'API...

Et comme pour les Generics, c'est l'API de Collections qui devrait bien profiter de tout cela


a++