CALL GLOP()

My CPU collection

2011-12-05T17:44:00.000-08:00

ShouldNotReachHere

2010-10-11T14:50:00.000-07:00

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (classFileParser.cpp:3161), pid=3136, tid=4676
# Error: ShouldNotReachHere()
#

My first Android app

2010-10-03T22:17:00.000-07:00

I created my first Android app. It converts a date in Gregorian Calendar into Maya "Long Count" calendar. Contrary to popular view Mayan calendar doesn't end on December 21st, 2012. You can test this in my app :-).

Sources can be found here.

Alternative to Thread.sleep()

2010-06-06T19:12:00.000-07:00

Follow-up to my previous post. Here is an alternative to Thread.sleep() that uses spin-yield:


    private static final long SLEEP_PRECISION = TimeUnit.MILLISECONDS.toNanos(2);  //TODO: Determine for current machine

    public static void sleepNanos (long nanoDuration) throws InterruptedException {
        final long end = System.nanoTime() + nanoDuration;


        long timeLeft = nanoDuration;
        do {
            if (timeLeft > SLEEP_PRECISION)
                Thread.sleep (1);
            else

                Thread.sleep (0); // Thread.yield();
            timeLeft = end - System.nanoTime();

            if (Thread.interrupted())
                throw new InterruptedException ();

        } while (timeLeft > 0);

    }

Test

I run 4 threads requesting 5 millisecond sleep 1000 times each (on my Dual-Core CPU). The first chart shows sleepNanos(TimeUnit.MILLISECONDS(5).toNanos()):

The second chart shows Thread.sleep(5):

As you can see, sleepNanos() is much more precise. I found that this approach was originally used by Ryan Geiss for WinAmp visualization plugin.

UPDATE

Even better precision can be achieved if you are willing to consume more CPU power doing Spin-Wait for the last part of the wait:


 
 
    public static void sleepNanos (long nanoDuration) throws InterruptedException { 
        final long end = System.nanoTime() + nanoDuration; 
        long timeLeft = nanoDuration; 
        do { 

            if (timeLeft > SLEEP_PRECISION) 
                Thread.sleep (1); 
            else 
                if (timeLeft > SPIN_YIELD_PRECISION) 

                    Thread.sleep(0); 
 
            timeLeft = end - System.nanoTime(); 
 
            if (Thread.interrupted()) 
                throw new InterruptedException (); 
 
        } while (timeLeft > 0); 

    }

Measuring nanoseconds in Java / Windows

2010-05-13T10:35:00.001-07:00

I was under false impression that interval timers in Java allow sub-millisecond precision on Windows. I knew that Thread.sleep(millis, nanos) internally uses milliseconds, but for some reason I thought that methods like LockSupport.parkNanos() method provide precise waits. Well, I was wrong. The smallest delay this method can realize is approximately 1.95 milliseconds on my Windows PC.

Back in 2006 David Holmes explained that Java timer intervals are based on waitForMultipleObjects() Windows API (which uses dwMilliseconds). They still are.

One simple (but not universal) workaround is a "spin-sleep":


    private static void sleepNanos (long nanoDelay) {
        final long end = System.nanoTime() + nanoDelay;
        do {
            Thread.yield();  // Thread.sleep (0);
        } while (System.nanoTime() < end);
    }

When running standalone this method consumes all free resources of single CPU core, but it will share with other threads that may be running. For large durations it can be enhanced to use Thread.sleep() for bulk of the waiting.

P.S. Difference between Thread.yield() and Thread.sleep( 0 ) is explained here.

Old trap

2009-12-11T14:40:00.000-08:00

I was puzzled why one of my objects had incorrect toString()

class Foo { 
    private long id; 
    private String name; 
 
    Foo(long id, String name) { 
        this.id = id; 
        this.name = name; 
    } 
 
    public String toString () { 
        return id + ' ' + name; 
    } 
}

