Developpez.com

Club des développeurs et IT pro
Plus de 4 millions de visiteurs uniques par mois

Java SE 7 : Nouvelles modifications du language
Introduites par le projet Coin, présentées par Frédéric Martini

Le , par Baptiste Wicht, Expert éminent sénior
Mise à jour du 01/12/09

Gestion des exceptions améliorée (multi-catch et rethrow)

Citation Envoyé par adiGuba  Voir le message
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++

Mise à jour du 25/11/09

Encore plus de nouvelles fonctionnalités dans Java 7
Elles viennent d'être dévoilées lors de la Java Community Conference d'Anvers

La conférence Devoxx (également baptisée la Java Community Conference) s'est achevée à Anvers la semaine dernière.
Parmi les participants on comptait IBM, Oracle et Adobe.

Un des sujets abordés les plus "chauds" a évidemment été les futures fonctionnalités de Java 7.

Et on y a appris quelques nouveautés.

Citons (en vo) l'arrivée du :

* Language support for collections
* Automatic Resource Management
* Improved Type Inference for Generic Instance Creation (diamond)
* Strings in switch
* Binary literals
* Simplified Varargs Method Invocation

On pourra également utiliser les caractères spéciaux dans les nombres :

Par exemple 123456789 pourra s'écrire :

Code : Sélectionner tout
1
2
 
123_456_789
Ce qui faciliter l'interaction avec les langages dynamiques qui sont plus souples dans la définition des nombres.

Plus de détails sur ces "nouvelles nouveautés" ici même dans le courant de la semaine.

Pour mémoire le Java Development Kit Software est prévu pour Septembre 2010. Le premier Build de la 6ème Milestones (la 77ème donc) devrait sortir elle le 3 Décembre prochain.

Source : Devoxx et la page officielle du projet de Java 7

Et vous ? :

Que pensez-vous de ces nouveautés introduites par Java 7 ?

Mise à jour de Gordon Fowler.

Septembre 2009

Bonjour,

adiGuba vient de présenter les modificaitons finales du langage Java 7 introduites par le projet Coin.

Vous pouvez avoir accès à cette liste sur son blog.

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de _skip _skip - Expert éminent http://www.developpez.com
le 01/12/2009 à 10:54
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.
Avatar de adiGuba adiGuba - Expert éminent sénior http://www.developpez.com
le 01/12/2009 à 11:16
Citation Envoyé par _skip  Voir le message
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/

Citation Envoyé par professeur shadoko  Voir le message
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++
Avatar de professeur shadoko professeur shadoko - Membre expérimenté http://www.developpez.com
le 02/12/2009 à 10:08
Citation Envoyé par _skip  Voir le message
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 : Sélectionner tout
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-)
Avatar de _skip _skip - Expert éminent http://www.developpez.com
le 02/12/2009 à 10:15
Citation Envoyé par professeur shadoko  Voir le message
Juste pour t'expliciter le problème: encapsulation et découplage.
soit un code client de cette interface:
Code : Sélectionner tout
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-)

Et quelque chose comme

Code : Sélectionner tout
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?
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 02/12/2009 à 11:10
Citation Envoyé par professeur shadoko  Voir le message
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.
Avatar de professeur shadoko professeur shadoko - Membre expérimenté http://www.developpez.com
le 02/12/2009 à 14:57
Citation Envoyé par pseudocode  Voir le message
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.
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 02/12/2009 à 15:05
Citation Envoyé par professeur shadoko  Voir le message
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 : Sélectionner tout
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
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()); 
}
Avatar de professeur shadoko professeur shadoko - Membre expérimenté http://www.developpez.com
le 16/12/2009 à 11:27
Citation Envoyé par Uther  Voir le message
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!
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 16/12/2009 à 11:36
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.
Avatar de professeur shadoko professeur shadoko - Membre expérimenté http://www.developpez.com
le 16/12/2009 à 14:47
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)
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 16/12/2009 à 15:19
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.
Offres d'emploi IT
Ingénieur développeur .net h/f
Experis Executive - Rhône Alpes - Lyon (69000)
/bin /echo
CodinGame - Ile de France - Montpellier
Développeur javascript confirmé h/f
ACENSI - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -