Discussion :

[richard]

Bonsoir,

J'essaie d'apprendre Java, je suis un "ancien" programmeur Turbo Pascal Pascal Objet - Lazarus (de niveau très moyen), je me remets à la programmation après une bonne douzaine d'années d'arrêt, j'ai choisi Java pour des raisons professionnelles essentiellement mais je ne travaille pas dans le domaine informatique évidemment. Je travaille présentement sur un exercice tiré d'un MOOC.
L'exercice ne me pose pas de problème, en revanche, j'ai un nouveau bug alors que je n'en avais pas, sans aucune modification de mon code je précise.
Je suis sous Linux Ubuntu et j'ai DRJava comme EDI (c'était ce qui était préconisé par le MOOC et c'est simple : ça me va pour apprendre). Je ne demande aucune aide sur l'exercice que j'ai quasiment fini (découper un fichier CSV en trois champs avec vérification du format de saisie) mais je voudrais savoir ce qui se passe pour ce bug.
J'ai effectivement changé quelque chose : au lieu de "compiler" mon programme via DRJava j'ai installé open-JDK.6.0 pour pouvoir le compiler et l'exécuter en dehors de la console de DRJava, depuis dès que je compile mon programme il me met cette erreur que je n'avais pas auparavant (mais je ne sais pas ce qu'il utilisait auparavant pour compiler, hélas). Désolé je suis un peu paumé avec tous ces runtime, JVM, trucs divers, je n'ai pas encore l'habitude mais ça viendra. Cela ne fait que 15 jours que je m'y suis (re)mis.

Voici mon code :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
//Le test fonctionne sur DrJava, mais pour etre reconnu par le correcteur il faut rejeter dans vos tests des formats non conformes comme
//pas de ;
//1 nom sans prenom,
//des dates sans /
//ou des annees à 5 chiffres 
import java.util.Date;
import java.util.Scanner;
 
public class CSV {
 
  public static void main(String[] args){
 
    String ligneCSV;
    Scanner sc = new Scanner(System.in); // creation d'un objet scanner
    ligneCSV = sc.nextLine(); // lecture d'une ligne et sauvegarde dans ligneCSV
 
    int first_comma = ligneCSV.indexOf(";");
    //reste à tester la presence du prenom
 
    String[] data = ligneCSV.split(";"); // découpage en trois sous-chaînes nom / prenom / date
    String nom = data[0];
    String prenom = data[1];
    int l_chaine_nom = nom.length();
    int l_chaine_prenom = prenom.length(); 
    String datestr = data[2];
    String[] dmy = datestr.split("/"); // découpage en trois sous-chaînes jour/mois/année
 
    //test guillemets
    if (nom.charAt(0) != '\"' | nom.charAt(l_chaine_nom-1) != '\"' | prenom.charAt(0) != '\"' | prenom.charAt(l_chaine_prenom-1) != '\"') { 
      // on doit entourer un caractère par de simples quotes ' ' et une string par des doubles " " !
      System.out.println("Erreur de format");
    }
    // test format date
    else if (datestr.length() != 10 | datestr.charAt(2) != '/' | datestr.charAt(5) != '/'){
      System.out.println("Erreur de format");      
    }  
    else {
 
      Integer day = new Integer(dmy[0]);
      int jour = day.intValue();
      Integer month = new Integer(dmy[1]);
      int mois = month.intValue();
      Integer year = new Integer(dmy[2]); 
      int annee = year.intValue();
 
      Date naiss = new Date(annee-1900,mois-1,jour); // création objet date
      System.out.println(nom);
      System.out.println(prenom);
      System.out.println(naiss.toString());
    } // fin else
 
  }
 
}

J'ai vu ici et là que cette exception était liée à un objet non instancié ou une référence invoquée qui avait la valeur "null", bon je comprends le principe je crois, mais je ne vois pas comment il s'applique à mon bout de code. Je me demande vaguement si ce n'est pas lié à l'objet "Scanner", c'est juste une suspicion (il a été donné tel quel dans les consignes de l'exo et je ne sais pas comment il fonctionne). Comme je n'en suis pas sûr et qu'avant ça fonctionnait très bien, je suis dans le brouillard...

Si quelqu'un avait la gentillesse de m'expliquer ce serait super, merci d'avance. Désolé pour cette question sans doute idiote mais je nage, là.

[joel.drigo]

Salut,

C'est une erreur de compilation ou une exception ? Parce que ce n'est pas la même chose. Et dans les deux cas, ce serait bien que tu nous dises laquelle (et pas une interprétation, l'intitulé exact de l'erreur de compilation, ou de l'exception voire la stacktrace de l'exception), et la ligne dans laquelle elle se trouve.

