Skip to content

Dagens "aha" med JAXB

JAXB er yderst lækkert, dokumentationen er lidt la-la. Se blot følgende:

-xmlschema
    treat input schemas as W3C XML Schema (default). If you do not specify this switch, your input schemas will be treated as W3C XML Schema.
 


I fordi jeg ikke forstår hvad de mener, blot lidt overflødig parameter... Hvis man spørg mig :-)

Java - nu under GPL

Jeg vil også være med til at sprede budskabet om Java, som blev open source. Nyheden er vel stadig "fresh" - det synes jeg da. Jeg faldt også lige over Richard Stallman's kommentare til dette. Den kan ses her.

HotSpot VM (JVM) og javac bliver frigivet under et projekt kaldet OpenJDK. Det skal nok blive spændende at følge dette projekt. Duke, Java's maskot er også blevet open source. Dette betyder bl.a. at Java nu kan distribueres med f.eks. Debian.

Personligt synes jeg at det er en stor dag for open source og fri software.

Error: class file has wrong version 48.0, should be 47.0

This is one of the few entries I have written in English, so typos etc. will be present :-)

The reason that I'm writing this in English and not in Danish is that this problem is somewhat documented on the net - but I would also like to contribute.

So, why do I get a class file has wrong version 48.0, should be 47.0 error? The reason for this is that you are using JDK 1.4 to build your project. This is fine, but somewhere in your build process you are using JDK 1.3. The problem emerges as a conflict between these two versions. In my case JDK 1.4 called the JDK 1.3 javac which then tried to use JDK 1.4's rt.jar file. As JDK 1.3 doesn't understand the 1.4's specification (major/minor version) it throws a class file has wrong version 48.0, should be 47.0.

The solution was to compile the entire system with JDK 1.4. But notice that some parts of your system might have to be compiled using 1.3, and therefore this solution is not viable for you. In this case you must identify what parts need to be compiled with 1.3 and what parts need 1.4 and use verify that you are doing this correctly. This, of course, depends on your build method.

Lidt sjov med Java

Vi kender det alle - man bruger en finally fordi man er sikker på at den altid vil blive kørt... Men er vi nu også helt sikker på det? Nææh, men ideen er da god:
try {
    if (choice) {
        while (true) ;
    } else {
        System.exit(1);
    }
} finally {
    code.to.cleanup();
}

Bare fordi det står i bøgerne skal man ikke altid tro på det.

Null flag bug pattern

Nogle gange er man som Java-programmør "fristet" til at returnere en null-pointer når man arbejder med exceptions. Dette er ikke altid praktisk - faktisk er det skidt for ens kode, da kvaliteten af koden falder. At returnere en null-pointer (eller blot null) er også kendt som null flag bug pattern.

I stedet for at returnere null burde man overveje at smide en exception. Lad os tage et eksempel:
public Object next() {
    try {
        String result = internal.readLine();
        if (result == null)
            throw new NoSuchElementException();
        else
            return result;
        catch (IOException e)
            throw new NoSuchElementException(e.toString());
    }
}

(kode-stumpen er taget herfra)


Hvis det ikke er let at se hvorfor det er bedre at smide NoSuchElementException i stedet for at returnere null, vil jeg henlede læseren opmærksomhed på null flag bug pattern. Den er forholdsvis kort og overskue, og giver en let måde at øge kvaliteten af ens kode.