Programmieren mit Harald R. Haberstroh

RemoteException

public class Server {
    public static void main(String[] args) {
        try {
            LocateRegistry.createRegistry(1099);
            System.out.println("RMI-Registry erfolgreich gestartet");
        } catch (RemoteException ex) {
            System.out.println("Fehler beim Starten der Registry: " + ex);
        }
        try {
            DB db = new Data("fahrten.db");
            //System.out.println(((Data)db).records.size());
            DB d = (DB) UnicastRemoteObject.exportObject(db, 1099);
            System.out.println("1xx");
            Naming.rebind("Data", d);
            System.out.println("2xx");

            
            Header he = ((Data)db).getHeader();
            Header h = (Header) UnicastRemoteObject.exportObject(he, 1099);
            Naming.rebind("Header", h);


            System.out.println("Alles gebunden");


        } catch (RemoteException ex) {
            System.err.println("RemoteException");
        } catch (MalformedURLException ex) {
            System.err.println("MalformedURLException");
        }
    }
}

RemoteException: remote object implements illegal remote interface; nested exception is: 
        java.lang.IllegalArgumentException: illegal remote method encountered: public abstract int data.Header.length()

public class Data implements DB, Serializable {

    private final int MAGIC_COOKIE = 4223;
    private Header header;
    private String fileName="";
    private ArrayList lockedRecNo;
    private int DataOffset; //166

public interface Header extends Remote {
    public Field getField(int fID);

    public int length();

    public void addField(Field f);

}

public class Fields extends UnicastRemoteObject implements Header, Serializable {

    private ArrayList felder;

    public Fields() throws RemoteException {
        felder = new ArrayList(0);
    }
...

public class Server {

    public static void main(String[] args) {
        DB db = null;
        try {
            db = new Data("fahrten.db");
        } catch (RemoteException ex) {
            System.err.println("RemoteException (new Data()): " + ex.getMessage());
        }
        try {
            LocateRegistry.createRegistry(1099);
            System.out.println("RMI-Registry erfolgreich gestartet");
        } catch (RemoteException ex) {
            System.out.println("Fehler beim Starten der Registry: " + ex);
        }
        try {
            DB d = (DB) UnicastRemoteObject.exportObject(db, 1099);
            Naming.rebind("Data", d);
        } catch (RemoteException ex) {
            System.err.println("RemoteException (rebind(Data)): " + ex.getMessage());
        } catch (MalformedURLException ex) {
            System.err.println("MalformedURLException: " + ex.getMessage());
        }
        try {
            Fields he = (Fields) ((Data) db).getHeader();
            Header h = (Header) UnicastRemoteObject.exportObject(he, 1099);
            try {
                Naming.rebind("Header", (Fields) h);
            } catch (MalformedURLException ex) {
                System.err.println("MalformedURLException (rebind(Header)): " + ex.getMessage());
            }
        } catch (RemoteException ex) {
            System.err.println("RemoteException: " + ex.getMessage());
        }
        System.out.println("Alles gebunden");
    }
}

Logger.getLogger(Server.class.getName()).log(Level.SEVERE, null, ex);

try {
                    while(true) {
                        records.add(read(nr));
                        nr++;
                    }
                } catch (RemoteException ex) {
                } catch (RecordNotFoundException ex) {
                }

Labels: allgemeines, Fehler, Java

# Eingestellt von Harald R. Haberstroh @ 09:28 0 Kommentare

Folgendes Beispiel zeigt ein Problem beim Autoboxing in Java. Der Autor des Code-Fragments will int-Werte in der LinkedList lockedRecords speichern. Das funktioniert beim Speichern in Zeile 16 auch super, weil der int-Wert recNo automatisch in ein Integer-Objekt gepackt wird.

LinkedList<Integer> lockedRecords = new LinkedList<Integer>();

    public long lock(int recNo) throws RemoteException,
            RecordNotFoundException {
        long lockCookie = 0;
        if(existsRec(recNo)){
            synchronized(records.get(recNo)){
                while(lockedRecords.contains(recNo)){
                    try {
                        records.get(recNo).wait();
                    } catch (InterruptedException ex) {
                        System.err.println("Lock Interrupted!");
                    }
                }
                if(existsRec(recNo)){
                    lockedRecords.add(recNo);
                    boolean lock_getted = true;
                    lockCookie = lockedRecords.size() -1;
                    return lockCookie;
                }
            }
        }else{
            throw new RecordNotFoundException();
        }
        return lockCookie;
    }

    public void unlock(int recNo, long lockCookie) throws RemoteException,
            RecordNotFoundException, SecurityException {
        if(recNo > 0 && recNo < records.size()){
            if(lockCookie >= 0 && lockCookie < lockedRecords.size()
                    && lockedRecords.contains((int)lockCookie)){
                synchronized(records.get(recNo)){
                    lockedRecords.remove(recNo);
                    records.get(recNo).notifyAll();
                }
            }else{
                throw new SecurityException();
            }
        }else{
            throw new RecordNotFoundException();
        }
    }

Warum?

Die Klasse LinkedList (sowie viele andere Klassen des Java Collection Frameworks) besitzt zwei remove()-Methoden:

1. E remove(int index), welche das Element mit dem Index index entfernt und eine IndexOutOfBoundsException wirft, wenn der Index nicht existiert.
2. boolean remove(Object o), welche das entsprechende Objekt entfernt, falls es existiert (und in diesem Fall true liefert).

Autoboxing ist also im Allgemeinen sehr praktisch, kann aber zu unerwarteten Problemen führen.

Übrigens ist eine Lösung mit Verwendung von Integer nicht zielführend, da beim Autoboxing nur bei kleinen Werten tatsächlich dasselbe Objekt verwendet wird:

Integer i1 = 23;
Integer i2 = 23;
Integer i3 = 2132321423;
Integer i4 = 2132321423;
System.out.println(i1 == i2);
System.out.println(i1.equals(i2));
System.out.println(i3 == i4);
System.out.println(i3.equals(i4));

true
true
false
true

Labels: Fehler, Java

# Eingestellt von Harald R. Haberstroh @ 13:00 0 Kommentare

