IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Événements Java Discussion :

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


Sujet :

Événements Java

  1. #61
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

  2. #62
    Membre à l'essai
    Inscrit en
    Novembre 2009
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : Novembre 2009
    Messages : 13
    Points : 21
    Points
    21
    Par défaut
    Citation Envoyé par Uther Voir le message
    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....

  3. #63
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    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.

  4. #64
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Le site sur le language java 7 est ici
    https://jdk7.dev.java.net/

  5. #65
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    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)

  6. #66
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    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.

  7. #67
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    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++

  8. #68
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    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 - Visualiser dans une fenêtre à part
    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-)
    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)

  9. #69
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    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 - Visualiser dans une fenêtre à part
    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 - 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?

  10. #70
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  11. #71
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    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.
    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)

  12. #72
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    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 - 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.

  13. #73
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    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!
    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)

  14. #74
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

  15. #75
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    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)

  16. #76
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

Discussions similaires

  1. Sait-on quelles seront les nouveautés de java 7
    Par _skip dans le forum Langage
    Réponses: 18
    Dernier message: 18/02/2009, 13h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo