Discussion :

[adiGuba]

y'a des printf'maniacs

Et oui !
Je n'ai jamais trop aimé le println() ni le cout du C++...

Et un exemple métier, vous avez ?
Une classe qu'on code pour couvrir un besoin utilisateur, si vous préférez..

Je ne pense pas que l'ellipse couvre un besoin utilisateur...
Elle permet de simplifier légèrement la tache de du developpeurs avec un code plus clair (la création du tableau est induite)...

a++

[adiGuba]

Toujours a propos de l'ellipse...

En parcourant l'API 1.5 je me suis apercut qu'un grand nombre de méthode avec un tableau en paramètre utilisent désormais une ellipse à la place.
C'est le cas par exemple des methodes getConstructor(), getMethod() de la classe Class...

Après quelques test j'ai remarqué le comportement suivant :

La méthode de l'article:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void doSomething(Object… args)
{
  // do something
 
}

Peut également être utilisé comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Object[] args = new Object[] { "arg1", "arg2", "arg3" };
doSomething ( args );

En fait l'ellipse possède la même signature qu'un tableau...
Si on essaye de déclarer une méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void doSomething(Object[] args)
{
  // do something
}

On obtient l'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

doSomething(java.lang.Object[]) is already defined

a++

[Melchisedec]

Moi je ne vois pas la pertinence des import statiques.
Selon l'article de Lionel Roux, les imports statiques permettent d'éviter le préfixage des attributs ou méthodes statiques par le nom de leur classe.
Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
import static java.lang.Math.cos
public class MyClass {
 
private double x;
MyClass(double x){
this.x=cos(x);//au lieu de this.x=Math.cos(x);
}

}
Franchement, je ne vois pas la perte de temps ou le problème entrainé par le préfixage qu'on avait l'habitude faire au paravant. D'ailleurs je trouve que cette nouveauté va introduire au contraire des erreurs si il ya conflit entre les imports.

[os9]

Salut tout le monde,

Bon voilà, je vient juste de télécharger J2SE 5.0. Avant je travaillait tjs avec l'ancien 1.4.2 .

Alors, après quelques mois de vie du nouveau né de Sun (il a bien garandit depuis à mon avis ), j'aimerai bien avoir votre avis sur les nouveautés qui ont été annoncé ? est ce qu'elle répondent bien aux attentes ? Enfin, nous partager votre avis sur J2SE 5.0...


Merci à tous.

[yveslamand]

Je n'ai pas encore pu travailler de façon professionnelle sur la version 5.0. Il faut le temps avant qu'un grand compte passe en version 5.0 -(

Ce que j'en ai vu était plutôt positif. Vive l'autoboxing ! Et, enfin, on va pouvoir utiliser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf(...)

. En ce qui concerne les imports statiques, je connais pas, mais je trouve cela dangereux et je ne trouve pas cela génant d'ajouter les imports (surtout en utilisant Eclipse).

[Original Prankster]

Pour moi (et surement pour tous ceux qui viennent du C) l'ajout de la méthode printf() est une très bonne nouvelle parcequ'elle permet de formater simplement des données...

Justement ! Le C est quand même révolu notamment avec les langages orientés objet qui ont pris la relève, tels C++ ou... Java !!! Et oui, rappelons que Java est également un langage orienté objet, et la plupart des améliorations du langage mentionnées dans l'article sont toutes inspirées du C, qui n'en est pas un ! Pour l'exemple :
type enum
printf
ellipse

Sans parler de l'autoboxing qui facilite la programmation aux dépends de la sûreté des programmes !! Seul ADA à ce jour (parmi les langages les + connus du moins) offre un typage fort permettant d'écrire des applications assurant une certaine sécurité. C'est d'ailleurs ce langage qui est utilisé dans le cadre d'applications concernant Ariane ou la ligne Météore. Pourtant (bien que lent) Java est très puissant et mérite sa place dans les applications importantes, notamment au niveau de la programmation distribuée... Alors pourquoi lui apporter de nouvelles limites ?? Pour aider les "informaticiens non chevronnées" ?

De surcroît, la nouvelle boucle for est annoncée comme étant simplifiée... Je ne m'y suis pas plongé dedans, mais à première vue (pour quelqu'un habitué au C++ du moins) elle me semble plus complexe, simplement parce que le concept change. A étudier de plus près avant de poursuivre l'argumentation...

En revanche, la généricité c'est une bonne nouvelle, que les programmeurs céplusplussiens attendaient avec impatience depuis longtemps...

Sérieusement, je ne sais pas mais je suis plutôt déçu (non pas de la qualité de l'article, mais des nouvelles que j'ai pu y trouver) d'être déçu, parce que Java est un langage que j'estime beaucoup alors que ce n'est pas le cas pour le C (désolé, commencer de façon intensive en C++, ça aide ).

