Tu devrais jeter un oeil sur OSGi, si ce n'est pas déjà fait...Citation:
Envoyé par Killing Joke
Version imprimable
Tu devrais jeter un oeil sur OSGi, si ce n'est pas déjà fait...Citation:
Envoyé par Killing Joke
1E6 c'est bien aussi :)
Il me semble qu'il a quelques truc pas mal dans ces quelques nouveautés.
Moi, ya une question qui me taraude l'esprit ... des nouveautés, qu'est-ce qui pourra être "java 6 compliant" (si je mets un -target 1.6) ?
Par exemple, je me doute que les underscores dans les nombres ne vont pas remettre en question mon bytecode. De même, il est connu que les switch sur les string étaient possibles dans la spec du bytecode (c'était une restriction du compilateur et non du langage).
A l'inverse, je suppose que l'utilisation de nio devient éliminatoire (tout comme l'utilisation des nouvelles classes apparues avec cette version : Objects, fork/join etc...)
Les choses sur lesquelles j'ai plus de mal à me prononcer :
- Le multicatch : On pourrait se dire que le compilateur n'aurait qu'à copy/paster le bloc de code pour les différentes exceptions catchée (c'est d'ailleurs même peut-être ce que fait le compilateur, même en target 1.7 ?). On aurait alors une compatibilité de fait pour ce sucre, est-ce bien le cas ?
- Le try-with-resource : on pourrait se dire que le compilateur supprimerait les références à l'interface Closable (sauf peut-être dans les endroits où on ferait un extends Closable ?).
Après tout, le runtime n'a pas besoin d'être sur que la classe implémente Closable (ça, c'est plutôt une préoccupation du compilateur) : lui, tout ce dont il a besoin, c'est de l'implémentation de la méthode close().
Qu'en pensez-vous ?
Pour les changements du langage, même s'il s'agit au final de sucre syntaxique, ils seront refusés par le compilateurs si on lui spécifie un target inférieur.
En fait la limitation porte plutot sur le paramètre "source" que le "target" mais comme le paramètre "target" doit toujours être supérieur au paramètre "source", ça reviens au même.
Pas tout a fait.Citation:
A l'inverse, je suppose que l'utilisation de nio devient éliminatoire (tout comme l'utilisation des nouvelles classes apparues avec cette version : Objects, fork/join etc...)
Les incompatibilités de l'APÏ standard java ne sont pas vérifiées par le compilateur, il ne s'occupe que du langage lui même. Pour t'en convaincre, on peut actuellement très bien compiler un code qui fait appel a des bibliothèques apparues avec JavaSE 6 avec un target 1.4.
Bien évidement un tel code échouera tout de même s'il est exécuté sur une JVM antérieure a Java 6, mais il compilera sans problème.
c'est pour ça qu'il reste recommandé de compiler avec un jdk qui correspond à la version de votre cible :)
comment utiliser java 7 avec Jbuilder 2006 entreprise
Il faut voir dans les options de projets s'il est possible de choisir son JDK mais de toute façon, il y a fort a parier que les nouvelles fonctionnalité du langage (multicatch, string dans les switch, littéraux binaires, ...) seront mal supportées.
Si tu veux un bon support de Java 7, il faudra te tourner vers des IDE plus récents comme Netbeans 7, Eclipse 3.7 ou Itellij IDE 10.5
Merci de votre réponse, mais dans Eclipse ou netbeans je ne trouve pas les composants de la manipulation de base de données comme dans Jbuilder
Autant que je sache, les composants auxquels vous faites sans doute référence étaient exclusifs aux outils borland. Vous pourrez toujours faire de la base de données en utilisant JDBC ou ses frameworks mais vous ne trouverez pas les composants propriétaires de borland comme tels.Citation:
Envoyé par Benferhat
Java 7 disponible en version finale
Oracle publie son environnement d'exécution et le JDK 7
Mise à jour du 29/07/11
Après plus de quatre ans depuis la sortie de Java 6, Oracle vient de publier la version finale de Java Runtime Environment (JRE) 7.
Cette version est la première de Java SE publiée depuis la reprise du langage par Oracle suite au rachat de SUN.
Java SE 7 apporte un support pour un bon nombre de tendances qui ont déferlé dans le monde du développement informatique depuis la publication de la dernière version. Il offre une prise en charge amélioré des langages dynamique conçus pour fonctionner sur la machine virtuelle Java comme Scala et Groovy.
Java SE 7 embarque une API permettant de simplifier l’’exécution d’un programme à travers des processeurs multi-cœurs. Et plusieurs autres nouveautés importantes (lire-ci avant).
Le nouveau Runtime Java 7 peut-être utilisé par les développeurs avec les environnements de développement NetBeans ou encore IntelliJ IDEA 10.5. Oracle a annoncé qu’il publiera avant la fin de l’année une mise à jour de son EDI JDeveloper pour un support de Java 7.
Le runtime Java 7 est disponible pour les systèmes d’exploitations Linux, Solaris et Windows 32 bits et 64 bits.
Oracle a également annoncé la disponibilité de la version finale du Kit de Développement de Java 7 (JDK7),
:fleche: Télécharger Java 7 sur le site d'Oracle
:fleche: Télécharger JDK 7 sur le site d'Oracle
Un seul mot : ENFIN !
Oracle a peut être bien fait de reporter la majorité des nouveautés à Java 8. Il fallait absolument qu'une mise à jour sorte, pour prouver que le langage continue d'évoluer...
D'accord avec Flaburgan, même si les nouvelles fonctionnalités ne sont pas celles que j'attendais en priorité. C'est un bonne chose qu'ils aient enfin sorti une nouvelle version.
Il va falloir être patient en attendant java 8 :mrgreen:
Sinon à l'installation du jdk-7-windows-i586.exe : quand je veux changer la location (par exemple pour le mettre dans c:\java) du répertoire d'installation en appuyant sur "Change...", msiexec me pête un message (voir PJ)
J'avais résolu le souci en faisant un back puis un next avec les précédentes versions, mais là ça ne fonctionne pas je vais essayer d'aller l'installer sur un autre poste :aie:
A+
Maintenant que Java 7 est sorti, on va pouvoir inscrire les enums Java dans la liste des espèces en voie de disparition. Place aux codage avec les pieds et aux Strings dans les switch et leurs futures erreurs chronophages dues à des problèmes de casse indécelables avant l'exécution.
Tu as les droits en écriture là où tu veux l'installer ? (ça paraît bête mais je demande..) (et pis les droits d'install aussi, on sait jamais haha)
Ceux qui remplaceraient des enums par des strings sont les mêmes qui le faisaient avant avec des int alors ça change rien. De plus String et enum sont pas incompatible. ExempleCitation:
Envoyé par air-dex
Code:
2
3
4
5
6
7
8
9
10
11
Ou peut on recuperer la OpenJDK 7 ?
http://openjdk.java.net/
je pense pas qu'il y aie de release windows dispo, mais tu peux compiler les sources :aie:
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.Citation:
Envoyé par air-dex
De toute façon quand ces gens la voient que les String dans un switch ne marchent pas, ils font tout simplement une chaine de if, pas une énumération.
Je cherche quelque chose de deja compiler.Citation:
Envoyé par tchize_
on ne peut pas demander a un utilisateur lambda de le faire :aie:
(ce n'est pas pour moi, moi je ne passe pas sur jdk7 :mrgreen:)
L'utilisateur lambda il télécharge la version oracle, pas la version open jdk :pCitation:
Envoyé par eclesia
Ca commence bien...
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] command execution failed
Embedded error: @NotNull instrumentation failed for
Ca commence bien. :aie:
(source)Citation:
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.
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.
Ca fait peur qu'ils décident de sortir Java 7 en sachant qu'il contient des bug si gênants.Citation:
Envoyé par pseudocode
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.Citation:
Envoyé par Uther
Quand au known issues, ce truc est clairement mentionné dedans:
Citation:
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é ...
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.
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.Citation:
Envoyé par Tesing
Oui par exemple pour les requêtes SQL ça serait pratique.Citation:
Envoyé par _skip
Ça sera sans doute pour une prochaine fois.
Non le projet coin sert justement a regrouper toutes les évolutions syntaxique mineure. Il n'y a pas d’évolutions majeure pour cette version.Citation:
Envoyé par Tesing
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.
Comme en c#Citation:
Envoyé par Uther
Code:
2
3
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.Citation:
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.
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.
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.
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.Citation:
Envoyé par _skip
(source)Code:
2
3
4
5
6
7
8
9
10
11
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.Citation:
Envoyé par Uther
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.
Abuser des enums ce n'est pas tip-top non plus :/Citation:
Envoyé par air-dex
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++
Certes, mais la plupart des frameworks web java proposent une adaptation de type automatique, incluant les enums.Citation:
Envoyé par adiGuba
Jbuilder 2006 accepte Java 7 ???
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é.Citation:
Envoyé par adiGuba
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.Citation:
Envoyé par Tommy31
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
Concernant Java 8 les lambdas vont permettre de nouvelles sortes d'APIs, donc indirectement cela finira par être utile ;)Citation:
Envoyé par _skip
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 :
Voire comme ceci avec le Type Inference :Code:
2
3
Code:
2
3
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 :D
a++