|
Hi folks!
I think I have figured out what this
NullPointerException in WizardStore is all about:
When I take the binary distribution along with jdk
1.3 rc1 I receive this exception. As someone else reported, this doesn't happen
with jdk1.2.2.
Now, when I rebuild the database from the source
using javac the exception goes away. But then again if I compile it using jikes,
it reappears.
So I think, it has to do with the fact that JDK1.3
bytecode is not compatible with bytecode that was considered standard
before jdk1.3 came along.
As a Windows user I had some trouble building the
source distribution because it relies on make - a unix command. Make might be
alright as long as you have it on your pc. But in fact most Windows users like
me don't. So I spent some time figuring out how I could make it work on my
windows machine and finally came accross cygwin, which seemed to have the
commandset necesarry for this operation.
But once again it didn't work, because the buld
script relied on a command that was unknown to me - jikes. Only by chance I
found out what jikes actually was, downloaded it from alphaworks and installed
it only to see that the build script still didn't work because of unix
path-separators '/' mixed with windows path-separators '\'.
After that, I was fed up with make and tried a
different approach: compiling each source directory individually using 'javac
*.java'.
As I plodded along I was convinced that I would
very soon end up with a working build of an open source odbms. But I should have known better...
Some sources didn't even compile because they
relied on packages and classes that I could not find among the jar files that
were included with the distribution.
After some time I found out that the classes that
didn't compile and even whole packages around these classes do not
make part of the current binary distribution (anymore). They must have remained
in the source tree from some earlier build until now.
So I removed them and ... to my surprise it worked.
Even this annoying NullPointerException simply vanished.
So now I'm able to use this real cool kind of
software.
Since I don't want anybody else to go through all
that again I included my Windows build script: (put it into the ozone root
directory, attention: it does not generate the jar file)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
set JAVA_COMPILER=javac
rem the following lines have to be enabled if you
are building with jikes
rem set JAVA_HOME=D:\java\jdk1.3 rem set
JAVA_CLASSPATH=%JAVA_HOME%\jre\lib\i18n.jar
rem set JAVA_CLASSPATH=%JAVA_CLASSPATH%;%JAVA_HOME%\jre\lib\jaws.jar rem set JAVA_CLASSPATH=%JAVA_CLASSPATH%;%JAVA_HOME%\jre\lib\rt.jar set CLASSPATH=.
set CLASSPATH=%CLASSPATH%;%JAVA_CLASSPATH% set CLASSPATH=%CLASSPATH%;%OZONE_HOME% set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\castor.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\gnu-regexp-1.0.8.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\javaclass.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\jndi.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\jta-spec1_0_1.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\w3c-dom.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\xalan.jar set CLASSPATH=%CLASSPATH%;%OZONE_HOME%\bin\xerces.jar rem call castor in order to build
org.ozoneDB.tools.opp.castor package
java org.exolab.castor.builder.SourceGenerator -i org/ozoneDB/tools/OPP/OzoneClassDescriptor.xsd -package org.ozoneDB.tools.OPP.castor %JAVA_COMPILER% org\odmg\*.java
%JAVA_COMPILER% org\ozoneDB\*.java %JAVA_COMPILER% org\ozoneDB\core\*.java %JAVA_COMPILER% org\ozoneDB\core\DbRemote\*.java %JAVA_COMPILER% org\ozoneDB\core\dr\*.java %JAVA_COMPILER% org\ozoneDB\core\wizardStore\*.java %JAVA_COMPILER% org\ozoneDB\DxLib\*.java %JAVA_COMPILER% org\ozoneDB\DxLib\net\*.java %JAVA_COMPILER% org\ozoneDB\odmg\*.java %JAVA_COMPILER% org\ozoneDB\tools\*.java %JAVA_COMPILER% org\ozoneDB\tools\opp\*.java %JAVA_COMPILER% org\ozoneDB\util\*.java %JAVA_COMPILER% org\ozoneDB\xa\*.java %JAVA_COMPILER% org\ozoneDB\xml\*.java %JAVA_COMPILER% org\ozoneDB\xml\dom\*.java %JAVA_COMPILER% org\ozoneDB\xml\repository\*.java %JAVA_COMPILER% org\ozoneDB\xml\util\*.java ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
In summary I would suggest the following
improvements:
1. Simplify the build process for windows
users
Yes, I know there is a build.bat included with the
distribution but it should be in the root directory and it refers to openxml.jar
which is not included with the distribution. Moreover, it doesn't build all the
classes that make part of the binary distribution (OPP is not included for
instance).
2. throw out java sources that are no longer needed
and do not compile
org.ozoneDB.xml.DOMFactory.java
org.ozoneDB.xml.OOXMLDOMFactory.java
org.ozoneDB.xml.util.OpenXMLParser.java
org.ozoneDB.xml.util.OpenXMLWriter.java
org.ozoneDB.xml.test (I
removed the whole package but I it might be possible that only a few files do
not compile any more)
org.ozoneDB.core.classicMM
(whole package)
org.ozoneDB.core.classicStore (whole package)
org.ozoneDB.core.monitor
(whole package)
3. rely on standard tools that everybody has on
his/her machine when JDK is installed
Don't use jikes by default.
4. Make two binary releases available for download.
One for JDK1.3 and one for earlier versions.
5. include the complete javadoc in the source
distribution or include a batch file for generating this javadoc
I hope this will avoid users getting frustrated
with ozone.
So for now I'm quite happy with ozone although the
odmg examples don't work on my pc.
Regards, Michael
|