J'espère juste que je suis en train d'en faire un plat pour rien, et qu'à force d'utilisation et d'expérience, ces "améliorations" deviendront naturelles...

[Original Prankster]

Sans vouloir polémiquer, une méthode qui accepterait des arguments en nombre variable me semble une "erreur de conception".
Peux-tu me donner un exemple où ce besoin existe ?

Facile, l'exemple de la méthode printf en C :

printf("Ceci est un %s de chaine avec %d %s variables", exemple, 3, arguments)

Et une redirection de flux c'est pas légèrement beaucoup plus simple ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cout >> "Ceci est un " >> exemple >> " de chaîne avec " >> 3 >> arguments >> " variables" >> endl;

Je n'ai jamais trop aimé le println() ni le cout du C++...

Pourtant c'est beaucoup plus intuitif qu'un printf() : pas besoin de chercher comment on représente un string (%s) ni un double (%d), et tout est dans l'ordre dans lequel on le dirait oralement !! C'est presque du flux de paroles !!

[yveslamand]

En C, j'ai souvent utilisé printf (normal), mais c'est sprintf qui me manque le plus. Pour faire un formatage de string de façon simple, c'est très bien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sprintf(buffer,"%20s %.4d",pszStr,iValue);

Pour moi, Java est un langage génial. Le C est aussi un super langage, mais pas pour faire la même chose. Je ne pense pas qu'un langage puisse être universel. Chaque langage a ses domaines de prédilections.

[adiGuba]

Salut,


Personnellement, je ne pense pas que le C soit un langage révolu... mais de toute façon ce n'est pas parce que certaines des améliorations viennent du C qu'elles sont forcément mauvaise...

Le type enum apporte une sécurisation du code, et évite ainsi de recourir à des constantes static final int peu fiable (rien n'empêche de passer une valeur 'en dur'). De plus le type enum de Java est bien un objet et n'est plus vraiment comparable au type enum du C...

Le printf() (et la classe Formatter associé) est surtout utile pour le formattage. L'opérateur + (ou << du C++) est pratique pour concaténer, mais dès que l'on souhaite utiliser un formatage spécifique cela devient plus complexe. Bien sûr cela ne concerne que la génération de fichier texte pur

L'elipse est juste une nouvelle manière de déclarer des méthodes avec un tableau en paramètre. Elle permet ainsi de simplifier l'utilisation de certaines méthodes. Je trouve d'ailleurs qu'elle n'est pas encore assez utiliser dans l'API : une petite méthode add(E...elements) aurait été bien pratique dans l'interface List, cela permettrai de remplacer le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
List<String> list = new ArrayList<String>();
list.add("chaine1");
list.add("chaine2");
list.add("chaine3");
list.add("chaine4");

Par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
List<String> list = new ArrayList<String>();
list.add("chaine1", "chaine2", "chaine3","chaine4");

Sans parler de l'autoboxing qui facilite la programmation aux dépends de la sûreté des programmes !!

Le seul problème à ma connaissance est le risque de NullPointerException lors de l'auto-unboxing (Wrapper->primaire)... mais cela ne me choque pas (le problème peut également exister sans autoboxing...)

De surcroît, la nouvelle boucle for est annoncée comme étant simplifiée...

En fait elle permet simplement d'itérer sur des tableaux ou sur des objets Iterable (c'est à dire qui retourne un Iterator) de la même manière, tout en initialisant les différentes valeurs...

J'espère juste que je suis en train d'en faire un plat pour rien, et qu'à force d'utilisation et d'expérience, ces "améliorations" deviendront naturelles...

Je pense aussi qu'il faut un temps d'adaptations...
Personnellement j'étais très sceptique quand à l'utilisation du static import, et je me surprent à l'utiliser plus souvent que je ne le pensais

a++

[Original Prankster]

Pour moi, Java est un langage génial. Le C est aussi un super langage, mais pas pour faire la même chose. Je ne pense pas qu'un langage puisse être universel. Chaque langage a ses domaines de prédilections.

Je pense aussi que C est un bon langage, dans le sens où il a révolutionné le monde de la programmation. Mais désormais il a évolué pour donner naissance au C++, qui est bien plus performant...

Et justement, si chaque langage a son domaine de prédilection (ce que je pense aussi), pourquoi faire ressembler un langage comme Java à un autre langage (qui plus est obsolète) ? On perdrait ainsi en spécificité... Non ?

[yveslamand]

Beaucoup de développeurs Java étaient avant des développeurs C (il suffit de regarder les catalogues des sociétés de formation. Ils ont souvent 2 cours: "Java for C programmers" et "Java for non-C programmers").