    public int[] find(String[] criteria) throws RemoteException {
        ArrayList erg = new ArrayList();
        for(int i=0; i< records.size();i++){
            boolean match=true;
            if(criteria != null){
                for(int j=0; j< criteria.length;i++){
                    if(criteria[j] != null){
                        if(!records.get(i).getField(j).contains(criteria[j])){
                            match=false;
                            break;
                        }  }  }  }
            
            if(records.get(i).isDeleted()){
                match=false;
            }
            if(match){
                erg.add(i);
            }
        }
        int[] back = new int[erg.size()];
        for(int i=0; i< erg.size();i++){
            back[i]=(int)erg.get(i);
        }
        return back;
    }

Labels: allgemeines, Fehler, Java

# Eingestellt von Harald R. Haberstroh @ 12:19 1 Kommentare

Eine Stunde Fehlersuche! Suche in einem fremden Code, der gewisse Anforderungen erfüllen muss. Der Unit-Test für eine Methode, die einen CSV-String liefern ist fehlgeschlagen. Das Feld an der Position 5 war immer leer. Der Test erwartete den String "42995";"47.01708,16.93225";"20.73708,29.96312";" 196";"201105132101";" 405";"9634090160";"O", die Methode lieferte jedoch 42995;"47.01708,16.93225";"20.73708,29.96312"; 196;201105132101;"";9634090160;"O"

OK, dieser "Fehler" war schnell gefunden. Die Methode hielt sich besser an das CSV-Format (nur Strings sind in Hochkomma eingeschlossen, Zahlen nicht) als mein Test. Das war schnell korrigiert und nun lieferte die Methode alles als String:
"42995";"47.01708,16.93225";"20.73708,29.96312";" 196";"201105132101";"";"9634090160";"O"

Fast richtig. Das ist ein wirklicher Fehler. Durchforsten und Debuggen hat ergeben, dass dieses Feld schon beim Lesen immer leer wird. Der Code dazu ist folgender (das Leerzeichen bei den Bedingungen "kleiner als" habe ich für den Blog hinzugefügt, damit da nicht ein ungültiges HTML-Tag ensteht, grundsätzlich erschwert das Fehlen solcher Leerzeichen das Lesen des Codes):

public Data(String fn) throws FileNotFoundException, IOException{
        fileName=fn;

        rf = new RandomAccessFile(fn, "rw");
            int mC=rf.readInt();
            if(mC==4223){
                int dataOffset=0;
                short count=0;

                dataOffset=rf.readInt();
                firstDataOffset=dataOffset;
                count=rf.readShort();
                information = new Header(count);
                for(int i=0;i< count;i++){
                    short fNameLength = rf.readShort();
                    byte[] roughData = new byte[fNameLength];
                    rf.read(roughData/*, (int)rf.getFilePointer(), fNameLength*/);

                    String fieldName = new String(roughData,"ISO-8859-1");
                    short fDescLength = rf.readShort();
                    roughData = new byte[fDescLength];
                    rf.read(roughData/*, (int)rf.getFilePointer(), fDescLength*/);
                    String fieldDescription = new String(roughData,"ISO-8859-1");

                    char type = (char)rf.readByte();

                    short fDataLength = rf.readShort();

                    Field f = new Field(fNameLength, fieldName, fDescLength, fieldDescription, type, fDataLength);

                    information.setHeaderField(i, f);
                }
                records = new ArrayList();
                while(dataOffset< rf.length()){
                    short flag = rf.readShort();
                    String[] data = new String[information.getLength()];
                    for(int i=0;i< data.length;i++){
                        int readLen = information.getField(i).length;
                        byte[] roughData = new byte[readLen];
                        rf.read(roughData/*, dataOffset, readLen*/);
                        switch(information.getField(i).type){
                            case'f':
                            case'F':
                                data[i] = new String(roughData,"ISO-8859-1");
                                break;
                            case'v':
                            case'V':
                                StringBuilder sb = new StringBuilder();
                                for(int j=0;i< readLen && (char)roughData[j]!='\0';j++){
                                    sb.append((char)roughData[j]);
                                }
                                data[i] = sb.toString();
                                break;
                            case'c':
                            case'C':
                                byte[] d = new byte[1];
                                d[0]=roughData[0];
                                data[i] = new String(d);
                                break;
                        }
                        dataOffset+=(2+readLen);
                    }
                    if(flag==0){
                        records.add(new RecordData(data, true, information));
                    }else{
                        records.add(new RecordData(data, false, information));
                    }

                }
                rf.close();
                information.recAnz = records.size();
            }else{
                throw new FileNotFoundException("Keine DB-Datei");
            } 
    }

Also nächste Hypothese: das Lesen der Daten ist fehlerhaft! Zeilen 38 bis 40. Aber die sind m.E. korrekt. Vielleicht wurde der Dateiheader falsch gelesen (dort sind die Feldlängen und Feldtypen spezifiziert).

Zeilen 5 bis 32. Aber auch dort ist nichts verdächtiges. Es ist schon zum Verzweifeln! Alles schaut richtig aus und trotzdem schlägt der Test fehl (zu Recht, denn das Ergebnis ist falsch).

Jetzt ist einmal Zurücklehnen angesagt. Das ganze mal von der Entfernung betrachten. Breakpoint auf Zeile 48 setzen und schauen, was sich tut.

Erst beim 5. Feld (0-basiert) tritt der Fehler auf. Die Schleife wird sofort verlassen, obwohl roughData tatsächlich mehr als 0 Bytes enthält, 5, um genau zu sein. readLen enthält sogar den richtigen Wert. Wie so zum Teufel ist dann die Bedingung j < readLen && roughData[j] != 0 nicht erfüllt (das Casten auf (char) hatte ich schon entfernt, weil '\0' tatsächlich den Wert 0 hat)?

Ich habe bei dem Ausdruck Leerzeichen eingebaut, die im Original nicht waren. Jetzt fällt es wie Schuppen aus den HaarenAugen! Im Original auf Zeile 49 steht i < roughData && roughData[j] != 0. i statt j - optisch fast nicht zu unterscheiden!

i zählt die Felder, j die einzelnen Bytes in einem Feld. Daher ist ab dem Feld 5, welches eine Länge von 5 hat, der erste Teil der Bedingung nicht mehr erfüllt und es wird ein leerer String erzeugt.

Ja, Programmieranfängern wird immer gepredigt: "sprechende" Namen verwenden!

Das hätte geholfen! Statt i könnte man z.B. fieldno verwenden und statt j wäre byteno angebracht. Damit wäre der Fehler nie passiert! Die Schleife hätte gleich falsch ausgesehen:

for(int byteno=0;fieldno< readLen && roughData[byteno]!=0;byteno++){
    sb.append((char)roughData[byteno]);
}

Selbst wenn man in kurzen Schleifen i und j als Laufvariable erlaubt, dann müsste aber in der äußeren Schleife immer noch ein "sprechender" Name verwendet werden. Das stäche auch ins Auge (die Leerzeichen verbessern das auch noch!):

for (int i = 0; fieldno < readLen && roughData[i] != 0; i++){
    sb.append((char)roughData[byteno]);
}

Die Variante mit "sprechenden" Namen für Schleifen, die länger als ein paar Zeilen sind, und kurze Laufvariable für kurze Schleifen (Dreizeiler) ist die beste Möglichkeit, dann das Beispiel mit i und fieldno schaut gleich irgendwie falsch aus. Zumindest schaut man sich so etwas gleich näher an.

Leerzeichen und sprechende Namen bringen's!

Siehe auch Programmierrichtlinien allgemein. Dort steht leider nichts über die Verwendung von Leerzeichen.

Java Guidelines findet man z.B. hier: http://www.oracle.com/technetwork/java/codeconv-138413.html

Google findet auch etwas: www.google.com

Labels: allgemeines, Fehler, Java

# Eingestellt von Harald R. Haberstroh @ 17:49 0 Kommentare

• bei einem einen Java-Decompiler verwenden, damit ich überhaupt praktisch mit dem Programm arbeiten und mir Fehler genauer betrachten kann, denn dieser Kandidat hat nur die *.class-Dateien ins Abgabe-Archiv gepackt (Eclipse-Projekt).
• bei 6 (sechs) ich die *.java-Dateien mühsam wieder in die richtige Paket-Struktur bringen, teilweise nur durch händisches Anlegen der Klassen und dann Kopieren der entsprechenden Textstellen aus der einen Textdatei, in der alle Klassen zusammengefasst waren (alles Netbeans-Projekte).
• bei den restlichen 10 konnte ich das Projektverzeichnis unmittelbar verwenden (4 Eclipse-, 5 Netbeans-Projekte bzw. ganz ohne Meta-Information der IDE).

Das nächste Bild zeigt ein falsch abgegebenes Projekt. Es gibt in den Paket-Verzeichnissen keine *.java-Dateien!

Die *.java-Dateien waren im übergeordneten Verzeichnis zu finden. Die Verzeichnisse mit den Sourcen beginnen alle mit einem Leerzeichen und müssen erst wieder umbenannt werden:

Das Verzeichnis, das mit "-brz" endet, enthält das Projekt, aber eben ohne die Sourcen.

Ich denke, man muss schon ziemlich Hand anlegen, um aus den Projektverzeichnissen diese kaputten Projekte zu erzeugen.

Ich frage mich, was so kompliziert ist, wenn es heißt: "Das gesamte Projekt-Verzeichnis (Name-brz) in eine Jar-Datei (Name-brz.jar) packen und ins Abgabeverzeichnis kopieren (Name-brz.jar enthält also u.a. die „ausführbare“ Datei brz.jar)."

Die Angabe für das Projekt war so:
"Verwenden Sie als Standard-Encoding UTF-8 (Unicode)!
Nennen Sie das Projekt Name-brz, wobei Name Ihr Familienname ist.
Erstellen Sie eine geeignete Paket-Struktur.
Erstellen Sie die Verzeichnisse build und doc. Im Verzeichnis build muss das fertige Programm brz.jar abgelegt werden. In doc muss die generierte JavaDoc abgelegt werden. Legen Sie im Projektverzeichnis eine Datei readme.txt an, die Hinweise zum Erzeugen von brz.jar enthält.
brz.jar soll alle nötigen Informationen zum Betrieb mit Ausnahme der Datenbankdateien enthalten, d.h. brz.jar soll in jedem beliebigen Verzeichnis aufgerufen werden können.
Programmaufruf: über ein Argument der Kommandozeile soll festgelegt werden, ob das Programm als Server (Argument server), Client (Argument client) oder AdminClient (Argument admin) läuft.
Erstellen Sie ein Ant-Script, mit dem die Applikation und die Dokumentation (neu) erstellt werden kann."

Es durfte frei zwischen Eclipse und Netbeans gewählt werden.

Die Leute haben 5 oder mehr Jahre Programmieren hinter sich. Und immer wieder Tests in dieser Arbeitsumgebung (Java unter Linux). Ich verstehe das nicht!

Diese Umstände kosteten bis jetzt ein paar Stunden Arbeit (überhaupt, wenn man diesen Blog-Eintrag mitrechnet). Wirklich korrigiert habe ich noch keine der Arbeiten.

Labels: allgemeines, eclipse, Fehler, netbeans, PR5

# Eingestellt von Harald R. Haberstroh @ 13:57 0 Kommentare

Labels: allgemeines, Fehler, Links

# Eingestellt von Harald R. Haberstroh @ 09:23 0 Kommentare

>>> from random import seed, random
>>> seed("23")
>>> random()
0.41111702255082994

>>> from random import seed, random
>>> seed("23")
>>> random()
0.09256672412670508

>>> "23".__hash__()
6400038450057767

>>> "23".__hash__()
308105767

>>> seed(23)
>>> random()
0.92486525162594524

>>> seed(23)
>>> random()
0.92486525162594524

Labels: allgemeines, Fehler, Python

# Eingestellt von Harald R. Haberstroh @ 11:47 0 Kommentare

<projectdescription>
  <name>start-demo</name>
  <comment></comment>
  <projects>
  </projects>
  <buildspec>
  </buildspec>
  <natures>
  </natures>
</projectdescription>

<projectdescription>
  <name>start-demo</name>
  <comment></comment>
  <projects>
  </projects>
  <buildspec>
    <buildcommand>
      <name>org.eclipse.jdt.core.javabuilder</name>
      <arguments>
      </arguments>
    </buildcommand>
  </buildspec>
  <natures>
    <nature>org.eclipse.jdt.core.javanature</nature>
  </natures>
</projectdescription>

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="output" path="bin"/>
</classpath>

Labels: CVS, eclipse, Fehler

# Eingestellt von Harald R. Haberstroh @ 15:00 0 Kommentare

Labels: allgemeines, CVS, Fehler, System

# Eingestellt von Harald R. Haberstroh @ 15:47 0 Kommentare

Labels: allgemeines, CVS, Fehler, System

# Eingestellt von Harald R. Haberstroh @ 13:18 1 Kommentare

1. Alle einzelnen Dateien des Projekts händisch commiten.
2. Das Projekt in einem neuen Verzeichnis auschecken.
3. Prüfen, ob alles da ist.
4. Das alte/originale Projekt löschen.
5. Das neue verwenden.

• Replacing CVS files
• Concurrent Versions System – Wikipedia

Labels: CVS, eclipse, Fehler, netbeans

# Eingestellt von Harald R. Haberstroh @ 14:36 0 Kommentare

//------------------------------------------------------------------------------
//
// Function: ConvertDays
//
// Local helper function that split total days since Jan 1, ORIGINYEAR into 
// year, month and day
//
// Parameters:
//
// Returns:
//      Returns TRUE if successful, otherwise returns FALSE.
//
//------------------------------------------------------------------------------
BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)
{
   int dayofweek, month, year;
   UINT8 *month_tab;

   //Calculate current day of the week
   dayofweek = GetDayOfWeek(days);

   year = ORIGINYEAR;

   while (days > 365)
   {
       if (IsLeapYear(year))
       {
           if (days > 366)
           {
               days -= 366;
               year += 1;
           }
       }
       else
       {
           days -= 365;
           year += 1;
       }
   }


   // Determine whether it is a leap year
   month_tab = (UINT8 *)((IsLeapYear(year))? monthtable_leap : monthtable);

   for (month=0; month<12; month++)
   {
       if (days <= month_tab[month])
           break;
       days -= month_tab[month];
   }

   month += 1;

   lpTime->wDay = days;
   lpTime->wDayOfWeek = dayofweek;
   lpTime->wMonth = month;
   lpTime->wYear = year;

   return TRUE;
}

 year = ORIGINYEAR; // == 1980
 while (day > 365)
 {
     if (IsLeapYear(year))
     {
         numOfLeap++;
         if (day > 366)
         {
             day -= 366;
             year += 1;
         }
     }
     else
     {
         day -= 365;
         year += 1;
     }
 }

Labels: C, Fehler

# Eingestellt von Harald R. Haberstroh @ 11:18 4 Kommentare