[Java] variabele opeens null

[QuuN..]

Ik heb in een programma een variabele die in een methode een waarde krijgt. Deze waarde wil ik vervolgens in een andere methode uitlezen, echter heeft deze opeens de waarde null. Iemand enig idee hoe ik dit kan oplossen?

Het betreft hier de variabele value, die de waarde uitleest die binnenkomt via een Comm poort

code:

public void serialEvent(SerialPortEvent event) 
    {
    
        switch(event.getEventType()) 
        {
            case SerialPortEvent.BI:
            case SerialPortEvent.OE:
            case SerialPortEvent.FE:
            case SerialPortEvent.PE:
            case SerialPortEvent.CD:
            case SerialPortEvent.CTS:
            case SerialPortEvent.DSR:
            case SerialPortEvent.RI:
            case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
            break;
            case SerialPortEvent.DATA_AVAILABLE:
            readBuffer = new byte[3];
            try 
            {
                while (inputStream.available() > 0) 
                {
                    int numBytes = inputStream.read(readBuffer);
                    System.out.println("Wat is dit: " + numBytes);
                }
                
                String value = new String(readBuffer);
                System.out.print(value);
            } 
            
            catch (IOException e) {System.out.println(e);}
            break;
        }
    }

Hier wil ik de waarde gebruiken, echter krijg ik een foutelding dat ik value niet kan parsen. Dit komt omdat tegen mij verwachting de waarde null is ipv een String.

code:

public static void setColor()
     {
     
        value2 = Integer.parseInt(value);

        if(((value2 >> counter) & 00000001) == 1)
        {
            kleur = Color.red;
        }
        else
        {
            kleur = Color.green;
        }
        if(counter < 8)
        {
            counter++;
        }
        else
        {
            counter = 0;            
        }
     }

Value staat in de klasse gedefineerd als:

code:

private static String value;

[danslo]

Je definieert een nieuwe(!) variabele die in een (kleinere) scope valt:

Java:

String value = new String(readBuffer);

Dit moet dus zijn:

Java:

this.value = new String(readBuffer);

Je kan overigens 'this.' weglaten, maar dat maakt het er niet leesbaarder op.

[ Voor 92% gewijzigd door danslo op 17-08-2010 09:27 ]

[Scyth]

Voor mij is Java inderdaad ook even behoorlijk stoffig; maar iets wat mij direct te binnen schiet hier is een simpele variable scope issue.

edit:

Wat CLS meldde dus... * Scyth gaat koffie halen.

[ Voor 21% gewijzigd door Scyth op 17-08-2010 09:27 ]

[Tubby]

Mag ik vragen waarom de variabele value en de methode setValue static zijn?

[QuuN..]

Komt eerder door gebrek aan programmeerkennis Tubby.
Ik roep de methoden aan vanuit een klasse die een GUI maakt en static is. Ik moet daar nog even wat meer in gaan duiken, dit was meer een quick en dirty oplossing.

De code die ik poste was niet helemaal meer up to date zie ik net.
Zoals je zit declareer ik value al, en kan String dus inderdaad gewoon worden weggelaten.

Echter geeft System.out.println(value) in de methode setColor nog steeds de waarde null.
Ik heb me er al helemaal scheel op gekeken maar zie de oplossing niet.

[danslo]

QuuN.. schreef op dinsdag 17 augustus 2010 @ 09:38:

Echter geeft System.out.println(value) in de methode setColor nog steeds de waarde null.
Ik heb me er al helemaal scheel op gekeken maar zie de oplossing niet.

Twee mogelijke oorzaken:
1) Minder waarschijnlijk; de twee methodes behoren niet tot dezelfde class.
2) Waarschijnlijker: het initialiseren van je String gebeurt pas nadat je setColor hebt aangeroepen (of helemaal niet).

Ga debuggen

[Tubby]

cls schreef op dinsdag 17 augustus 2010 @ 09:41:
[...]


Twee mogelijke oorzaken:
1) Minder waarschijnlijk; de twee methodes behoren niet tot dezelfde class.
2) Waarschijnlijker: het initialiseren van je String gebeurt pas nadat je setColor hebt aangeroepen (of helemaal niet).