La ressemblance est au niveau des mots clés, par du langage en lui-même. int représente un entier, for = un boucle, ...

Par contre, pas d'objet en C, pas d'héritage, ...

A partir de là, donner le même nom pour des méthodes identiques semblent logique. Pas besoin de réinventer la roue ...

[Original Prankster]

donner le même nom pour des méthodes identiques semblent logique. Pas besoin de réinventer la roue ...

Le problème est bien là, d'après moi : des "méthodes identiques"

Personnellement, je ne pense pas que le C soit un langage révolu... mais de toute façon ce n'est pas parce que certaines des améliorations viennent du C qu'elles sont forcément mauvaise...

En revanche, je reconnais que le langage C n'est pas mauvais. Je dis juste qu'il a permis d'inventer des langages plus évolués, et que par conséquent, lui, il l'est moins

De plus le type enum de Java est bien un objet et n'est plus vraiment comparable au type enum du C...
Le printf() (et la classe Formatter associé) est surtout utile pour le formattage.
L'elipse est juste une nouvelle manière de déclarer des méthodes avec un tableau en paramètre.

Le type enum évidemment est un objet mais dans tous les cas reste fort pratique, pas de soucis la-dessus. En ce qui concerne le printf() et l'elipse je trouve ça moins "beau" mais ne dénigre tout de même pas leur utilité. Et oui, le soucis de la beauté du code...

[yveslamand]

donner le même nom pour des méthodes identiques semblent logique. Pas besoin de réinventer la roue ...

Le problème est bien là, d'après moi : des "méthodes identiques"

Faut pas exagérer. En C, on utilise accept() pour écouter sur une socket, idem en Java.

Remarque, ce serait peut-être mieux de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
new ServerSocket().addSocketListener(new SocketListener() {
	public void sockectConnected(SocketEvent arg0) {
		// ...		
}});

[pitoubicou]

Pour moi, le C reste tout de même le langage bas niveau. Il reste quand même beaucoup plus rapide que le Java (à quand une JVM plus rapide ??? ) et il n'a pas son pareil pour tenir dans un petit µP 8bits.

Donc, pour moi le C est loin d'être un langage révolu, en tout cas pour le monde de l'embarqué !!!

Le JAVA c'est bien quand même , et puis c'est plus simple (pas de pointeurs... !!!

[Deadpool]

Halte aux idées reçus :

Si, il y a bien des pointeurs en Java. En revanche, c'est l'arithmétique des pointeurs qui a été supprimée.

[Original Prankster]

On pourrait même rajouter : en Java il n'y a QUE des pointeurs... Mais c'est transparent à l'utilisateur

[Deadpool]

Non, il n'y a pas que des pointeurs. Les types primitifs t'en fait quoi? Essaie d'affecter null à un int, tu vas voir ce que le compilo va te dire!

[Original Prankster]

Sans déconner... Je parlais de Java, bien sûr, par des "artefacts C" de Java.

[sgourio]

Bonjour,
alors voilà, 2 ans après la sortie du jdk5, j'aimerais avoir vos retours sur les types génériques.
Pour ma part j'en ai marre de faire de toujours avoir à faire des cast dans le code, et je trouve que les génériques permettent d'éviter pas mal d'erreurs avant l'exécution.
Cependant je contaste que très peu d'api ont utiliser les fonctionnalités du jdk5 (pas de générique dans struts, ni dans jsf, ni dans hibernate, ni même dans spring)... Les utilisez-vous ces fameux génériques?

[adiGuba]

Cependant je contaste que très peu d'api ont utiliser les fonctionnalités du jdk5 (pas de générique dans struts, ni dans jsf, ni dans hibernate, ni même dans spring)... Les utilisez-vous ces fameux génériques?

Le monde de l'entreprise est assez "frilleuse" : elle préfère resté sur des technologie éprouvé et bien maitrisé et attendre avant de faire évoluer les choses...

Ainsi, J2SE 1.4 est encore très utilisé (de même que le 1.3 d'ailleurs).
Surtout que J2EE 1.4 fonctionne avec ces JRE, alors que Java EE 5.0 qui neccessite Java 5.0 est bien trop jeune...

Or, si les nouveautés de Java 5.0 sont très intérressante, le bytecode généré n'est pas compatible et neccessite une JVM 5.0...

Ainsi, si une API passe en Java 5.0 et utilise les nouveautés du langage, elle se "sépare" d'une grande partie de sa cible.

C'est pourquoi la plupart des API n'ont pas encore été migré : elle offre une meilleure compatibilité avec les JVM plus anciennes...

Il faudra attendre que Java 5.0 devienne la "norme" en entreprise pour voir les API externe migrer petit à petit...

Surtout que cette migration a un coût, et que la maintenance de deux versions l'est encore plus

a++