Le 7/7 c'est Java 7

**Traroth2** · 08/07/2011, 14h25

Envoyé par Killing Joke

Perso', j'attends surtout Java 8 pour le projet Jigsaw, avec la gestion des dépendances directement gêrée en Java (modules et dépendances inter-modules ou dépendances vers des jars) (même si çà n'ira sans doute pas super loin, çà mettra un coup de pied dans la fourmillère maven).

Tu devrais jeter un oeil sur OSGi, si ce n'est pas déjà fait...

**wax78** · 13/07/2011, 11h32

1E6 c'est bien aussi

Il me semble qu'il a quelques truc pas mal dans ces quelques nouveautés.

**Atma_** · 17/07/2011, 12h59

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 ?

**Uther** · 17/07/2011, 13h54

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.

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

Pas tout a fait.
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.

**tchize_** · 18/07/2011, 10h47

c'est pour ça qu'il reste recommandé de compiler avec un jdk qui correspond à la version de votre cible

**Benferhat** · 25/07/2011, 12h38

comment utiliser java 7 avec Jbuilder 2006 entreprise

**Uther** · 25/07/2011, 14h01

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

**Benferhat** · 25/07/2011, 14h56

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

**_skip** · 25/07/2011, 15h59

Envoyé par Benferhat

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.

**Hinault Romaric** · 29/07/2011, 11h52

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

Télécharger Java 7 sur le site d'Oracle

Télécharger JDK 7 sur le site d'Oracle

**Flaburgan** · 29/07/2011, 13h22

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

**nu_tango** · 29/07/2011, 13h38

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

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

A+

**air-dex** · 29/07/2011, 14h07

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.

**Flaburgan** · 29/07/2011, 14h10

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)

**tchize_** · 29/07/2011, 14h16

Envoyé par air-dex

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.

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

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
switch(clesLueDespuisLeFichierQueJaiPasEncoreconvertiEnEnum){
   case "Machin":
     return new Node (MonEnum.Machin, parametres[0], parametres[1]);
   case "Truc":
     return new Node (MonEnum.Truc, parametres[0], parametres[1], parametres[2]);
   case "Bidule":
     return new Node (MonEnum.Bidule);
   default :
     return new Node(MonEnum.Unknown);
}

**eclesia** · 29/07/2011, 14h41

Ou peut on recuperer la OpenJDK 7 ?

**tchize_** · 29/07/2011, 15h13

http://openjdk.java.net/

je pense pas qu'il y aie de release windows dispo, mais tu peux compiler les sources

**Uther** · 29/07/2011, 15h33

Envoyé par air-dex

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.

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.

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.