Ga debuggen

3) Het toekennen van de static variabele value gebeurt meerdere keren omdat serialEvent meerdere keren aangeroepen wordt

een debug point aan het eind in serialEvent levert veel inzicht op

[QuuN..]

Het zit hem waarschijnlijk in het 2e inderdaad. Helaas moet ik het hier nu even met JCreator LE doen, waar geen debug functie op zit. Ik weet wel waar de fout zit en heb dit nu aangepast. Ik roep nu setColor pas aan nadat value een waarde heeft gekregen, echter krijg ik de volgende foutmelding.

code:

Waarde: 315lPort.java:649)
    at com.sun.comm.NotificationThread.run(Win32SerialPort.java:878)

Ik zal voor de volledigheid even de hele code posten. Let niet op de quick en dirty programmeerwijze, het is een testprogramma om functionaliteit te testen.

code:

import java.io.*;
import java.util.*;
import javax.comm.*;
import java.awt.*;
import javax.swing.*;
import java.util.Scanner;

/*
 * De waarde van value heb ik nodig in de methode setColor().
 * Aan de hand van deze waarde wordt bepaald welke circels rood of groen worden.
 * Als ik de waarde van value opsla in een globale variabele, en deze gebruik in de methode setColor(), dan is de waarde van value opeens null.
 */
 
public class SimpleRead implements Runnable, SerialPortEventListener {
    static CommPortIdentifier portId;
    static Enumeration portList;

    static InputStream inputStream;
    SerialPort serialPort;
    Thread readThread;
    
    private static String value;
    private static int value2;
    private static Color kleur;
    //private static byte[] readBuffer;
    static int counter = 0;
    

    public static void main(String[] args) 
    {
        portList = CommPortIdentifier.getPortIdentifiers();
        
        //Maak Frame aan voor visualisatie
        JFrame app=new JFrame();
        app.setBounds(213,133,600,600);
        app.setTitle("Sensor Check");
        app.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
     // app.setContentPane(new Paneel() );
        app.setVisible(true);
        
        //Poorten afgaan
        while (portList.hasMoreElements()) 
        {
            portId = (CommPortIdentifier) portList.nextElement();
            if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) 
            {
                 if (portId.getName().equals("COM16")) 
                 {
            // In geval van linux poort:               if (portId.getName().equals("/dev/term/a")) {
                    SimpleRead reader = new SimpleRead();
                 }
            }
        }
    }
    
    public SimpleRead() 
    {
        try 
        {
            serialPort = (SerialPort) portId.open("SimpleReadApp", 2000);
        } 
        catch (PortInUseException e) {System.out.println(e);}
        try 
        {
            inputStream = serialPort.getInputStream();
        } 
        catch (IOException e) {System.out.println(e);}
        try 
        {
            serialPort.addEventListener(this);
        } 
        catch (TooManyListenersException e) {System.out.println(e);}
        serialPort.notifyOnDataAvailable(true);
        try 
        {
            serialPort.setSerialPortParams(9600,
                SerialPort.DATABITS_8,
                SerialPort.STOPBITS_1,
                SerialPort.PARITY_NONE);
        } 
        catch (UnsupportedCommOperationException e) {System.out.println(e);}
        readThread = new Thread(this);
        readThread.start();
    }

    public void run() 
    {
        try 
        {
            Thread.sleep(20000);
        } 
        catch (InterruptedException e) {System.out.println(e);}
    }
    
     //Maakt de circel rood als het bit hoog is en maakt de circel groen als het bit laag is.
     //9 Bits, begin bij eerste bit (meest rechtse), deze maskeren en controleren of deze 0 of 1 is.
     //Vervolgens kijkt hij naar het volgende bit, totdat alle bits geweest zijn (counter < 8)
     public static void setColor()
     {
        //System.out.println("Testje" + value);
        value2 = Integer.parseInt(value);

        if(((value2 >> counter) & 00000001) == 1)
        {
            kleur = Color.red;
        }
        else
        {
            kleur = Color.green;
        }
        if(counter < 8)
        {
            counter++;
        }
        else
        {
            counter = 0;            
        }
     }
     
     //Geeft in dit geval rood of groen terug. Apparte methode voor beter overzicht.
     public static Color getColor()
     {
        
        return kleur;   
     }


    public void serialEvent(SerialPortEvent event) 
    {
    
        switch(event.getEventType()) 
        {
            
            case SerialPortEvent.BI:
            case SerialPortEvent.OE:
            case SerialPortEvent.FE:
            case SerialPortEvent.PE:
            case SerialPortEvent.CD:
            case SerialPortEvent.CTS:
            case SerialPortEvent.DSR:
            case SerialPortEvent.RI:
            case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
            break;
            case SerialPortEvent.DATA_AVAILABLE:
            byte[] readBuffer = new byte[20];
            try 
            {
                while (inputStream.available() > 0) 
                {
                    int numBytes = inputStream.read(readBuffer);
                }                
                value = new String(readBuffer);
                System.out.print("Waarde: "+ value);
                 System.out.println("testinput");
                setColor();
            } 
            catch (IOException e) {System.out.println(e);}
           
            break;
        }
       
        
    }
}
/*
//Invulling van de GUI
//Geeft aan elke circel de bijbehorende kleur
class Paneel extends JPanel
{   
     public void paint(Graphics g) 
     {
        super.paintComponent(g);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (50,50,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (125,50,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (200,50,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (50,125,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (125,125,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (200,125,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (50,200,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (125,200,70,70);
        SimpleRead.setColor();
        g.setColor (SimpleRead.getColor());
        g.fillOval (200,200,70,70);
     }
}*/

