Sait-on quelles seront les nouveautés de java 7

Version imprimable

07/10/2008, 12h17
_skip

Sait-on quelles seront les nouveautés de java 7

Bonjour,

Nous avons bien quelques posts dans le forum débat concernant les propositions d'amélioration de java (niveau langage). Malheureusement j'ai été incapable de trouver des informations de source convenable sur ce qui avait effectivement été retenu ou non.

Quelqu'un sait où en est la situation?
07/10/2008, 12h33
adiGuba

Salut,

Malheureusement il n'y a toujours pas de JSRs globale pour Java 7, et donc on n'a aucune info officiel sur l'avenir de Java.

On ne peut que se baser sur les JSRs annexes et leurs avancements supposé pour en déduire leurs possibilitées d'intégration, ainsi que sur plusieurs propositions d'évolutions du langage.

Le blog d'Alex Miller est assez détaillé sur le sujet, et comporte une page récapitulatif de ce qui pourrait être intégré à Java 7 : http://tech.puredanger.com/java7

Il a même fait ses propres estimations il y a quelques temps : http://tech.puredanger.com/2008/08/0...iction-update/

Mais il n'y a rien de certain pour le moment... :(

a++
07/10/2008, 15h45
_skip

Merci, une lecture très intéressante.

Malheureusement pas de chance pour l'inférence de type et les properties. Par contre du coté des exceptions ça a l'air d'aller dans le bon sens!
05/11/2008, 10h00
Shusaku

Un article assez détaillé (et en français) sur les nouvelles librairies :

http://blog.octo.com/index.php/2008/...es-dans-java-7
05/11/2008, 11h41
djo.mos

Salut,
N'oublies pas aussi que plusieurs des probables nouveautés sont débattues ici : http://www.developpez.net/forums/f10...e-java/debats/
05/11/2008, 11h49
adiGuba

J'ai également abordé certains aspects sur mon blog : http://blog.developpez.com/adiguba?cat=695

Même si en ce qui concerne les évolutions du langage, on ne sait toujours rien de précis pour le moment.

a++
10/11/2008, 16h16
_skip

Dans les topics de débat un peu partout sur le net, les choses ressortent assez bien: Y'a ceux qui disent java c'est java et ceux (comme moi) qui veulent que java soit c#. :mrgreen:

J'arrive pas à comprendre que les blocks ARM n'aient pas reçu plus de soutien.
C'est tellement l'horreur d'écrire du

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
try
{
     obj = ...;
     .... ;
} 
finally
{
    if( obj != null && obj.isOpen() )
    {
        try
        { 
            obj.close();
        }
        catch( ...)
        {
        }
    }
}

17/02/2009, 13h32
_skip

Un update sur le blog d'Alex Miller

http://tech.puredanger.com/2009/02/16/java7-update/

Un bref aperçu de mon point de vue :

En gros :
-Gestion d'exceptions améliorée OK (extra!)
-Inférence de type générique à la construction OK (utile)
-Gestion du null : person?.getName OK (mouais)
-Api files system OK (utile)

Sinon
-bloc ARM out (dommage)
-closures out (...)
-properties out (plein de get/set à documenter youpi)
-nouvelle API Date & Time douteuse (espérons que oui)
-swing beans binding out (aïe, terrible!)
17/02/2009, 15h50
adiGuba

Citation:

Envoyé par _skip

-Api files system OK (utile)

Oui très utile je dirais même !
Avec une gestion d'erreurs propre (basé sur les exceptions), et une meilleure intégration au système (gestions spécifiques des attributs de fichiers, des liens symboliques, de la notification de changement du système de fichier, ...). :king:

Citation:

Envoyé par _skip

-swing beans binding out (aïe, terrible!)

Dans un sens je peux comprendre cela : cette API gagnerait énormément si le langage intégrait un mécanisme de property ou de literals qui permettrait de bénéficier qu'un code sécurisé à la compilation.

:arrow: En l'état actuel tout est basé sur des noms de propriétés dans des String, et que tout changement peut passer inaperçu à la compilation mais causer des dégât à l'exécution...

Sinon dans l'article il parle de la JSR 308 qui consiste à généraliser l'utilisation des annotations partout dans le code source, mais il n'y a pas de trace de la JSR 305 dont l'utilité me semble plus concrête : cette dernière à pour objectif de définir un ensemble d'annotation qui pourrait être utilisé pour analyser le code et générer des warnings/erreurs (comme @NonNull pour les paramètres n'acceptant pas de valeur null...).

:arrow: Certains EDIs/outils utilisent déjà cela mais de manière anecdotique du fait qu'il n'y a rien de standard...

a++
17/02/2009, 16h05
_skip

Tu as raison pour les chaines de caractères non checkées à la compilation, mais je m'essaie actuellement à JSF et j'ai l'impression qu'on est tout à fait prêt à vivre avec ça. (Venant du monde .Net ça m'a un peu choqué d'ailleurs). On peut limiter ce problème en générant les property names sous forme de constantes finales dans son bean:

