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

Langage Java Discussion :

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


Sujet :

Langage Java

  1. #1
    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 : 38
    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 611
    Points
    7 611
    Par défaut 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?

  2. #2
    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 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    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++

  3. #3
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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!

  4. #4
    Nouveau Candidat au Club
    Inscrit en
    novembre 2008
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Un article assez détaillé (et en français) sur les nouvelles librairies :

    http://blog.octo.com/index.php/2008/...es-dans-java-7

  5. #5
    Expert éminent
    Avatar de djo.mos
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2004
    Messages : 4 666
    Points : 7 668
    Points
    7 668
    Par défaut
    Salut,
    N'oublies pas aussi que plusieurs des probables nouveautés sont débattues ici : http://www.developpez.net/forums/f10...e-java/debats/

  6. #6
    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 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    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++

  7. #7
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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#.

  8. #8
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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 : 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
    try
    {
         obj = ...;
         .... ;
    } 
    finally
    {
        if( obj != null && obj.isOpen() )
        {
            try
            { 
                obj.close();
            }
            catch( ...)
            {
            }
        }
    }

  9. #9
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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!)

  10. #10
    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 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par _skip Voir le message
    -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, ...).

    Citation Envoyé par _skip Voir le message
    -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.

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

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

    a++

  11. #11
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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.

  12. #12
    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 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par _skip Voir le message
    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 Voir le message
    Mais c'est mon impression personnelle, pas d'offenses.
    Il n'y a pas de problème (au contraire )



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

  13. #13
    Membre émérite
    Avatar de gifffftane
    Profil pro
    Inscrit en
    février 2007
    Messages
    2 354
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : février 2007
    Messages : 2 354
    Points : 2 582
    Points
    2 582
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Mieux que Google, utilisez Sur Java spécialisé sur la plate-forme java !
    Pour réaliser vos applications Java dans le cadre de prestations, forfait, conseil, contactez-moi en message privé.

  14. #14
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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?

  15. #15
    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 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par gifffftane Voir le message
    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 Voir le message
    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 Voir le message
    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++

  16. #16
    Membre émérite
    Avatar de gifffftane
    Profil pro
    Inscrit en
    février 2007
    Messages
    2 354
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : février 2007
    Messages : 2 354
    Points : 2 582
    Points
    2 582
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    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

    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.
    Mieux que Google, utilisez Sur Java spécialisé sur la plate-forme java !
    Pour réaliser vos applications Java dans le cadre de prestations, forfait, conseil, contactez-moi en message privé.

  17. #17
    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 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par gifffftane Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    class MyBeans {
     
    	public final String name;
     
    	public MyBeans(String name) {
    		this.name = name;
    	}
    }
    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 : 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
    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 ?
    	}
    }
    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. #18
    Membre émérite
    Avatar de gifffftane
    Profil pro
    Inscrit en
    février 2007
    Messages
    2 354
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : février 2007
    Messages : 2 354
    Points : 2 582
    Points
    2 582
    Par défaut
    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.
    Mieux que Google, utilisez Sur Java spécialisé sur la plate-forme java !
    Pour réaliser vos applications Java dans le cadre de prestations, forfait, conseil, contactez-moi en message privé.

  19. #19
    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 : 38
    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 611
    Points
    7 611
    Par défaut
    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.

Discussions similaires

  1. Quelles sont les nouveautés de Zend Core 2 ?
    Par piour dans le forum Zend
    Réponses: 4
    Dernier message: 21/09/2012, 17h26
  2. Réponses: 0
    Dernier message: 27/04/2006, 13h00
  3. Réponses: 0
    Dernier message: 27/04/2006, 13h00
  4. [CR10]Quelles sont les nouveautés de la version 10 ?
    Par osoudee dans le forum SAP Crystal Reports
    Réponses: 3
    Dernier message: 11/11/2004, 17h37

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