Roman Rokytskyy wrote:

>>Something that I did to my JVM was add a mechanism to traverse the
>>class tree.
>>
>>
>
>Why didn't you use the classloader hierarchy? Is there any good reason
>for this?
>
>

Sure. The classloader loads stuff on demand. There is no way to force
it to load all dependencies of a class.

>>You will find almost instantly that the Firebird Java implementation
>>will require changes to whatever base classes your JVM comes with.
>>Plan for it.
>>
>>If you aren't aware of it, base classes are the least bit portable,
>>containing all sorts of nasy native stuff to actually make thiings
>>work.
>>
>>
>
>How should it touch the Java code running in tha JVM as long as we use
>external JVM (one for Windows, one for Linux)?
>
>

That will also drive you nuts. Firebird should find a technically
acception, license compatible JVM, and package the base classes with the
kit. Having different base classes for different platforms could be
done, but shouldn't. In fact, except for the threading primitives, a
JVM, per se, doesn't have platform dependencies, doing very little other
than opening and closing files and allocating and deallocating memory.
Everything else is in native code, but other than sockets, that, too, is
mostly portable. A potential exception is a JIT JVM, but embedded JVM
doesn't need one.

>Why? It already works with a off-the-shelf JVM (in our case Sun), and
>no interception was needed. Can you explain this in details?
>
>
>

How do you catch native calls back into the engine? I suppose you could
put the whole thing, JVM and all, into a shared library and have a base
class do a loadLibrary on itself, but that means that JVM can't be
statically linked in. On refection, maybe that's a good thing.

What I did in Netfrastructure to reduce the cost of the Java/C++
interface was to add an "externalObject" pointer to selected Java
objects to point to a C++ analog. The pointer is invisible to Java
code, but makes finding the corresponding C++ class for a Java object a
great deal easier. As it turns out, the hardest part of a very thin
JDBC layer is object tear down, which is chock full of race conditions
between the Java garbage collector and database request releases and
database detaches. Given the mutual dependencies of Connections,
Statements, and ResultSets, and that closing some can force closure of
others, the asynchronous nature of garbage collectors, and the inability
of freshly minted programmers to release unused resources, and you get a
real nasty stew. You can avoid it by adding multiple redirection
layers, but at a performance cost I was unwilling to accept.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376