public final String PROP_NOM = "name"...

En fait je trouve que c'est pas trop cher payé par rapport aux nombres de copier-coller que l'on fait généralement pour remplir des JTextField, parser leur valeur, les convertir dans le bon type manuellement etc...
Les grands formulaires en swing, je trouve que ça pêche quand même un peu si on se contente du standard.

En gros j'aurai aimé un effort coté swing car je trouve que cette API seule est un peu à la ramasse par rapport à d'autres technos comme winforms, qt etc...
Mais c'est mon impression personnelle, pas d'offenses.
17/02/2009, 16h29
adiGuba

Citation:

Envoyé par _skip

Les grands formulaires en swing, je trouve que ça pêche quand même un peu si on se contente du standard.

Je suis tout à fait d'accord sur le fait qu'il ne faille pas se contenter du standard ;)

Ce que je veux dire c'est que beans-binding pourrait énormément profiter d'évolutions du langage qui ont été reporté, et que si cette API est intégré tel quel on risque d'y apporter de gros changement dans le futur... :?

A la rigueur il est préférable de l'utiliser comme librairie externe en attendant...

Citation:

Envoyé par _skip

Mais c'est mon impression personnelle, pas d'offenses.

Il n'y a pas de problème (au contraire :D)

Le fait est que le cycle d'évolution de Java est à des années lumières de .NET. Les JSRs sont soumis à l'accord de plusieurs entité... ce qui peut prendre énormément de temps !

a++
17/02/2009, 19h42
gifffftane

Perso pour les propriétés de beans j'évolue actuellement vers une pratique iconoclaste, encore à roder, mais j'ai de bonnes impressions.

Attention, voici la démarche iconoclastique...

J'ai commencé par m'intéresser aux marques final dans les attributs d'instance ; j'avais vu ici et là que la JVM pouvait mieux optimiser leurs accés (jamais vérifié si c'était vrai).

Je me suis rendu compte que je pouvais mieux gérer ce type d'attributs, car mon EDI (Netbeans) me prévenait lorsque j'oubliais de les initialiser. Et puis il me semblait que je pouvais écrire un code plus sûr avec eux.

Et puis j'ai pris conscience qu'il ne m'était plus besoin d'écrire le setTruc (forcément, allez-vous me dire). Ils me permettaient donc d'économiser une moitié de la barbe d'écrire des get/set.

Et enfin, enchaînement d'idées, je me suis dit qu'il était parfaitement idiot également d'écrire aussi le getTruc, puisque je ne voyais pas quel fioritures j'allais écrire en plus du return truc, et donc je mets l'accés à l'attribut directement en public. J'arrive donc à

Code:

public final Truc truc;

De cette façon, aucun risque d'effet de bord (forcément ! ), et j'écris le reste de mon code de l'objet pour qu'il réagisse quelque soit la valeur de ma constante (même si tous les attributs de mon final ne sont pas eux mêmes final).

Qu'en pensez-vous, à part que c'est pas bien du tout et qu'il ne faut pas le conseiller ?... C'est beaucoup mieux, non ?

Rassurez-vous : pour les propriétés de bean que je ne peux pas marquer final, je continue l'ancien système par get et set.
17/02/2009, 20h21
_skip

Si je ne me trompe pas c'est le cas des tableaux standards de java qui ont cette propriété.
"public final int length"

En fait il y a pas un tas de choses qu'on puisse reprocher à ta manière de faire puisque le but d'un getter/setter est de contrôler l'accès depuis l'extérieur de la classe. Compte tenu que l'élément protégé est read-only, accès direct vs un get qui fait rien?

Certains puristes pourraient argumenter que si un jour l'intérieur de ta classe change complètement de mécanique et que ce champ n'est plus une valeur immuable mais le résultat d'un calcul, cela nécessiterait des changements dans les codes utilisant ta classe.

Maintenant chacun est libre de faire ce qu'il veut, si on extrapole ce cas que tu as soumis, à rechercher à tout prix une abstraction maximale on va souvent droit dans le mur et en négligeant trop cet aspect on nuit à l'évolutivité. Après chacun son juste milieu.
Mais c'est tout un débat ça aussi.

Adiguba, est-ce que tu pensais à jGoodies pour la librairie externe?
17/02/2009, 23h07
adiGuba

Citation:

Envoyé par gifffftane

Qu'en pensez-vous, à part que c'est pas bien du tout et qu'il ne faut pas le conseiller ?... C'est beaucoup mieux, non ?

Le problème c'est que ce n'est pas standard ni évolutif :
[list][*]Les propriétés d'un beans doivent être accessible via une méthode et non pas directement.[*]On n'a plus aucun contrôle sur l'accès à la propriété, en particulier si cette dernière est mutable :([/quote]

Citation:

Envoyé par _skip

Compte tenu que l'élément protégé est read-only, accès direct vs un get qui fait rien?

En terme de performance ? Ce doit être minime car la JVM sait très bien inliner les getter/setter tout comme les méthodes simple, même si elle ne sont pas final. Cela tout en conservant les avantages de la POO ;)

Citation:

Envoyé par _skip

Adiguba, est-ce que tu pensais à jGoodies pour la librairie externe?

Je fais très peu de Swing en fait... donc je n'avais pas de librairie spécifique en tête mais il en existe plein ;)

Tu pourrais même utiliser beans-binding car un grand nombre de JSR sont implémenté avant l'intégration dans la future version. Exemple : https://beansbinding.dev.java.net/

a++
17/02/2009, 23h50
gifffftane

Citation:

Envoyé par adiGuba

Le problème c'est que ce n'est pas standard ni évolutif :
[list][*]Les propriétés d'un beans doivent être accessible via une méthode et non pas directement.[*]On n'a plus aucun contrôle sur l'accès à la propriété, en particulier si cette dernière est mutable :(

Pas standard, oui je sais :yaisse2:

Mais là, le standard est un peu lourd et il n'évolue plus depuis quasi une demi-douzaine d'années ; alors quand tu parles de non évolutif, c'est direct le standard qui n'est pas évoutif.

Mais je présume que tu pensais à mon code, qui serait non-évolutif... Justement, ça se discute.

Sans accesseur, la signification est en fait complètement différente d'avec accesseur. C'est comme si l'objet voulait dire : cette propriété sans accesseur, vous pouvez en faire ce que vous voulez, je ne suis même pas au courant lorsque vous la modifiez. Par contre, quelque soit son état, lorsque je dois réagir, alors je m'engage à réagir correctement.

Il y a une séparation complète, explicite, entre accès et action. L'accés ne déclenche, à coup sûr, aucune action. (sauf pour ceux qui ont plus d'un tour dans leur sac, mais chut).

Si la propriété devient obsolète, cela n'empêche nullement de respecter l'engagement. Tu la marques deprecated, et tu fais évoluer ton code petit à petit, comme d'habitude.

Comme elle est marquée final, il ne faut pas oublier que c'est l'objet lui même qui, lors de sa construction, la renseigne, et que aucun autre ne peut le faire à sa place. C'est un levier très fort d'évolution. Par exemple rien n'empêche de faire évoluer la classe concrète de l'attribut final, sans faire évoluer la déclaration.

Dans l'ensemble, je trouve que l'usage des attributs d'instance marqués final oblige à beaucoup plus de discipline dans la construction et l'initialisation de l'objet, ordre qui t'aide beaucoup lorsque tu dois faire évoluer l'objet.

Et le fait que ce soit une fausse constante n'est pas très grave pour ce cas.

Donc l'évolution, si elle est un peu plus sioux que dans le cas avec accesseur, reste largement possible. J'admets toutefois que mon usage aurait besoin de plus de rodage, d'expérience. On verra.

Citation:

Envoyé par gifffftane

Mais je présume que tu pensais à mon code, qui serait non-évolutif... Justement, ça se discute.

Ce que je voulais dire, c'est que si tu as ceci :
Code:

1 2 3 4 5 6 7 8 class MyBeans { public final String name; public MyBeans(String name) { this.name = name; } }
:arrow: Tu mets à mal le principe d'encapsulation en donnant un accès direct à l'attribut.

Si demain on te demande de rendre cet attribut modifiable, tu vas devoir le cacher pour passer à un code du style :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class MyBeans { private String name; public MyBeans(String name) { this.name = name; } public String getName() { return this.name; } public void setName(String name) { this.name = name; // firePropertyChange ? } }
:arrow: Tout le code existant ne fonctionnera plus car l'attribut "name" n'est plus visible :(

Bref tout cela pour simplement s'éviter l'écriture d'une méthode getter, alors que cela peut être généré par l'EDI...

a++

18/02/2009, 13h07
gifffftane

Oui, OK, je sais. Justement, je remets en cause ; c'est ce que je dis depuis le départ. Quand bien même cela se fait automatiquement dans les EDI.

Bon, je crois qu'il vaut mieux attendre java 7.
18/02/2009, 13h49
_skip

C'est à peu près ce que j'ai voulu dire à travers mon exemple (changement d'une valeur immuable par le résultat d'un calcul ou X).

Sinon pour revenir à java 7, même si les cycles d'évolutions s'étalent et que tout le monde peine à se mettre d'accord, on voit par rapport aux propositions qui sont faites que les gens deviennent sensibles :

1) Aux problèmes de productivité et de maintenance (- de code pour plus de fonctionnalités).
2) A ce qui se fait chez la concurrence, .Net pour ne pas le citer.

En gros que les opérations courantes puissent se faire de façon straightforward, par exemple un sélecteur de fichier sans avoir besoin de classes de filtrage mais en indiquant simplement les extensions admises, un JTable triable sans galérer à intercepter les clics sur les colonnes ou implémenter un vieux tableModel bien dur avec gestion manuelle de l'édition des colonnes.

Tout ça pour pas passer du temps sur des problèmes récurrents et mettre son énergie sur autre chose.