The statement new Foo(123, "Hello") prints something like "155Hello" instead of "123 Hello". Of course the reason is pretty simple:

 
     public String toString2() { 
        return new StringBuilder().append(id + 32L).append(name.toString()).toString(); 
    }

Stack allocation in Java is still a myth

2009-11-11T08:45:00.000-08:00

There were rumors that Mustang will have on stack allocation as a part of hot spot optimization.

Four+ years later this :


public long encode (String input) {
   final byte [] buffer = new byte [8];  

   .. encode input into buffer 

   .. convert buffer into LONG 

   return result;
}

I was hoping JVM will allocate buffer on stack based on the fact that it does not escape from this method. Running this test 10M times with -verbosegc shows extensive GC work (1.6.0_16-b01 64 bit server JVM with -XX:+DoEscapeAnalysis option).

On the positive side. GC is very fast. Consider three functions:

encodeNewBuffer () uses new byte array to encode input string.

encodeSynchronizedField () uses private field, guarded by synchronized{} block

encodeThreadLocalField () uses ThreadLocal cache to encode input string

Here is the code:


long encodeNewBuffer (String input) {
   final byte [] buffer = new byte [8];  

   return f (buffer);
}

/////////////

private final byte [] buffer = new byte [8];  

synchronized long encodeSynchronizedField (String input) {
   return f (buffer);
}

/////////////

ThreadLocal<byte[]> threadLocal = new ThreadLocal<byte[]>();
{
    threadLocal.set(new byte [8]);
}

long encodeThreadLocalField (String input) {
   byte [] buffer = threadLocal.get();
   return f (buffer);
}

GC-based method is a winner:


encodeNewBuffer():         4,108 sec. 
encodeSynchronizedField(): 5,322 sec.
encodeThreadLocalField() : 5,411 sec

Multi-threaded testing with JUnit. Switch to ConcJUnit .

2009-11-09T09:38:00.001-08:00

Our JUnit tests deal with components that use multiple threads. Unfortunately JUnit has no built-in support for this kind of testing.

Lets consider a simple thread that interprets commands from input queue. In this example it can only understand "exit" command. All other inputs trigger an error.

 
 
abstract class MainLoop extends Thread { 
 
    private Queue<String> commands = new LinkedBlockingDeque<String>(); 

 
    public void run () { 
        while (true) { 
            String command = commands.poll(); 
            if (command.equals ("exit")) 
                break; 

            else 
                reportError ("Unknown command: " + command); 
        } 
    } 
 
    public void add (String command) { 
        commands.add(command); 

    } 
 
    abstract void reportError (String error); 
} 
 
public class MyTest { 
 
    @Test 
    public void test() { 
        MainLoop thread = new MainLoop() { 

            void reportError(String error) { 
                Assert.fail (error); 
            } 
        }; 
        thread.start(); 
        thread.add ("quit"); // sic! shoudl be "exit" 

    } 
}

If we run the above test, JUnit completely ignores failure of "Commands Interpreter" thread (Although default uncaughtExceptionHandler prints exception to standard output):


   [junit] Running test.MyTest
   [junit] Exception in thread "Commands Interpreter": java.lang.AssertionError: Unknown command: quit
   [junit]      at org.junit.Assert.fail(Assert.java:91)
   [junit]      at test.MyTest$1.reportError(MyTest.java:36)
   [junit]      at test.MainLoop.run(MyTest.java:19)
   [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.422 sec

As you can see JUnit detected 0 errors. JUnit has at least two problems when it comes to multi-threaded tests:

JUnit only cares about errors in its own thread. It completely ignores exceptions or assertion failures in child threads.

Left over child threads may produce side effect on subsequent tests. In some cases failures in child threads may happen after the main thread is finished.

We used various custom workarounds until it was clear that we need a generic solution for growing number of multi-threaded tests. Luckily we found an excellent tool - ConcJUnit (AKA ConcuTest) written by Mathias Ricken.

a) ConcJUnit is a drop-in replacement of JUnit. It includes standard JUnit classes and introduces own test runners. Just replace junit.jar by concutest.jar .

b) ConcJUnit detects both failures in child threads and leftover threads.

Switching to ConcJUnit produces expected result:


java.lang.AssertionError: Unknown command: quit
 at org.junit.Assert.fail(Assert.java:91)
 at test.MyTest$1.reportError(MyTest.java:36)
 at test.MainLoop.run(MyTest.java:19)
 at test.MainLoop.run(MyTest.java:19)

If you want to know more about ConcJUnit, read materials from introduction page. For example, the following presentation.

GLOP

2009-11-05T08:38:00.000-08:00

"Consider a program — any program; let us call it GLOP. We begin designing our program by imagining that we have a machine with a hardware instruction that will perform GLOP (an idea that is not beyond the realm of possibility with today's microprogrammable computers) Thus, to write program GLOP, we merely write the instruction

GLOP

and we are done! Not only are we finished, but we are relatively certain that the resulting program is correct — assuming that the hardware primitive GLOP performs correctly (and if it doesn't, we can always blame it on the vendor)."

Edward Yourdon "Techniques of program structure and design‎" 1975.

2009-11-03T16:59:00.001-08:00

2:5020/236.23 :-)

sizeof and object padding in Java

2009-10-08T21:27:00.001-07:00

Consider the following classes:


class Struct1 {
    byte b1;
}

class Struct2 extends Struct1 {
    byte b2;
}

class Struct3 extends Struct2 {
    byte b3;
}

class Struct4 extends Struct3 {
    byte b4;
}

class Struct5 extends Struct4 {
    byte b5;
}

class Struct6 extends Struct5 {
    byte b6;
}

class Struct7 extends Struct6 {
    byte b7;
}

class Struct8 extends Struct7 {
    byte b8;
}


class FlatStruct8 {
    byte b1, b2, b3, b4, b5, b6, b7, b8;
}

On my JVM (1.6.0_16 64-bit):


sizeof (new Struct8()) = 80 (sic!)
sizeof (new FlatStruct8()) = 24

Now, 24 makes sense (8 bytes of data + 2 x 8 bytes of object overhead). In case of Struct8, we can see that Java pads fields declared in each class to so that total block size will be multiple of 8.

I used both Instrumentation-based and GC-based sizeof () implementations to confirm this.

On 32-bit JVM (1.6.0_04-b12) blocks are padded to multiple of 4.


sizeof (new Struct8()) = 40 
sizeof (new FlatStruct8()) = 24

More about padding.

Faster JUL logging

2009-07-27T15:16:00.000-07:00

Here are the steps we followed to improve java.util.logging performance:

Switched from SimpleFormatter to our custom formatter. It boosted performance up to 6 times. Our formatter prints only time-of-day portion of timestamp (using custom formatting function). Our log files also omit class/method/thread context for each log message. It also uses custom MessageFormatter (based on StringBuilder).

Tweaked FileHandler to flush every 8K rather than after each message. This boosts performance up to 2.5 times.

We tried using Java7 logger package. We didn't notice considerable improvements for our usage patterns.

Credit for much of this work goes to my colleague Nikolay Dul.

Java logging

2009-07-22T18:37:00.000-07:00

Am I the only one who misses


public void log (Level level, String msg, Object ... params)

Instead of existing


public void log (Level level, String msg, Object [] params)

in java.util.logging.Logger ?

P.S. Apparently not: enhancement request was filed back in 2004. I will see what I can do...

Writing game bot in Java

2009-06-13T18:16:00.000-07:00

Can Java be used to write a simple MMORPG game bots?

Easily. Java has a class java.awt.Robot that is intended for writing automated tests and provides just what we need.

First, lets create a bot that will keep an eye on your character's health status. The basic idea is very simple - when health status is running low, drink a healing potion. Repeat. This simple script covers your back and releases your mind from some routine actions. You will concentrate on attacking your opponent ;-)