Par ailleurs, pour les dates, tu devrais regarder la classe java.util.SimpleDateFormat.

Pourquoi Java 6 au fait ?

[richard]

Bonsoir,

j'ai ceci comme messages dans la fenêtre du compilo :

1. Compiler is using classPath = '[/home/richard/javadev/exercices, /home/richard/javadev/drjava.jar]'; bootClassPath = 'null'
2. File: (no associated file) [line: (no source location)]
3. Error: java.lang.NullPointerException

Je ne sais pas si cela répond à ta première question; Quant à la seconde, je n'en ai aucune idée, quand je fais un 'java -version' dans ma console voici ce que cela m'affiche :

Code :

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

1
2
3
4
openjdk version "1.8.0_141"
OpenJDK Runtime Environment (build 1.8.0_141-8u141-b15-3~14.04-b15)
OpenJDK 64-Bit Server VM (build 25.141-b15, mixed mode)
richard@richard-MS-7817:~$

Serait-ce la source de mon problème ?

Merci.

[richard]

OK, merci pour cette piste : j'ai supprimé mon kit de dev openJDK 6 et relancé DRJava. Dans la fenêtre du compilateur il affiche désormais : "eclipse compiler 4.5" alors même qu'eclipse n'est pas installé sur ma machine, mais je suppose que DRJava a fait sa propre sauce lors de l'installation.

En tout cas, le bug à la compilation a disparu maintenant. Tout est redevenu normal je peux à nouveau compiler mon programme.

Je n'ai pas compris pourquoi en revanche. Version obsolète et non rétro-compatibilité de mon (minuscule) code j'imagine.

Merci pour l'aide.

[richard]

Par ailleurs, pour les dates, tu devrais regarder la classe java.util.SimpleDateFormat.

Oui, j'ai vu qu'elle était marquée "deprecated", donc obsolète et déconseillée. Mais comme c'est celle qui figurait dans le MOOC du CNAM, et que le correcteur automatique l'attendait manifestement, je l'ai quand même utilisée.
Pour mes futurs programmes en Java je prendrai soin de n'utiliser que les classes "à jour" ce que j'ai toujours fait en Object Pascal. Ça a l'air un peu compliqué avec les mises à jour très rapides et les différentes versions. Bon je n'en suis pas encore là...

Merci encore.

[thelvin]

Hello,

Ça a l'air un peu compliqué avec les mises à jour très rapides et les différentes versions. Bon je n'en suis pas encore là...

C'est une illusion. Les classes obsolètes étaient très vieilles, les classes qui les remplacent commencent à être là depuis un moment, et leur remplacement est arrivé une fois depuis l'existence de Java.
C'est aussi le cas d'autres classes très vieilles pour lesquelles un meilleur remplacement a été proposé une fois depuis que Java existe.

Ce n'est pas tous les jours.

Maintenant, je comprends que quand on apprend, et que le cours dit d'utiliser telle classe, et que le compilateur dit que cette classe est dépréciée, on se sent un peu dépassé par les évènements. Mais c'est juste qu'apprendre, c'est un peu impressionnant. Ça n'a rien à voir avec Java qui évoluerait trop vite, ce n'est pas le cas. Il évolue plutôt que de ne pas le faire du tout, rien de plus.

[richard]

Exact. J'aurais dû écrire "compliqué pour moi".

Après, je ne me suis pas senti perdu, le cours me dit d'utiliser ça, j'utilise ça, c'est juste un moment dans l'apprentissage.

Mais rassure-toi, si j'ai opté pour Java après 20 ans au moins de Pascal impératif et objet, c'est justement pour avoir un langage "moderne" qui colle aux réalités technologiques.

[joel.drigo]

Oui, j'ai vu qu'elle était marquée "deprecated", donc obsolète et déconseillée.

SimpleDateFormat deprecated ? C'est quoi ta plateforme ?

Si à partir de Java 8, il vaut mieux utiliser les classes du package java.time que celles liées à java.util.Date, ces dernières ne sont pas marquées deprecated même en Java 10. D'autant que tu parlais d'utiliser le JDK 6, ce pourquoi je te parlais de cette classe.

Par ailleurs, le constructeur de Integer avec argument String, lui, est déprécié en Java 9 (au profit des méthodes parseInt() et valueOf() de Integer).

Bonsoir,

j'ai ceci comme messages dans la fenêtre du compilo :

1. Compiler is using classPath = '[/home/richard/javadev/exercices, /home/richard/javadev/drjava.jar]'; bootClassPath = 'null'
2. File: (no associated file) [line: (no source location)]
3. Error: java.lang.NullPointerException

