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

NetBeans Java Discussion :

comportement différent "java en ligne de commande" et "java via netbeans"


Sujet :

NetBeans Java

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut comportement différent "java en ligne de commande" et "java via netbeans"
    Bonjour à tous,

    je bloque sur un problème. J'ai un comportement différent de mon programme avec les 2 modes de lancement suivants :
    1) je le lance dans une console avec la commande "java -jar monProg.jar"
    2) je le lance via netbeans

    Pour être plus précise, je lance mon programme, je regarde le fichier de log dans lequel il écrit (le programme écrit des octets, donc j'ouvre mes logs avec un editeur hexadecimal) et là je m'aperçois que les octets sont différents (selon le mode de lancement) alors qu'ils devraient être identiques.

    Quelqu'un aurait-il une idée svp ?

    Merci

  2. #2
    Membre averti

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2010
    Messages
    246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2010
    Messages : 246
    Points : 402
    Points
    402
    Par défaut
    Cela manque cruellement de détail.

    Les octets de quoi ? qu'est-ce qui est écrit ? quelle est la différence ? qu'exécute tu comme programme ? il nous faut des infos...

    Car sinon comme ca, il ne me semble pas aberrant qu'il puisse y avoir des octets différents sur un fichier géneré... ce serait-ce que par exemple si il contient la date ou l'heure de la compilation....
    C'est en aidant les autres qu'on en apprend beaucoup soi-même

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    et bien ce sont des octets en dur dans mon code donc ce sont des données fixes, qui devraient être tout le temps les mêmes.

    Quand je lance en ligne de commande j'ai (en hexadecimal):
    03 00 00 88

    Quand je lance via netbeans j'ai :
    03 00 00 ef bf bd

    alors que ça devrait être la même chose...

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    ça ne pourrait pas être parce que peut-être sans le savoir j'utilise des versions différentes de java selon que je suis en ligne de commande ou bien avec netbeans ?

  5. #5
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par _LittleFlea_ Voir le message
    ça ne pourrait pas être parce que peut-être sans le savoir j'utilise des versions différentes de java selon que je suis en ligne de commande ou bien avec netbeans ?
    Vraiment si tu nous donnais le bout de code fautif (au mieux un exemple minimaliste qui reproduit le problème et compile) on pourrait vraiment mieux t'aider.

  6. #6
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 552
    Points : 21 608
    Points
    21 608
    Par défaut
    Dans ces cas-là, il faut soupçonner une différence dans les choses qui dépendent de l'environnement.

    Qu'est-ce qui, typiquement, dépend de l'environnement ?

    - par exemple, le charset par défaut ?

    => 0x88 est, en windows-1252, une sorte d'accent circonflexe. Il est mappé en Unicode à U+02C6 (MODIFIER LETTER CIRCUMFLEX ACCENT), une sorte de marqueur phonétique. Je ne suis pas sûr de comprendre ce que c'est censé être.

    => 0xEF BF BD est la représentation UTF-8 détestée mais bien connue de l'unicode U+FFFD (REPLACEMENT CHARACTER), le caractère utilisé pour dire "ici on n'a pas su décoder le caractère." Il est notamment utilisé en Java quand on lui demande de construire un flux de caractères à partir d'un flux d'octets et que certains octets sont incompatibles avec le charset de décodage. Par exemple en trouvant un octet 0x88 entouré d'ASCII dans le flux, qu'on essaie pourtant de décoder comme UTF-8.

    Conclusion : en ligne de commande le charset par défaut est windows-1252, et via Netbeans le charset par défaut est UTF-8. La première hypothèse était la bonne.
    Je suis sûr que Netbeans peut être configuré pour démarrer avec un autre charset par défaut.

    Conclusion 2 : ceci est l'une des nombreuses raisons pour lesquelles il ne faut jamais coder quelque chose qui dépend du charset par défaut. Montre ton code, nous te dirons comment l'éviter.

    --
    thelvin, grand joueur de Phoenix Wright : Ace Attorney et Miles Edgeworth Investigations
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Dans ces cas-là, il faut soupçonner une différence dans les choses qui dépendent de l'environnement.

    Qu'est-ce qui, typiquement, dépend de l'environnement ?

    - par exemple, le charset par défaut ?

    => 0x88 est, en windows-1252, une sorte d'accent circonflexe. Il est mappé en Unicode à U+02C6 (MODIFIER LETTER CIRCUMFLEX ACCENT), une sorte de marqueur phonétique. Je ne suis pas sûr de comprendre ce que c'est censé être.

    => 0xEF BF BD est la représentation UTF-8 détestée mais bien connue de l'unicode U+FFFD (REPLACEMENT CHARACTER), le caractère utilisé pour dire "ici on n'a pas su décoder le caractère." Il est notamment utilisé en Java quand on lui demande de construire un flux de caractères à partir d'un flux d'octets et que certains octets sont incompatibles avec le charset de décodage. Par exemple en trouvant un octet 0x88 entouré d'ASCII dans le flux, qu'on essaie pourtant de décoder comme UTF-8.

    Conclusion : en ligne de commande le charset par défaut est windows-1252, et via Netbeans le charset par défaut est UTF-8. La première hypothèse était la bonne.
    Je suis sûr que Netbeans peut être configuré pour démarrer avec un autre charset par défaut.

    Conclusion 2 : ceci est l'une des nombreuses raisons pour lesquelles il ne faut jamais coder quelque chose qui dépend du charset par défaut. Montre ton code, nous te dirons comment l'éviter.

    --
    thelvin, grand joueur de Phoenix Wright : Ace Attorney et Miles Edgeworth Investigations
    Merci pour ta réponse, ceci dit juste une précision, je lance en ligne de commande depuis linux...

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    et 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
    public static void main(String[] args) throws IOException {
            PropertyConfigurator.configure("/data/conf/SimulateurTPEBouchonLogger.conf");
     
            ServerSocket s = new ServerSocket(port);
            Socket soc = s.accept();
     
            // Un BufferedReader permet de lire par ligne.
            InputStream in = new DataInputStream(soc.getInputStream());
     
            byte trameRFC1086[] = new byte[49];
            byte coucheRFC1006[] = new byte[4];
            byte tab[] = new byte[1000];
     
            //lecture de la trame de connexion (RFC1086) : 48 + 1 octets
            in.read(trameRFC1086, 0, 49);
     
            //lecture de la couche RFC1006 : 4 octets
            in.read(coucheRFC1006, 0, 4);
     
            System.out.write(trameRFC1086);
            FilterOutputStream fos = new PrintStream(new LoggingOutputStream(logger, Level.INFO),true);
            fos.write(trameRFC1086);
     
     
            System.out.write(coucheRFC1006);
            FilterOutputStream fos2 = new PrintStream(new LoggingOutputStream(logger, Level.INFO),true);
            fos2.write(coucheRFC1006);
     
     
            int nb = coucheRFC1006[3] & 0xFF;
            nb += (coucheRFC1006[2] & 0xFF) * 256;
     
            in.read(tab, 0, nb);
     
            System.out.println(nb);
     
            in.close();
            soc.close();
        }

  9. #9
    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
    Salut,

    • Tes commentaires ne sont pas cohérents avec ton code (Tu parles de BufferedReader là où tu utilises des DapaInputStream).
    • Le DataInputStream est totalement inutile dans le code que tu nous as présenté : autant utiliser directement l'InputStream de la socket. Même chose pour le PrintStream !
    • Attention à tes méthodes de lecture : read() ne garantie pas que toutes les données soit bien lu. Par exemple selon la charge réseau tu pourrais ne recevoir qu'une partie des infos. Il faut vérifier la valeur de retour !!!
    • Il manque tous les try/finally pour la fermeture des flux !!!



    Enfin il faudrait plus de détail sur ce LoggingOutputStream...


    a++

  10. #10
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 552
    Points : 21 608
    Points
    21 608
    Par défaut
    Important aussi, on n'envoie jamais du binaire dans un logger.

    Déjà qu'envoyer du binaire dans un PrintStream, je trouve que ça manque de rigueur...
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #11
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Important aussi, on n'envoie jamais du binaire dans un logger.

    Déjà qu'envoyer du binaire dans un PrintStream, je trouve que ça manque de rigueur...
    d'accord mais là le but du projet est d'envoyer des données binaires sur une socket, et je dois tracer tout ce qui est envoyé. Donc je dois bien écrire du binaire dans mes log. Ensuite je contrôle mes logs avec un éditeur hexadécimal.

    Si il y a une meilleure façon de faire je suis preneuse

  12. #12
    Membre averti

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2010
    Messages
    246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2010
    Messages : 246
    Points : 402
    Points
    402
    Par défaut
    On s'approche d'informations exploitables...

    Pourrais-tu nous décrire précisement ce que tu cherche à faire en fait ? le type de données manipulés, etc.

    Car parfois, on pense avoir une bonne piste et on demande de l'aide sur cette piste, alors que le fait d'exposer clairement le problème peut amener les personnes à penser à une meilleure solution que celle que tu as envisagé.

    Avec la description de ce que tu souhaites faire, on sera plus à même de t'aider.
    C'est en aidant les autres qu'on en apprend beaucoup soi-même

  13. #13
    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
    un log, c'est destiné à recevoir du texte, point! Si tu veux y mettre la trace de test données, commence par les convertir en texte, par exemple, si les byte sont 1,89,154, envoie vers ton log "1,89,154". De plus, on utilise les logger comme ça:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
         logger.info("reçu trame connexion "+Arrays.deepToString(trameRFC1086));
         logger.info("reçu couche RFC "+Arrays.deepToString(coucheRFC1006));

    Donc, non, on écrit pas du binaire dans des logs textuels. Et transformé en texte, c'est bien plus lisible. Si vous voulez des logs binaire, créez les vous même, et ne les mélangez pas avec du texte!!

  14. #14
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    un log, c'est destiné à recevoir du texte, point! Si tu veux y mettre la trace de test données, commence par les convertir en texte, par exemple, si les byte sont 1,89,154, envoie vers ton log "1,89,154". De plus, on utilise les logger comme ça:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
         logger.info("reçu trame connexion "+Arrays.deepToString(trameRFC1086));
         logger.info("reçu couche RFC "+Arrays.deepToString(coucheRFC1006));

    Donc, non, on écrit pas du binaire dans des logs textuels. Et transformé en texte, c'est bien plus lisible. Si vous voulez des logs binaire, créez les vous même, et ne les mélangez pas avec du texte!!
    d'accord, vous avez surement raison.

    afin de convertir un tableau de byte en String, j'utilise cette focntion :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    public static String getHexString(byte[] b) {
    		String result = "";
    		for (int i = 0; i < b.length; i++) {
    			result += Integer.toString((b[i] & 0xff) + 0x100, 16).substring(1) + " ";
    		}
    		return result;
    	}
    A votre avis, elle est correcte ? Car maintenant s'il y a aussi une erreur lors de l'affichage de mes octets en String, on ne va pas s'en sortir
    et j'avoue je ne suis pas à l'aise avec le binaire et java (vu qu'un byte est signé en java alors qu'en c, on utilise unsigned char et ce n'est pas signé.)

  15. #15
    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
    c'est quoi ce "+ 0x100" et ce substring?? Vous vous tordez les méninges là
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    public static String getHexString(byte[] tableau) {
      StringBuilder sb = new StrinbBuilder(b.length*3);
      for (byte b : tableau){
         sb.append(String.format("%02X ",  ((int)b) & 0xff));
      }
      return sb.toString();
    }

  16. #16
    Membre du Club
    Profil pro
    Inscrit en
    Août 2009
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2009
    Messages : 155
    Points : 45
    Points
    45
    Par défaut
    bon alors là mystère... en transformant mon tableau de byte en String (en hexadécimal) dans mes logs, là j'obtiens la même chose, que je lance mon programme dans le shell ou bien via netbeans

    pour ceux que ça intéresse, voilà la classe LoggingOutputStream que j'utilisais (classe trouvée sur internet) :
    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
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    /*
     * To change this template, choose Tools | Templates
     * and open the template in the editor.
     */
     
    package org.apache.log4j.contribs;
     
    /*
     * Licensed to the Apache Software Foundation (ASF) under one or more
     * contributor license agreements.  See the NOTICE file distributed with
     * this work for additional information regarding copyright ownership.
     * The ASF licenses this file to You under the Apache License, Version 2.0
     * (the "License"); you may not use this file except in compliance with
     * the License.  You may obtain a copy of the License at
     *
     *      http://www.apache.org/licenses/LICENSE-2.0
     *
     * Unless required by applicable law or agreed to in writing, software
     * distributed under the License is distributed on an "AS IS" BASIS,
     * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     * See the License for the specific language governing permissions and
     * limitations under the License.
     */
     
     
    import java.io.*;
    import org.apache.log4j.*;
     
     
    /**
     * An OutputStream that flushes out to a Category.<p>
     *
     * Note that no data is written out to the Category until the stream is
     *   flushed or closed.<p>
     *
     * Example:<pre>
     * // make sure everything sent to System.err is logged
     * System.setErr(new PrintStream(new LoggingOutputStream(Category.getRoot(), Priority.WARN), true));
     *
     * // make sure everything sent to System.out is also logged
     * System.setOut(new PrintStream(new LoggingOutputStream(Category.getRoot(), Priority.INFO), true));
     * </pre>
     *
     * @author <a href="mailto://Jim.Moore@rocketmail.com">Jim Moore</a>
     * @see Category
     */
    public class LoggingOutputStream extends OutputStream {
      protected static final String LINE_SEPERATOR = System.getProperty("line.separator");
     
     
      /**
       * Used to maintain the contract of {@link #close()}.
       */
      protected boolean hasBeenClosed = false;
     
      /**
       * The internal buffer where data is stored.
       */
      protected byte[] buf;
     
      /**
       * The number of valid bytes in the buffer. This value is always
       *   in the range <tt>0</tt> through <tt>buf.length</tt>; elements
       *   <tt>buf[0]</tt> through <tt>buf[count-1]</tt> contain valid
       *   byte data.
       */
      protected int count;
     
     
      /**
       * Remembers the size of the buffer for speed.
       */
      private int bufLength;
     
      /**
       * The default number of bytes in the buffer. =2048
       */
      public static final int DEFAULT_BUFFER_LENGTH = 2048;
     
     
      /**
       * The category to write to.
       */
      protected Category category;
     
      /**
       * The priority to use when writing to the Category.
       */
      protected Priority priority;
     
     
      private LoggingOutputStream() {
        // illegal
      }
     
     
      /**
       * Creates the LoggingOutputStream to flush to the given Category.
       *
       * @param cat        the Category to write to
       *
       * @param priority   the Priority to use when writing to the Category
       *
       * @exception IllegalArgumentException
       *                   if cat == null or priority == null
       */
      public LoggingOutputStream(Category cat, Priority priority)
      throws IllegalArgumentException {
        if (cat == null) {
          throw new IllegalArgumentException("cat == null");
        }
        if (priority == null) {
          throw new IllegalArgumentException("priority == null");
        }
     
        this.priority = priority;
        category = cat;
        bufLength = DEFAULT_BUFFER_LENGTH;
        buf = new byte[DEFAULT_BUFFER_LENGTH];
        count = 0;
     
      }
     
     
      /**
       * Closes this output stream and releases any system resources
       *   associated with this stream. The general contract of <code>close</code>
       *   is that it closes the output stream. A closed stream cannot perform
       *   output operations and cannot be reopened.
       */
      public void close() {
        flush();
        hasBeenClosed = true;
      }
     
     
      /**
       * Writes the specified byte to this output stream. The general
       * contract for <code>write</code> is that one byte is written
       * to the output stream. The byte to be written is the eight
       * low-order bits of the argument <code>b</code>. The 24
       * high-order bits of <code>b</code> are ignored.
       *
       * @param b          the <code>byte</code> to write
       *
       * @exception IOException
       *                   if an I/O error occurs. In particular,
       *                   an <code>IOException</code> may be thrown if the
       *                   output stream has been closed.
       */
      public void write(final int b) throws IOException {
        if (hasBeenClosed) {
          throw new IOException("The stream has been closed.");
        }
     
        // don't log nulls
    //    if (b == 0) {
    //      return;
    //    }
     
        // would this be writing past the buffer?
        if (count == bufLength) {
          // grow the buffer
          final int newBufLength = bufLength+DEFAULT_BUFFER_LENGTH;
          final byte[] newBuf = new byte[newBufLength];
     
          System.arraycopy(buf, 0, newBuf, 0, bufLength);
     
          buf = newBuf;
          bufLength = newBufLength;
        }
     
        buf[count] = (byte)b;
        count++;
      }
     
     
      /**
       * Flushes this output stream and forces any buffered output bytes
       *   to be written out. The general contract of <code>flush</code> is
       *   that calling it is an indication that, if any bytes previously
       *   written have been buffered by the implementation of the output
       *   stream, such bytes should immediately be written to their
       *   intended destination.
       */
      public void flush() {
        if (count == 0) {
          return;
        }
     
        // don't print out blank lines; flushing from PrintStream puts out these
        if (count == LINE_SEPERATOR.length()) {
          if ( ((char)buf[0]) == LINE_SEPERATOR.charAt(0)  &&
               ( ( count == 1 ) ||  // <- Unix & Mac, -> Windows
                 ( (count == 2) && ((char)buf[1]) == LINE_SEPERATOR.charAt(1) ) ) ) {
            reset();
            return;
          }
        }
     
        final byte[] theBytes = new byte[count];
     
        System.arraycopy(buf, 0, theBytes, 0, count);
            try {
                category.log(priority, new String(theBytes));
            } catch (UnsupportedEncodingException ex) {
                java.util.logging.Logger.getLogger(LoggingOutputStream.class.getName()).log(java.util.logging.Level.SEVERE, null, ex);
            }
     
        reset();
      }
     
     
      private void reset() {
        // not resetting the buffer -- assuming that if it grew that it
        //   will likely grow similarly again
        count = 0;
      }
     
    }

  17. #17
    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
    Citation Envoyé par _LittleFlea_ Voir le message
    bon alors là mystère...
    Y a pas de mystère, on a déjà expliqué pourquoi ta technique ne pouvais pas marcher, sur toutes les coutures.

    Et en l'occurence, ceci

    est une erreur supplémentaire.

Discussions similaires

  1. Executer un programme java en ligne de commande
    Par kawther dans le forum Débuter avec Java
    Réponses: 6
    Dernier message: 18/02/2015, 19h49
  2. Obtenir la sortie d'une ligne de commande dans un variable java
    Par Dalidou dans le forum Général Java
    Réponses: 2
    Dernier message: 06/04/2009, 09h17
  3. java en ligne de commande et chemin absolu
    Par mon_nom_est_personne dans le forum Langage
    Réponses: 3
    Dernier message: 07/08/2008, 10h35
  4. Indentation fichier java en ligne de commande
    Par kinder29 dans le forum Général Java
    Réponses: 7
    Dernier message: 29/04/2008, 17h09
  5. [Runtime] executer une ligne de commande cmd à partir de java
    Par mazizou dans le forum API standards et tierces
    Réponses: 13
    Dernier message: 10/05/2007, 13h47

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