import java.awt.Color;
import java.awt.Robot;
import java.awt.Toolkit;
import static java.awt.event.KeyEvent.*;

private Toolkit toolkit = Toolkit.getDefaultToolkit();
private Robot robot = new Robot();

We need two type of things:

Inspect some area of the screen that shows your character health's status (usually appears as some sort of progress bar). We just need to know when some pixel inside the bar is getting black:
```
boolean isBlack (int x, int y) {
  Color c = robot.getPixelColor (x, y);
  return c.getRed() < 16 && c.getGreen() < 16 && c.getBlue() < 16;
}
```

Simulating keyboard action is also easy (we need to press a hotkey for your healing potions)

void key (int keyCode, long duration) throws InterruptedException {
  robot.keyPress(keyCode);
  Thread.sleep(duration);
  robot.keyRelease(keyCode);
}

Now the program itself is trivial:

while (true) {
    if (isBlack (90, 760)) 
      key (VK_F1, 500);
    
    Thread.sleep (50);   
  }

Here I assume that your healing potions are assigned to hotkey F1 (KeyEvent.VK_F1) and coordinates {90, 760} show your health status and become black when health is below 25% (your can use Paint or some other program to analyze game's screen shot).

Similar approach can be used to automate other tedious MMORPG tasks (mining gold, fishing, or gaining experience).

P.S. Take a look at this guy's screen (like a Boeing cockpit).

DISCLAIMER:Check your game's license before using this technique. It may be prohibited as something that gives unfair advantage over other players.

My favorite features in Scala

2008-12-24T18:31:00.000-08:00

Tupples in function results


def f(a: int, b: int) : (int, int) = (a/b, a%b)

type Nothing and Null (like NONE and ANY in Eiffel)
Object definitions
```
object Singleton { }
```

Parameterless methods, that can be overridden by fields and vice versa.


class Circle(radius:double) {
  def diameter = 2*radius
}
...
new Circle(5).diameter

Subtyping of generics (so-called co-variant subtyping). I miss this feature in Java:
```
def Iterator[+E] ...
now Iterator[String] will assign to Iterator[AnyObj].
```
Pattern-matching expressions? Need to try it.

Some of these I was missing since I programmed in Eiffel back in 1995.

Features I am not so fond of:

Case classes (a-la subtyped enums?)

Mindstorms are back

2008-09-30T20:13:00.000-07:00

Online game like this will be excellent for software job interview.

Obfuscated code

2008-09-12T07:29:00.000-07:00

Situation: Third-party client API library periodically fails with nasty exception:


Caused by: cli.System.AccessViolationException: Attempted to read or write protected memory.
This is often an indication that other memory is corrupt.
        at cli.TalTrade.Toolkit.DataBlock.ReadData(Unknown Source)
        at cli.TalTrade.Toolkit.RawData.GetDataAsBlock(Unknown Source)
        ... 34 more

After verifying that input parameters are legitimate I decided to take a look at the failing code. My trusty Reflector exposed the following:


private unsafe void ReadData(void modopt(IsConstModifier)* pData)
{
    // This item is obfuscated and can not be translated.
    ...
    if (*(((int*) (&gtal_handle + 4)))[4] < 6)
            goto Label_0038;
    ushort num5 = *((ushort*) (((*(((int*) (&gtal_handle + 4))) + *(((int*) (&gtal_handle + 4)))[6]) - 8) + 6));
    ... 100 more lines like these ...
}

That code is supposed to read data block from memory queue and possibly format it as string. What kind of secret know-how can it be?

Now instead of figuring out the problem by ourselves we are going to send this error to the vendor. What a waste of time on both sides.

Motorola RAZR repair

2008-08-14T06:54:00.000-07:00

Replaced keyboard in my cell phone. This is how it looked like at the worst moment.

Update on "direct vs. encapsulated field access times"

2008-08-05T20:04:00.000-07:00

Update to earlier post about performance of direct field versus method-encapsulated access. A friend of mine pointed to strange decrease in method access performance right before it is getting compiled to native code. So I went back and I enhanced output of the benchmark:



   static void benchmark () throws Exception {
       FieldAccessor fv = new FieldAccessor ();
       MethodAssessor mv = new MethodAssessor ();

       System.err.println ("\tTotal, Method, Field, Ratio");
       for (int n=1, total = 0; n < 10000000; n=2*n) {
           final long t0 = System.nanoTime();
           for (int i = 0; i < n; i++) {
               if ((mv.getField() & 0x101) != 0)
                   mv.setField(mv.getField()+1);
               else
                   mv.setField(mv.getField()+2);
           }
           final long t1 = System.nanoTime();
           for (int i = 0; i < n; i++) {
               if ((fv.field & 0x101) != 0)
                   fv.field = (fv.field+1);
               else
                   fv.field = (fv.field+2);
           }
           final long t2 = System.nanoTime();

           // dispay stats
           final double mvCycleTime = (double)(t1 - t0) / n;
           final double fvCycleTime = (double)(t2 - t1) / n;
           final double ratio = 100.0*fvCycleTime/mvCycleTime;
           total +=n;
           System.err.printf("% 12d,  %.3f,  %.3f,  %.2f%% %c\n",
                           total, mvCycleTime, fvCycleTime, ratio,
                           (fv.field == mv.getField() ? ' ' : '!'));

           Thread.sleep(500);
       }
   }

This code produces the following output (with -XX:+PrintCompilation):


   Total, Method, Field, Ratio
          1,  5866.000,  1759.000,  29.99% 
          3,  5463.000,  405.500,  7.42% 
          7,  1925.500,  217.750,  11.31% 
         15,  1166.000,  156.250,  13.40% 
         31,  648.313,  123.938,  19.12% 
         63,  440.438,  110.250,  25.03% 
        127,  401.922,  103.547,  25.76% 
        255,  270.688,  106.156,  39.22% 
        511,  243.715,  95.785,  39.30% 
       1023,  225.525,  94.367,  41.84% 
       2047,  231.510,  142.017,  61.34% 
       4095,  232.009,  97.745,  42.13% 
  2       tmp.TestFieldVsMethod$MethodAssessor::getField (5 bytes)
       8191,  227.914,  97.593,  42.82% 
  3       tmp.TestFieldVsMethod$MethodAssessor::setField (6 bytes)
      16383,  238.234,  98.486,  41.34% 
  1%      tmp.TestFieldVsMethod::benchmark @ 44 (277 bytes)
      32767,  13.628,  1.675,  12.29% 
      65535,  1.621,  1.666,  102.78% 
     131071,  1.611,  1.658,  102.88% 
     262143,  1.602,  1.655,  103.31% 
     524287,  1.599,  1.653,  103.41% 
    1048575,  1.897,  1.923,  101.40% 
  4       java.lang.String::charAt (33 bytes)
    2097151,  1.606,  1.652,  102.88% 
    4194303,  1.595,  1.652,  103.52% 
    8388607,  1.595,  1.652,  103.53% 
   16777215,  1.595,  1.655,  103.76%

Notice how ratio dives down at around 30,000 mark:

What that probably means is that field access code is compiled faster:

Without knowing much about hotspot inner workings, I expected to see a sharper decline.
I run this test on server version of Java 6 (1.6.0_10-beta-b25, 64 bit).

Java NIO with large data files

2008-08-05T16:41:00.000-07:00

We have a tool that sequentially reads financial data from massive multi-gigabyte files. It performs a lot of bytes-to-long, bytes-to-double, and utf-string conversions that were implemented in optimized fashion on top of BufferedInputStream.

It turns out that replacing that code with NIO's MappedByteBuffer processes 2 Gb file twice faster, while memory consumption remains the same.

Update: I have been warned and it turned out to be true: Reading 20 Gb file shows reverse results. Now NIO version is 8x slower than "old" stream-based approach. In this case I implemented paging because Java NIO cannot map file regions larger than 2Gb at once (Integer.MAX_VALUE).

On Windows XP 8K is a sweet spot for BufferedInputStream buffer size. Allocating larger buffer actually reduces performance significantly. May be size of mapped region has similar optimum.

Direct field vs. Method access times

2008-08-05T10:27:00.000-07:00

In my opinion there is no justification for using 'friendly' direct access to mutable class fields rather than getters and setters properties. I heard the following two arguments:

1. It makes performance-critical code run faster.

False. There is no benefit of direct access in frequently executed code. Chart below compares access time of direct field access to getters and setters.

As you can see, after 20,000 calls there is no difference in performance. This threshold is controlled by -XX:CompileThreshold JVM argument. Core of the test:


        final long t0 = System.nanoTime();
        for (int i = 0; i < n; i++) {
            if ((mv.getField() & 0x101) != 0)
                mv.setField(mv.getField()+1);
            else
                mv.setField(mv.getField()+2);
        }
        final long t1 = System.nanoTime();
        for (int i = 0; i < n; i++) {
            if ((fv.field & 0x101) != 0)
                fv.field = (fv.field+1);
            else
                fv.field = (fv.field+2);
        }
        final long t2 = System.nanoTime();

2. Direct field access reduces bureaucracy.

Read: I am too lazy to write getters and setters. Well, Eclipse and Netbeans have "Encapsulate Field" and "Generate getters and Setters" commands. And BTW, what none of free IDEs have is "Find where modified" search for class fields.

Having said that, I have no problems with public final fields :-)

A bug in Sun's 64-bit hotspot compiler

2008-07-31T06:41:00.000-07:00

A colleague of mine found a scary bug in Sun's hotspot compiler (64 bit version). It is reproducible on several computers in our office (CPUs: 2x AMD Opteron, Intel E8400; OS: Windows XP Professional 64-bit). Here is the code:


public class FailingTest {

    private final java.io.RandomAccessFile raf;
    private long sequence;

    public FailingTest() throws Exception {
        java.io.File f = new java.io.File("test.dat");
        f.delete();
        raf = new java.io.RandomAccessFile(f, "rw");
        f.deleteOnExit();
    }

    public void test(long timestamp) throws Exception {
        // This condition never happens but is required to
        // reproduce this bug, so is unused timestamp argument
        if (timestamp < 0)
            System.exit(0);

        final long valueToStore = sequence++;
        raf.seek(0);
        raf.writeLong(valueToStore);
        raf.seek(0);
        final long valueRead = raf.readLong();
        if (valueRead != valueToStore)
            System.err.println("Error: Read value " +
                            valueRead + " != " + valueToStore);
    }

    public static void main (String [] args) throws Exception {
        FailingTest t = new FailingTest();
        for (int ii = 0; ii < 1000000; ii++)
            t.test(ii);
    }
}

