At 09:38 15/02/2005 +0100, Egon Willighagen wrote:
>On Monday 14 February 2005 11:31 pm, Rajarshi Guha wrote:
> > On Fri, 2005-02-11 at 08:14 +0100, Egon Willighagen wrote:
> > > On Friday 11 February 2005 01:04 am, Rajarshi Guha wrote:
> > > > Hi, I've been updating DescriptorCalculator to handle descriptor
> > > > classes. That works fine. But it seems theres a problem when outputing
> > > > the values in CML:
> > > >
> > > > With the following command line I get
> > > >
> > > > java -Dcdk.debugging=true -cp $CLASSPATH
> > > > org.openscience.cdk.applications.DescriptorCalculator -t topological -s
> > > > "CC=CCC"
> > >
> > > Which JVM are you using? The libio.cml.Convertor does not work with
> > > 1.5...
> > What is the reason for it not working with 1.5? If you can point me in
> > the direction I'd like to try and get it to work - mainly so I can keep
> > on using 1.5 for my Tomcat/Axis setup
>CMLDOM is the 'problem'... but 4.6 is about to be released which does work
>with J1.5... so it's just a matter of one/two weeks
We had hoped to release it yesterday but then got concerned about Java
versions. As you will see from our posting today we have a problem between
J1.4 and J1.5 [Not sure whether this has been posted to the lists, so
please use it for discussion anyway.]
I would be very grateful for any insight.
JUMBO4.6 does not *require* any 1.5. It has been compiled by me under 1,4
and by Billy under 1,5 However it seems that a 1.5 version doesn't run on
In what way does libio.cml.Convertor depend on Java versions?
Egon - I assume you are checking out the most recent CVS of JUMBO. I have
fixed a serious problem with the DOM updating - it filled all the
attributes with "defaults".
It also gave a problem with CDK parsing - still don't know why but the
problem disappeared. The CDK "trapped" the parse error and reported "a
well-formedness error". This means we cannot get the real reason for the
error which I suspect was not well-formedness but something else. So it
would be useful for all our routines to return the actual exceptions.
In this area I think unit tests are essential. I am going through JUMBO and
putting them in JumboTools - they make the code a lot better. Also it is
very useful for people using different versions of the software.
I would suggest that for every public method there is at least one unit
test, and that all unit tests are collected for the library. That means
that the unit tests for version N can be run on version N+1. This
immediately shows if any signatures are missing. It also shows if anything
has gone wrong. Of course version N+1 will have complete unit tests. It
means that the group *using* the library can run the unit tests and ensure
conformance as they continue to develop.
================= earlier message for discussion ==============
[Crossposted to several lists - suggest we only reply on CDK]
We are about to release JUMBO4.6 - effectively a major release - but came
across two problems which we think need communal agreement. It affects most
of the Java Open Source community. I suggest we reply ONLY on CDK to limit
We develop on both Java 1.4 and 1.5 and discovered yesterday that byte code
*compiled on 1.5* will not run on 1.4 systems (even simple programs like
HelloWorld). It fails with an incompatible version number (actually
requires version 49.0 (sic) of Java). Therefore if we compiled and released
JUMBO on 1.5 machines it would fail anywhere with 1.4. [We assume that J1.4
bytecode runs on 1.5 systems]
Q. what strategy do the various groups have for this? Do you have any idea
of the rate of take up of J1.5?
javac 1.5 has a switch -target 1.4 which we assume generates byte code
compatible with J1.4 systems.
Q does this work?
Q. have you used and deployed code of this sort?
Q is it a good strategy?
Q should our community (Jmol, JCP, CDK, QSAR, Octet, JOElib, JUMBO) have a
communal view? If we all do the same thing we are limited by the slowest. I
assume that Jmol, for example, need to retain considerable backward
We have also now developed a large communal library. Thus JUMBO includes
Jmol, JCP, CDK and therefore all their libraries. (We are delighted with
this functionality - Billy has a very nice CML document viewer based on
This can mean 2 or even 3 copies of things like Xerces in the distrib. The
size is bad enough but since Xerces is now in the JVM 1.5 and also seems to
change its signatures with every new moon the chance of incompatible
versions is high. There are also copies of CDK libraries in JCP and so on.
We also found that when we installed a recent CDK a method in CDK had
disappeared which led to a compilation problem - we've managed to kludge
round but this will be an ongoing problem. Whenever there is a new (even
minor) release of any of our libraries we all have to clean and rebuild in
case of these problems.
Q How do we manage our libraries? If all of us use everyone else's
libraries then these problems will increase. For example we'd like to use
JOELib but not necessarily as part of our distributed system. If the
performance is not time-critical then we can use web services as a means of
insulating the APIs and libraries. For example we might move to running a
CDK 2Dlayout server. This could be distributed so that connections to the
web wouldn't be needed. However it would necessarily increase the
complexity and is incompatible with, say, lightweight applets.
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>Cdk-devel mailing list
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK