Projet Coin : Les nouveautés dévoilées à la Java Community Conference d'Anvers

[Uther]

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.

[fanprog1]

Envoyé par Uther

Je rajoute que je suis également déçu de ne pas voir le catch multiple, et le rethrow.

Tout à fait d'accord avec toi, j'aurai bien voulu egalement que cette fonctionnalité soit ajoutée....

[_skip]

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.

[tchize_]

Le site sur le language java 7 est ici
https://jdk7.dev.java.net/

[professeur shadoko]

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 !

[_skip]

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.

[adiGuba]

Envoyé par _skip

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.

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/

Envoyé par professeur shadoko

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

[professeur shadoko]

Envoyé par _skip

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.

Juste pour t'expliciter le problème: encapsulation et découplage.
soit un code client de cette interface:

Code :

1
2
3
4
 
 interface Catalogue {
       Iterator<Produit> get(String chaineMatch); // exemple très simplifié
}

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

[_skip]

Envoyé par professeur shadoko

Juste pour t'expliciter le problème: encapsulation et découplage.
soit un code client de cette interface:

Code :

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

Et quelque chose comme

Code :

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?

[pseudocode]

Envoyé par professeur shadoko

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

Une sorte de méthode finalize(), en fait.

[professeur shadoko]

Envoyé par pseudocode

Une sorte de méthode finalize(), en fait.

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.

[pseudocode]

Envoyé par professeur shadoko

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.

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 :

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 :

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());
}

[professeur shadoko]

Envoyé par Uther

La preuve en est le retour surprise des closures.

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!

[Uther]

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.

[professeur shadoko]

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)

[Uther]

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.