On my machine this test fails with the following output (I run it with -server -XX:CompileThreshold=100):


Error: Read value 4826 != 4825

The test fails every time with different numbers, with any version of 64-bit Sun JDK 1.6 we tried. This problem is NOT reproducible under 32-bit version and NOT reproducible on BEA's JRockit 1.6 (64 bit). Just verified that problem remains on the latest JVM available: build 1.6.0_10-beta-b25, Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode).

Debug mode penalty in .NET and Java

2008-07-21T14:58:00.000-07:00

Java users quite often distribute their code compiled in debug mode. This improves error diagnostics while performance penalty for having debug information in class files is negligible. Java doesn't have compile-time optimization since version 1.3 (for 8 years by now).

That is why I was amazed to see that C# Debug version of my test was 14.5 times slower compared to Release (compiled as /optimize+ /checked- /debug-). I could have imagined such difference for C++, but not for C# that also has just-in-time (JIT) optimization at run-time.

2008-07-07T15:44:00.000-07:00

Ralph Goings "cream pie" oil on canvas, 1979

Ant task for IKVMC

2008-06-12T09:43:00.000-07:00

Submitted Ant task for IKVMC - ant-ikvmc. I found multiple FileSet elements in Ant more convenient in defining source classes than -recurse:mask command line argument provided by IKVMC.