[danslo]

QuuN.. schreef op dinsdag 17 augustus 2010 @ 10:01:
Het zit hem waarschijnlijk in het 2e inderdaad. Helaas moet ik het hier nu even met JCreator LE doen, waar geen debug functie op zit. Ik weet wel waar de fout zit en heb dit nu aangepast. Ik roep nu setColor pas aan nadat value een waarde heeft gekregen, echter krijg ik de volgende foutmelding.

code:

Waarde: 315lPort.java:649)
    at com.sun.comm.NotificationThread.run(Win32SerialPort.java:878)

Komt daar niks voor? Lijkt me sterk dat dit de volledige foutmelding is.

[Tubby]

Je "Quick & Dirty" code lijkt me wel de oorzaak van je probleem. Zelfs voor een proof of concept kan het geen kwaad om je functies op te splitsen in meerdere classes.

In dit geval zou ik het parsen van value naar een int in de methode serialEvent doen (de String value is verder niet boeiend om te bewaren).

En het vertalen van de int waarde naar een Color (huidige inhoud setColor) uitvoeren in getColor.

Maar dat zou het hoogstens iets overzichtelijker maken en de scope waarin dit fout kan gaan minder breed, het blijft een beetje een pleister op een botbreuk.

[Tubby]

En zou je die portId niet eens meegeven aan de constructor van je SimpleReader en er een niet static variabele van maken!

Bah, hier is geen eer aan te behalen, dit kan op zoveel manieren fout gaan.

[Ozzie]

Ook zou ik ipv de kleur rood/groen opslaan gewoon een Boolean gebruiken. En dan later adhv die boolean iets rood danwel groen maken.

En word serialEvent wel aangeroepen voordat jij je getColor gebruikt? Als dat niet het geval is, maar dat zou je even moeten testen, dan is het natuurlijk logisch dat het fout gaat.

[QuuN..]

Tubby, als ik setColor niet aanroep in de Serialevent methode dan krijg ik geen foutmelding, en geeft het programma netjes de juiste waarde terug. Hier is dus niets mis mee. Kortom, value krijgt de juiste waarde mee. Het gaat pas fout als ik iets met deze waarde wil doen.

Als ik het parsen gelijk na String value = new String(readBuffer); doe, dan krijg ik het volgende:

code:

