... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)


I did some thinking about the shape of our product in C++.  I wrote a header file with all of the principle classes.  As usual, I began to worry more and more about the ownership of the objects which represent models, queries, and compiled queries.  The thought struck me:  what about using Java to implement SQL generation?  Java is pretty stable on the Win32 platform.  Microsoft has committed to delivering the new VJ6 in September -- VJ6 can create both EXE and DLL com servers.

Java has these advantages:

  • It is garbage collected -- no ownership issues.
  • It has excellent COM support on Win32.
  • It is potentially cross-platform (e.g. to meet one of our customers's requirements, or to plug into Oracle's Java framework).
  • It is 'hot', for marketing purposes.

Here are some disadvantages:

  • There is a run-time component, namely the VM.

Here are some apparent disadvantages, with rebuttals:

  • Java is young (read 'flakey').  To implement SQL generation, we will not have to access the rapidly changing portions of Java (e.g. AWT, JFC, etc.)  Java, the language, is solid on the Win32 platform.
  • Java is slow.  Query generation is not compute intensive.  Even if it were, JIT technology brings Java execution to within a factor of 2-3 to C++ for even compute intensive operations.

Blog Archive