Example of task:

<ikvmc target="library" out="${dotnet.out}/uhfclient.dll" home="${ikvm.home}" version="1.0.0.0" debug="true"  verbose="true">
   <reference path="${dotnet.out}/uhfc-3rd-party.dll"/>
   <fileset dir="${classes}" includes="${uhfdll.resources}">
     <exclude name="**/*.vpp"/>
     <exclude name="**/*.txt"/>
   </fileset>
   <fileset dir="${jars}">
       <include name="**/*.jar"/>
       <exclude name="foo.jar"/>
   </fileset>
 </ikvmc>

Bonus: Java doclet that generates IKVMC mapping file. Among other things mapping file can specify parameter names in methods and constructors translated by IKVMC. Since Java parameter names are not available from Java class files, IKVMC needs this hint to preserve original Java names. This is handy if you generate API libraries that will be used by .NET developers.

Here is an example of javadoc task to generate IKVM mapping file for selected packages:

 <javadoc sourcepath="${src}" classpath="${javac.classpath}" defaultexcludes="yes">
   <doclet name="deltix.tools.ikvmc.ant.IkvmcMapDoclet" path="${classes}">
     <param name="-out" value="${mapfile}"/>
   </doclet>
   <package name="com.acme.api"/>
   <package name="com.acme.util"/>
 </javadoc>

IKVM for Java - .NET interoperability

2008-06-12T09:27:00.000-07:00

Front-end to our Java-based server is written on C#/.NET. Interoperability is achieved using XML/WS-based server API (as well as some custom binary format for high volume data responses). Typical architecture. Well, this is going to change now, after we discovered IKVM project. IKVM translates Java byte code into MSIL.

The lack of Microsoft Java implementation for .NET platform has obvious commercial reason. But what cannot be done by the largest software company was done by single developer - Jeroen Frijters (the man behind IKVM). Amazing.

JAXB 2.1 is now in Java 6 (almost)

2008-06-12T08:39:00.000-07:00

Looks like Sun folks silently updated Java 6 to use JAXB 2.1 API. The fact that Java 6 was shipped with old version of JAXB used to be a lot of pain. Hopefully we don't need to mess with endorsed directory workaround anymore.

I run a diff and it turns out that JAXB API shipped with JDK 1.6 is almost identical to 2.1. It has only one significant difference from 2.1.6: Class javax.xml.bind.ContextFinder refers to a different location of Context Factory. In com.sun.xml.internal.bind.* became com.sun.xml.bind.*

Bottom line: if you want to use JAXB 2.1 with 1.6, simply add JAXB implementation in your classpath. No need to use Java endorsed mechanism anymore.

P.S. Also the following frequent error is now a history: "java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI requires 2.1". If you still see it with JAXB 2.1 in classpath simply update your Java 6 to the latest version (I tested it with 1.6.0_04-b12+ which was released in Spring 2008).

JAXB error "java.lang.StackTraceElement does not have a no-arg default constructor"

2008-06-02T13:48:00.000-07:00

Our Java-based XML service responds with exceptions in case of errors, so naturally it serializes subclasses of java.lang.Exception to XML.

Unfortunately JAXB 2.1.x fails when someone attempts to marshal a subclass of Exception:java.lang.StackTraceElement does not have a no-arg default constructor. This can be fixed using mechanism of JAXB Introductions. I just posted a fix here.

FP :-)

2008-05-20T16:01:00.000-07:00

I hope this blog will motivate me to finish all these little notes that ...