Exception in thread "Win32SerialPort Notification thread" java.lang.NumberFormatException: For input string: "315

De waarde die ingelezen wordt is 315. Parse ik niet, dan geeft mijn System.out.println(value); netjes 315 terug en krijg ik geen foutmelding. Het enige wat er dus fout gaat, is het omzetten en verder gebruiken van value. Deze waarde is de waarde die ik via de com poort binnenkrijg, en waar ik dus een aktie aan wil koppelen.

@ Ozzie: Misschien een beetje onduidelijk, maar ik heb de classe paneel even 'weggecommentaard', omdat eerst set/getColor werd aangeroepen voordat serialEvent werd aangeroepen. Dit is nu dus niet meer het geval.

@ CLS: Dit was toch echt het enige wat ik terug kreeg

[ Voor 4% gewijzigd door QuuN.. op 17-08-2010 10:45 ]

[Woy]

QuuN lees Tips bij debuggen! eens door. Het lijkt er nu echt op dat je de basis van programmeren nog niet helemaal onder de knie hebt, en dat wij nu voor jou aan het debuggen zijn.

De exception die je hier boven plaatst lijkt me nu typisch iets wat je toch echt zelf op moet kunnen lossen. Zet gewoon eens een breakpoint op de regel waar het mis gaat, en kijk wat de waardes van je variabelen zijn. Verder zou het goed zijn als je je eens wat meer verdiept over de scope van variabelen, en beter probeert de begrijpen wat een static variabele nou eigenlijk is.

[QuuN..]

Ik heb alle statics er even uitgehaald, zo zal daar geen misverstand over bestaan en ben ik ook van dat verwijt af.
Ook heb ik een demo gedownload waarbij ik wel kan debuggen. Daarbij zie ik dat value2 na het parsen ook netjes 315 is. Als ik daarna echter value2 wil printen, zie ik soms dat hij value2 1x goed print, en vervolgens krijg ik de foutmelding. Een andere x krijg ik gelijk de foutmelding.


Static gedoe is nu dus uitgesloten Woy, en debuggen helpt mij in dit geval ook niet verder.


Edit:
Ik heb er nu een sleep aan toegevoegd. Hij geeft nu 5 ot 7 x de goede waarde, waarna de error verschijnt. Ik gok dat het met de buffer te maken heeft. Soms geeft de println netjes "Value2: 315" terug, en soms "Value2: 3 "(let op de lege plek na de 3, waar de parse waarschijnlijk moeilijk over doet), gevolgd door "Value2: 15". Ik denk dat ik dus gewoon moet gaan controleren of value minimaal 3 cijfers bedraagt. Ik zal het resultaat posten.

[ Voor 48% gewijzigd door QuuN.. op 17-08-2010 12:10 ]

[Woy]

QuuN.. schreef op dinsdag 17 augustus 2010 @ 11:54:
Als ik daarna echter value2 wil printen, zie ik soms dat hij value2 1x goed print, en vervolgens krijg ik de foutmelding. Een andere x krijg ik gelijk de foutmelding.
..
en debuggen helpt mij in dit geval ook niet verder.

Dan moet je verder debuggen. Die waarde verdwijnt echt niet magisch. Gewoon een kwestie van de juiste break-points zetten en kijken wanneer de waarde gezet en overschreven word.

[QuuN..]

Dit valt niet te debuggen Woy, als ik debug dan zit er zo'n grote tijd tussen dat alle waarden kloppen. Een langere sleep gebruiken is ook geen optie, omdat hij realtime moet uitlezen. Ik moet dus controleren of er geen gaten in de string zitten. Wat dus nu voorkomt, is dat ik 1 van de volgende Strings krijg:
3[][]
[]15
31[]

Waarbij de [] staat voor een spatie. Dit kan dus niet worden omgezet naar een int. Ik bedenk me net dat de waarden i nde toekomst ook minder dan 3 cijfers kunnen bedragen. Ik moet dus de spaties wegwerken. Iemand enig idee hoe ik controleer op spaties en deze in een voorkomend geval weg kan krijgen?

[Tubby]

QuuN.. schreef op dinsdag 17 augustus 2010 @ 12:21:
Dit valt niet te debuggen Woy, als ik debug dan zit er zo'n grote tijd tussen dat alle waarden kloppen. Een langere sleep gebruiken is ook geen optie, omdat hij realtime moet uitlezen. Ik moet dus controleren of er geen gaten in de string zitten. Wat dus nu voorkomt, is dat ik 1 van de volgende Strings krijg:
3[][]
[]15
31[]

Waarbij de [] staat voor een spatie. Dit kan dus niet worden omgezet naar een int. Ik bedenk me net dat de waarden i nde toekomst ook minder dan 3 cijfers kunnen bedragen. Ik moet dus de spaties wegwerken. Iemand enig idee hoe ik controleer op spaties en deze in een voorkomend geval weg kan krijgen?

Debuggen helpt je altijd verder.

Heb je überhaupt al naar de api van String gekeken?

[EddoH]

Weet je zeker dat het wel spaties zijn?
Als ik het in mn vluchtige blik begrijp verwacht je in dit geval 3 ASCII karakters ( 3, 1,5)
Nu komt het voor dat je eerst een 3 leest, en daarna de 1 en de 5. Dat heeft niets met spaties te maken.

Dit kun je op verschillende manieren oplossen:
- altijd 3 getallen sturen (bv 001, 315, 023) en ze altijd per 3 uitlezen.
- een lengte byte sturen, en vervolgens wachten op length aantal karakters.

Van een opmerking als 'dit valt niet te debuggen' gaan mn haren recht overeind staan..

[The Eagle]

D'r staat me iets bij dat Java een beetje als C werkt. In een ver studieverleden heb ik ooit eens een gevalletje in C gehad waarbij men de = en de == operator door elkaar gebruikte. Het ene is voor vergelijken, het andere is voor toekennen. Ik vergeet dat nooit meer, heb me destijds een ongeluk lopen zoeken naar zoiets simpels.

[EddoH]

The Eagle schreef op dinsdag 17 augustus 2010 @ 13:25:
D'r staat me iets bij dat Java een beetje als C werkt. In een ver studieverleden heb ik ooit eens een gevalletje in C gehad waarbij men de = en de == operator door elkaar gebruikte. Het ene is voor vergelijken, het andere is voor toekennen. Ik vergeet dat nooit meer, heb me destijds een ongeluk lopen zoeken naar zoiets simpels.

...wauw....
Misschien even de code bekijken en het topic lezen?

[voodooless]

Even wat anders:

Java:

while (inputStream.available() > 0) 
                {
                    int numBytes = inputStream.read(readBuffer);
                }                
                value = new String(readBuffer);

Hier gaat ook wat fout/kan ook wat fout gaan...

[QuuN..]

Bij nader inzien blijken het inderdaad geen spaties te zijn. Wel merk ik dat, als de waarden gesplitst zijn, hij de resterende waarde gelijk er achteraan plakt, waar er normaal een delay zit.

Wat ik nu heb gedaan, is controleren of de String.length() 3 was. Als deze kleiner was, dan maakte ik de string gewoon 0. Hij heeft nooit de waarde 0 terug gegeven, echter werden de tekens af en toe weer gesplitst met errors als gevolg. Aan de waarde van value schijnt het dus niet te liggen.

Het kan dus volgens mij aan 2 dingen liggen
1. De buffer
2. Zoals voodooless zei kan het ook de while lus zijn, al zou ik niet weten hoe ik hier verder achter kan komen (antwoord ligt vast in debuggen, maar veel verder dan waarden bekijken e.d. kom ik niet met debuggen).

[EddoH]

Hint:
while (inputStream.available() > 0)

De karakters komen redelijk langzaam aanrennen over de COM poort.
Wat gebeurd als je de '3' hebt ontvangen, maar de '1' is er nog niet?

[ Voor 48% gewijzigd door EddoH op 17-08-2010 14:32 ]

[Woy]

