Re: [Joelib-devel] Libraries and Java versions

[Peter Murray-R. <pm...@ca...>]

[crossposted to a smaller set of lists!]

Thanks very much Joerg for quick reply...

At 11:24 15/02/2005 +0100, Joerg K. Wegner wrote:
> > [Crossposted to several lists - suggest we only reply on CDK]
>I suggest QSAR devel.

I am keeping in CDK as it overlaps with the Jmol group.


>>Q. what strategy do the various groups have for this? Do you have any 
>>idea of the rate of take up of J1.5?
>JOELib  is 1.4 (only maintenance, no active development)
>JOELib2 is 1.5 (active development)
That is our own in-house approach. JUMBO4.6 is now maintenance-only and 
Jumbo5 is being developed as fully Java 1.5 (at source level). There are 
additional incompatibilities with XML/JAXP - do you have any insight here?


>>Q does this work?
>Never tried.
>The only thing i found is that 1.5. in server mode caused hard shutdowns 
>of our server. Please use -client to switch of the at the moment instable 
>-server mode, which is used via autodetection.
>
>>Q. have you used and deployed code of this sort?
>No, but internally this should be the same code.

I agree it *should*. I just wanted confirmation!

>>Q is it a good strategy?
>Depends on your requirements, adding additional maintenance tasks should 
>be not too difficult.

We have to be able to support people who are not (very) java-literate so 
version problems must be excluded

>>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 compatibility
>As you all might know JOELib had not really an interface definition for 
>all relevant classes, this was much improved in the JOELib2 version (see 
>code stability metric).
>So, i think such things should forwarded to the single projects and are an 
>maintenance task, like building and getting a valid distribution. I think 
>those things should be added and consolidated in the ANT build.xml files 
>to do things automatically, then we will see if it works.
>Every project can add specific targets, like
>buildForJDK14, buildForJDK15

Agreed and I think we shall do this. It is a question of what we 
distribute. I don't want to distribute JUMBO5(1.4) and JUMBO5(1.5) for example!

>======================
>>  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.
>I'm aware of this problem and had also some nasty debugging experience 
>with those awfull library dependencies, but i have not really a solution 
>for that. As you know i'm a friend of all-in-one libraries, so i think the 
>guys with binding all those dependecies in one release should create an 
>automatic version for such things, e.g. removing cross-dependencies 
>automatically and release those ANT build-files, then the other projects 
>can decide what to do.

I agree that for specific applications this is a good strategy.

>>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.
>That's a code stability metric (interface) problem. Welcome to software 
>engineering problems, thats why i changed the version with a heavily 
>redesign. For JOELib2, which is still alpha, this is also the case, but i 
>can not froze all methods and classes, if a redesign is highly recommended 
>to be more user friendly and more stable for the future.

Understood. It is very difficult to balance flexibility and innovation.

>!!!
>I know that general interfaces are crucial important, but hey ... we are 
>working on that ... and we have still a long way to go ... so use as much 
>automatic testing and deployment as possible. Things like suggested also 
>in the book:
>Pragmatic Project Automation
>http://www.pragmaticprogrammer.com/sk/auto/
>
>Additionally we have still communication problems and different interests 
>with our projects and time slides, so there is no quick-fix for this problem.
>
>We are still focused on single tasks, but there is still a binding element 
>missing, which is an ungrateful job, because you will have a lot of work 
>to understand other projects and to design a common interface with the 
>prospect for being unable to publish one scientific paper.
>!!!

Yes. We have been slightly fortunate in that some of our funding has been 
for infrastructure. But we still have to publish it. (Incidentally JUMBO4.6 
distrib has copies of the papers and presentations that we are allowed to 
distribute - papers in JCICS cannot be redistributed - I am talking on this 
at the ACS)

>>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.
>1. I know that, that one reason why i decided to include a lot of the 
>functionality as source code dependency into JOELib, too. Especially if i 
>had some relevant changes at the interface or functionality.
>
>2. I do not really like the idea to abuse web-services as a common 
>interface, thats not really helpfull to create a common interface between 
>all projects, this binds only developer resources of several projects to 
>implement web-services.

I understand this view. Each of us will have their own dividing line. For 
example if you want a 3D structure it may be worth making a webservice call 
rather than linking in megabytes of code and data. But if you want to count 
hydrogens you need a local routine.

>So again, this is a software engineering problem, we need exact 
>requirement definitions for an interfaces here, or we will loose a lot of 
>time to implement functionalites, also sometimes twice.
>Not that i have a solution, but we have simply too much code and too much 
>functionality to get here a fast solution.
>And i can speak only for myself, i have absolutely no time to define such 
>an interface at the moment. Maybe an interface-Wiki might help us for the 
>discussion, but i am not too optimistic here.

We are all in the same position! But I think we have made much progress in 
the last 2 years and there is a lot of convergence.

P.


Peter Murray-Rust
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK
Tel: +44-1223-763069