A priori, tu lances la compilation et l'exécution avec un lanceur spécifique et non les exécutables du JDK (javac.exe et java.exe), ou peut-être une configuration spécifique de build liée à drjava, que je ne connais pas (mais qui utilise peut-être un fichier pour simuler l'entrée standard (System.in)).
[reflexion]C'est toujours pareil avec ces trucs censés simplifier Java (DRJava, Java's Cool, Processing...) : ils ajoutent ou modifient des comportements, impliquent donc des comportements non standard, et donc finalement ne simplifient rien du tout. Et difficile pour ceux qui font du Java standard de savoir pourquoi ça ne fonctionne pas normalement et difficile pour les néophytes de savoir que ce n'est pas vraiment du Java qu'ils font. Et la différence de comportement peut être introduite par la version de l'API et la plateforme (par exemple le Java Android, qui est très différent de JavaSE par son API, au point de m'apparaître comme un langage différent avec la même syntaxe). [/reflexion]

[richard]

Bonjour,

SimpleDateFormat deprecated ? C'est quoi ta plateforme ?

Linux Ubuntu 16 (ou Debian sur un autre PC).

Si à partir de Java 8, il vaut mieux utiliser les classes du package java.time que celles liées à java.util.Date, ces dernières ne sont pas marquées deprecated même en Java 10. D'autant que tu parlais d'utiliser le JDK 6, ce pourquoi je te parlais de cette classe.

Je me suis mal exprimé sans doute : je parlais de Java.Util.Date qui était notée comme obsolète (deprecated)

Par ailleurs, le constructeur de Integer avec argument String, lui, est déprécié en Java 9 (au profit des méthodes parseInt() et valueOf() de Integer).

Merci, j'ai vu ça aussi dans la doc que j'ai consulté : Java 5 & 6 de Delannoy, un peu ancien, mais bon pour l'instant ça fera l'affaire avec le fabuleux travail de M. Doudoux en plus. Mais il s'agissait des opérateurs de cast qui étaient présentés dans le cours donc à utiliser...

A priori, tu lances la compilation et l'exécution avec un lanceur spécifique et non les exécutables du JDK (javac.exe et java.exe), ou peut-être une configuration spécifique de build liée à drjava, que je ne connais pas (mais qui utilise peut-être un fichier pour simuler l'entrée standard (System.in)).

Oui, je suis arrivé plus ou moins à cette conclusion mais sans ta précision dans le diagnostic évidemment.

[reflexion]C'est toujours pareil avec ces trucs censés simplifier Java (DRJava, Java's Cool, Processing...) : ils ajoutent ou modifient des comportements, impliquent donc des comportements non standard, et donc finalement ne simplifient rien du tout.

Je suis d'accord, bien entendu. Juste une chose, Processing c'est vraiment un langage dédié à la création graphique et plastique, je l'utilise (un peu) dans des projets de créativité et d'arts graphiques, donc c'est très spécifique et nécessite pour vraiment l'utiliser d'avoir des connaissances dans la création plastique même si on peut sans doute l'utiliser pour autre chose. Les créateurs sont des plasticiens et il est enseigné essentiellement aux Beaux-Arts et dans les écoles d'art, c'est un outil spécifique donc c'est un peu normal qu'il ait un comportement particulier (je ne suis pas spécialiste mais je compte probablement le devenir pour des raisons professionnelles d'où un intérêt supplémentaire pour l'apprentissage de Java ).

[joel.drigo]

Processing c'est vraiment un langage dédié à la création graphique et plastique

Ce que je voulais évoquer en citant Processing, comme les autres, c'est qu'il y'a beaucoup de questions dans ce forum sur des problèmes en Processing par des personnes qui pensent que comme c'est du Java, on pourra y répondre. N'y connaissant rien en Processing, je suis bien incapable de donner une solution à leur problème qui fonctionnerait alors que la solution Java que je pourrais donner, et qui est peut être toute simple, ne serait pas applicable et pas compréhensible (donc pas adaptable).

[joel.drigo]

Je me suis mal exprimé sans doute : je parlais de Java.Util.Date qui était notée comme obsolète (deprecated)

Le constructeur à trois arguments en fait (avec d'autres constructeurs, et d'ailleurs tu as dû faire des "bidouilles" pour t'en servir).

Il semble que SimpleDateFormat soit déprécié sur certains environnements dédiés au développement pour mobile. Par ailleurs, SimpleDateFormat est connue pour des bugs en environnement multi-thread (parce que le parsing est stateful) et les développeurs ont tendance à utiliser un final static.