QuuN.. schreef op dinsdag 17 augustus 2010 @ 14:25:
(antwoord ligt vast in debuggen, maar veel verder dan waarden bekijken e.d. kom ik niet met debuggen).

Daar zit inderdaad de oplossing. In plaats van meteen zeggen dat het niet te debuggen valt, kun je ook wat verder gaan kijken. Ik geloof er namelijk niks van dat het niet te debuggen valt! Zet eens gewoon een breakpoint op een plek waar het mis lijkt te gaan. voodooless geeft in ieder geval al 1 plek aan. Stap eens stap voor stap door dat stukje code heen en kijk dan welke waardes alle variabelen in dat stukje krijgen. hint: numBytes krijg je niet voor niks terug, en je moet ook goed opletten wat er met de inhoud van readBuffer gebeurt.

[ Voor 17% gewijzigd door Woy op 17-08-2010 14:35 ]

[QuuN..]

Stel ik print:

System.out.println("Waarde: " + value);

en er komt "Waarde: 3", dan volgt heel snel daarna "Waarde: 15"
Dit volgt elkaar sneller op dan gewoon 2x "Waarde: 315"

Ik stuur vanuit mijn microcontroller de waarden al met een delay van 2000 ms

Waarden van de buffer zijn 51,49,53

Is elke keer zo. Bbij het debuggen zie ik niets geks bij de waarden van de buffer en van de variabele value.

[ Voor 22% gewijzigd door QuuN.. op 17-08-2010 14:39 ]

[Woy]

Dat lijkt me sowieso al een fout design, je zou er beter een separator tussen kunnen zetten zodat je achteraf in je Stream nog kunt zien waar de splitsing zit. Op dit moment is je protocol totaal afhankelijk van de timing dat de data binnen komt, als er ergens wat buffering toegepast word kan het dus al fout lopen.

Maar dan nog kun je natuurlijk gewoon debuggen, en moet je alleen iets beter nadenken over tactische plekken voor break-points. En anders maak je een kleine emulator die alleen data stuurt op het moment dat jij dat wil.

Maar als je eens gewoon stap voor stap door de code die voodooless aanhaalt heen stapt, en goed kijkt wat er gebeurt kom je in ieder geval al 1 fout tegen, ongeacht of de data nu te snel binnen komt of niet.

[ Voor 22% gewijzigd door Woy op 17-08-2010 14:45 ]

[QuuN..]

De microcontroller staat ingesteld op 9600 baud. Dit is zoals je ziet ook ingesteld in het java programma. Ik voorzie daar dus geen problemen.

[Woy]

Waar zie jij iemand zeggen dat de 9600 baud fout is?

[Remus]

voodooless schreef op dinsdag 17 augustus 2010 @ 14:12:
Even wat anders:

Java:

while (inputStream.available() > 0) 
                {
                    int numBytes = inputStream.read(readBuffer);
                }                
                value = new String(readBuffer);

Hier gaat ook wat fout/kan ook wat fout gaan...

@OP: Dit is de verkeerde manier van het gebruiken van available(). available() geeft alleen maar aan hoeveel bytes er minimaal beschikbaar zijn bij de volgende aanroep naar een read method. Het betekent niet dat dat het definitieve aantal bytes gaat zijn.

Daarnaast is je manier van lezen uit de inputstream ook totaal verkeerd.

Je kan de volgende sequence van gevallen hebben:

code:

t=0, readBuffer = [0x00, 0x00, 0x00]
t=1 available = 1 (byte 0x33)
=> read, readBuffer = [0x33, 0, 0]
t=2 available = 1 (byte 0x31)
=> read, readBuffer = [0x31, 0 ,0]
t=3 available = 0 (laatste byte nog niet gearriveerd)

definitieve waarde readBuffer = [0x31, 0 ,0]
resulterende string = "1(null)(null)" (waarbij (null) een null character weergeeft (0x00))

Hierop faalt de parseInt, want de volledige string moet een geldig getal zijn (de parser geeft een NumberFormatException vanwege die (null) characters.

Fix deze twee fundamentele fouten en je hebt waarschijnlijk al het grootste deel van je probleem opgelost.