Tu ne trouveras pas cette info sur le site officiel pour la simple et bonne raison qu'elle n'est pas encore officiellement fixée. La preuve en est le retour surprise des closures.
D'ailleurs, il n'y a pas de JSR officielle pour Java 7.
Tu ne trouveras pas cette info sur le site officiel pour la simple et bonne raison qu'elle n'est pas encore officiellement fixée. La preuve en est le retour surprise des closures.
D'ailleurs, il n'y a pas de JSR officielle pour Java 7.
Perso j'aurai apprécié un geste du côté des propriétés, bon sans cet opérateur à la noix qu'est la flèche. Je trouve ça pénible ces getter/setters à documenter, dans le genre plomberie inutile c'est fort.
En gros j'attendais que cette version 7 rattrappe un peu la bourre de java face à C# mais finalement tout ce qui est lourd reste bien lourd. Les blocs ARM sont une excellente chose, si seulement ils avaient été accompagnés d'une ou deux mesures comme les try-catch multiples-rethrow.
Car franchement les opérateurs sur les collections et les switch dans les chaînes de caractère, je trouve que ce sont des progrès moins que mineurs.
Le site sur le language java 7 est ici
https://jdk7.dev.java.net/
A propos de Disposable et de la modification des blocs try/catch.
Il me semble qu'on a ici un problème déjà vu avec les blocs synchronized: tout va bien... quand on est en portée syntaxique! java.util.concurrent avait apporté des solutions à ce problème pour les blocs synchronized.
Donc reprenons: j'ai un objet Disposable sur lequel je donne à un code client des accès (au travers d'un itérateur par exemple). Le code client consomme des données et c'est à lui qu'incombe la responsabilité de fermer... Dans ce cas il faudrait un DisposableIterator ou un truc qui nous garantisse la fermeture !
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
Je comprend pas vraiment le problème.
Les blocs ARM obéissent à une règle très simple : le même bout de code qui ouvre une ressource est responsable de sa libération et ainsi sa durée de vie est parfaitement réglée dès le départ.
Dans le cas contraire, c'est à dire si la ressource, par exemple un OutputStream, est obtenue par une autre classe via un getter, Il faudra effectivement toujours se mettre d'accord sur le responsable de la ressource. Pour y aller par là, ça ne changera pas si c'est ce que tu voulais dire.
En c# la plupart des objets disposables sont faits de tel manière que si la méthode dispose n'est pas appelée par le code du développeur, c'est le finaliseur de la classe qui le fera. Le seul problème c'est que contrairement au C++ on ne peut pas prévoir quand ça arrivera, idem pour java quoi.
Faut juste attendre des blocs ARM une facilité au niveau de la syntaxe, ce n'est pas une façon de se débarrasser de la gestion de ressource en général.
Ca tombe bien le multi-catch et le rethrow sont réexaminés pour intégration dans Java 7 (apparemment le rethrow faciliterait l'implémentation des blocs ARM) : http://blog.developpez.com/adiguba/p...catch-rethrow/
J'ai vu passer des messages dans ce sens dans la mailling-list du projet Coin, où il évoquait la possibilité d'intégré cela au for étendus, voir de créer un "try-for" qui fermerait l'Iterator à la fin du traitement.
A suivre donc...
a++
Juste pour t'expliciter le problème: encapsulation et découplage.
soit un code client de cette interface:
le code client ne sait pas si le code réalisant va passer des requêtes à JDBC, lire des données à partir d'un serveur ou que sais je...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 interface Catalogue { Iterator<Produit> get(String chaineMatch); // exemple très simplifié }
Mais c'est quand même à ce code client de dire s'il a cessé de consommer : d'où le besoin d'un contrat de type plus sophistiqué comme DisposableIterator (ou alors le fournisseur de l'Iterator crée un objet très spécial -par exemple avec un bail d'utilisation-)
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
Et quelque chose comme
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 try (Iterator<Produit> iter = monCatalogue.get("xyz") ) { iter.next()... }
(je suis pas 100% sûr de la syntaxe)
Ca ne serait pas possible ? Il n'est pas prévu que Iterator soit disposeable?
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
pas franchement: il se trouve que j'ai implanté pour moi un tel mécanisme et c'est pas simple simple:
Mon Disposable Iterator à moi :
- dispose d'une méthode close() explicite
- peut être configuré avec un timeOut
- si on "oublie" de le fermer :
- * soit le timeout le ferme
- * soit finalize le ferme (mais comme chacun sait finalize il faut pas compter dessus)
- * soit un shutdownHook le ferme
le premier qui arrive a gagné : mais c'est pas franchement simple...(par ex. quand il y a un refus par timeout le code client doit être prévenu).
Une technique plus générale serait bienvenue ....
Le transfert des opérations de sortie automatique dans le bloc appelant en rendant L'Iterator lui même Disposable me semble vraiment une bonne idée.
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
Ah. Mon problème à moi était d' ouvrir/fermer la "ressource" dynamiquement et pas de juste fermer l'itérateur. Du coup le finalize+shutdownHook était une bonne solution, malgré la latence entre la fin d'utilisation de l'itérateur, et le passage du GC.
Code java : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35 public class DisposableIterator<T> implements Iterator<T> { protected DisposableResource<T> resource = null; protected Iterator<T> iterator = null; public DisposableIterator(DisposableResource<T> resource, Iterator<T> iterator) { this.resource = resource; this.iterator = iterator; } @Override public boolean hasNext() { return this.iterator.hasNext(); } @Override public T next() { return this.iterator.next(); } @Override public void remove() { this.iterator.remove(); } @Override protected void finalize() throws Throwable { this.resource.dispose(); } } public abstract class DisposableResource<T> implements Iterable<T> { protected Iterable<T> iterable = null; protected int usage = 0; public DisposableResource(Iterable<T> iterable) { this.iterable = iterable; } public Iterator<T> iterator() { if ((usage++)==0) open(); return new DisposableIterator<T>(this, this.iterable.iterator()); } public void dispose() { if ((--usage)==0) close(); } public abstract void open(); public abstract void close(); }
Code java : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 public static void main(String[] args) { List<String> list = Arrays.asList("Hello", "world"); Iterable<String> resource = new DisposableResource<String>(list) { @Override public void open() { System.out.println("open the resource"); } @Override public void close() { System.out.println("Close the resource"); } }; Iterator<String> iter1 = resource.iterator(); while(iter1.hasNext()) System.out.println("read : "+iter1.next()); }
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
un document quelque part la dessus sur la direction que prennent les choses?
merci
modif: ah? je croyais avoir trouvé : http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc mais ça c'est FCM
Oops!
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
Je te conseille de suivre le blog de adiGuba qui fait des retours réguliers sur l'avancement des nouveautés de Java 7, particulièrement les closures.
autre URL pour suivre le film : http://openjdk.java.net/projects/lambda/
(bon je viens de me taper le suivi de la liste de mails sur le sujet et même si la théorie m'interesse je ne comprends pas tout car les auteurs omettent de mettre en place des exemples vraiment convaincants pour de simples mortels)
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
C'est pour cela que je t'ai proposé le blog d'adiGuba, qui prend la peine de fournir des exemple clairs tout en restant très complet.
Je me suis moi aussi abonné à closures-dev et lambda-dev, mais par moment il faut s'accrocher pour suivre.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager