[Jmol-developers] [ jmol-Bugs-1651741 ] vecmath conflict on OS X

[SourceForge.net <no...@so...>]

Bugs item #1651741, was opened at 2007-02-04 15:52
Message generated for change (Comment added) made by nicove
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1651741&group_id=23629

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: molvisions (molvisions)
Assigned to: Nicolas (nicove)
Summary: vecmath conflict on OS X

Initial Comment:
hi,

some time ago, the email list carried a discussion about a problem between Jmol and the existing vecmath.jar on OS X.

I continue to have trouble compiling Jmol on my OS X machine - I must remove vecmath.jar, compile Jmol, and then replace vecmath.jar.  this has become very frustrating.

can someone please explain why this is happening, and what steps can be taken to resolve the issue?  if it is a problem with the OS, I will be happy to submit a bug to Apple, as long as someone can provide a concise technical description of the actual problem.

this is Apple's Month of Bugs so we may have an increased chance of having it fixed.

thanks,

tim

----------------------------------------------------------------------

>Comment By: Nicolas (nicove)
Date: 2007-02-04 19:09

Message:
Logged In: YES 
user_id=1096197
Originator: NO

Bob,

don't worry with the null ;)

the exception handling in cloneAtom() is just cosmetics to make the
compiler happy. The only reasons that could trigger exceptions that I
could see are memory problems, and they would also be present with copying
informations manually. CloneNotSupportedException will never be thrown.

Nico


----------------------------------------------------------------------

Comment By: Bob Hanson (hansonr)
Date: 2007-02-04 18:18

Message:
Logged In: YES 
user_id=1082841
Originator: NO

What is the purpose of returning null from cloneAtom? Won't that break the
implementation? 
Let's see:

Atom Atom.cloneAtom() is called only by AtomsetCollection.newCloneAtom()
The exception handling delivers a null Atom. 

But newCloneAtom() is called by

appendAtomSetCollection(...)
cloneFirstAtomSet()
cloneLastAtomSet()
symmetryAddAtoms(...)

If these methods assign null to an atom, doesn't that cause major
problems?
I'm suggesting perhaps we should not rely on clone(), or at least not
return null. 
It's not such a big deal to just manually copy the information to a new
atom, is it?

Bob


----------------------------------------------------------------------

Comment By: Nicolas (nicove)
Date: 2007-02-04 17:47

Message:
Logged In: YES 
user_id=1096197
Originator: NO

Good !

IMHO, Exception is a little better than Throwable in this case.
You can commit the change if you want.

Nico

----------------------------------------------------------------------

Comment By: molvisions (molvisions)
Date: 2007-02-04 17:40

Message:
Logged In: YES 
user_id=920824
Originator: YES

hi Nico,

thanks for the direction.  replacing CloneNotSupportedException with
Exception or Throwable results in successful compile and launch.  is one
better than another?

tim

----------------------------------------------------------------------

Comment By: Nicolas (nicove)
Date: 2007-02-04 17:27

Message:
Logged In: YES 
user_id=1096197
Originator: NO

Tim,

The modification should be quite simple, it's just replacing one word in
/org/jmol/adapter/smarter/Atom.java.

The current implementation of the cloneAtom() method in
org.jmol.adapter.smarter.Atom is :
  Atom cloneAtom() {
    try {
      return (Atom)super.clone();
    } catch (CloneNotSupportedException cnse) {
      return null;
    }
  }

Could you try replacing the CloneNotSupportedExcetion by Exception,
giving:
  Atom cloneAtom() {
    try {
      return (Atom)super.clone();
    } catch (Exception cnse) {
      return null;
    }
  }

If it doesn't work, we can try Throwable instead of Exception:
  Atom cloneAtom() {
    try {
      return (Atom)super.clone();
    } catch (Throwable cnse) {
      return null;
    }
  }


----------------------------------------------------------------------

Comment By: Miguel (migueljmol)
Date: 2007-02-04 17:21

Message:
Logged In: YES 
user_id=1050060
Originator: NO

> in any case, my compiler error seems consistent with Nico's 
> explanation of the problem:

Nico is "the man" :-)

> if it helps, I can submit this as a bug to either Sun or
> Apple, or both. 

No need ... ignore my posting. Nico understands the issue. 


Miguel


----------------------------------------------------------------------

Comment By: molvisions (molvisions)
Date: 2007-02-04 17:18

Message:
Logged In: YES 
user_id=920824
Originator: YES

hi all,

thanks for the speedy responses.

Miguel, I was not clear - I am removing and replacing the OS vecmath.jar,
which is found in /System/Library/Jmol/Extensions.  I am not touching any
files in my Jmol copy at all.  I have not tried outright removing
vecmath.jar - but if I remove it from my Jmol copy, won't it be replaced
every time I update from the repo?  I suppose I can try removing the OS
copy for good...

in any case, my compiler error seems consistent with Nico's explanation of
the problem:

    [javac] /java/jmol/Jmol/src/org/jmol/adapter/smarter/Atom.java:58:
exception java.lang.CloneNotSupportedException is never thrown in body of
corresponding try statement
    [javac]     } catch (CloneNotSupportedException cnse) {
    [javac]       ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] 1 error


if it helps, I can submit this as a bug to either Sun or Apple, or both. 
not that I have any special channels; I would be just another voice in the
wilderness.

Nico, I am not versed in Java, so I doubt I could implement the change
that you suggest in a reasonable time frame.  sorry :-(   I'll be happy to
test any patches on my system, though, if you need an OS X.


best,

tim


----------------------------------------------------------------------

Comment By: Egon Willighagen (egonw)
Date: 2007-02-04 16:44

Message:
Logged In: YES 
user_id=25678
Originator: NO

Since CDK 1.0 is imminent, we have been discussing post 1.0 last week at
the CDK workshop... one thing that came up is the use of vecmath, because
CDK really uses only a rather small part of that library.

What bits of the vecmath does Jmol need? Is there no way to replace the
functionality?
How many classes and methods are really used?

----------------------------------------------------------------------

Comment By: Nicolas (nicove)
Date: 2007-02-04 16:35

Message:
Logged In: YES 
user_id=1096197
Originator: NO

Hi Miguel,

we just cross-posted on this :)
I diagnosed this problem a few months ago, and it was also on OS X. For
me, this is really a compatibility problem between several versions of
vecmath specifications.

Nico

----------------------------------------------------------------------

Comment By: Nicolas (nicove)
Date: 2007-02-04 16:29

Message:
Logged In: YES 
user_id=1096197
Originator: NO

The problem is due to the vecmath library itself.

The class org.jmol.adapter.smarter.Atom extends Point3f from vecmath and
defines a cloneAtom() method to clone itself.

In the first releases of vecmath (the one that is bundled with Jmol is 1.2
compatible), Point3f didn't implement the Cloneable interface and so the
clone() method was the one defined in Object itself: "Object clone()
throws CloneNotSupportedException". Notice the "throws
CloneNotSupportedException".
In this situation, our cloneAtom() method must either explicitely catch
this exception or explicitely throw it.

In the following releases of vecmath, Point3f did implement Cloneable, but
the clone method() was defined as "Object clone()". Notice the missing
"throws CloneNotSupportedException".
In this situation, our cloneAtom() method mustn't catch this exception or
throw it (exactly the opposite of the first releases).

A working solution (but not very clean) should be to modify our
cloneAtom() method to catch an exception higher in the class hierarchy
(Exception or Throwable) instead of CloneNotSupportedException. Could you
try this patch on your own system ?

Nico

----------------------------------------------------------------------

Comment By: Miguel (migueljmol)
Date: 2007-02-04 16:24

Message:
Logged In: YES 
user_id=1050060
Originator: NO

Tim,

I have been out of this for some time ... up until now I was not aware of
this problem ... but I'll tell you what I know and will speculate as to
the cause. 

The vecmath package that is used by Jmol is implementing an interface that
was defined by Sun with Java3D. That is, it is an open source
implementation of the API. It reuses exactly the same package/class names.


In general I think that this was a pretty good thing. It provided a
well-defined nearly 'standard' API to vector math that was needed for 3D
calculations. The documentation provided by Sun was/is pretty good. 

Over the past few years I have lobbied Sun to include the vector math
packages in the standard Java distributions. As of about two years ago I
received responses from someone at Sun saying that it was "on their list
of things to do". But, in reality, no one knows how long that list was/is
... and they probably have very limited resources. 

Now, with respect to Apple and Java on OSX ...

Apple has a unique agreement with Sun and they build their own Java
distributions. 

I strongly suspect that Apple is including the vecmath packages in their
distribution and that is the source of your problems. 

That is, there is a class library conflict of some type going on. 

Note that this was not a problem in the old days. A few (4) years ago
there were several people (including Egon perhaps) who were running Java3D
on the same box as Jmol without having any class library conflict. But the
rules may have changed because *if* java3d.vecmath is now part of a
standard class-library distribution then the class library security may be
tighter ... in order to prevent someone from overriding a standard class
library with a rogue imposter implementation. 

I suspect that one of a few of things is happening:

1) Apple has incorporated the vecmath package into their core Java
libraries. They may have done this before it has made it into the Sun
distributions. This may be because Apple is being responsive to the (3D
oriented) needs of its customer base. Overall, I this would be a good
thing ... it is what I asked Sun to do for years. 

2) Apple may have tried to incorporate all of Java3D, including the
vecmath stuff, into its core distribution. Overall, this would be a bad
thing ... because Java 3D is dead. 

3) I suppose that it is possible that vecmath is now included in the Sun
1.6 distributions. If that were the case then either:
 a) no other Jmol developers have upgraded to Java 1.6, so they are not
seeing the problem
 b) there is no class library conflict on other platforms. 

Tim, you said:

 > I must remove vecmath.jar, compile Jmol, and then replace vecmath.jar.


Q: Please confirm that we are talking about the application, not the
applet. 

Q: Are you sure that you must 'replace' vecmath.jar? 

Q: What happens if you don't replace it? (I think it should work, pulling
java3d.vecmath packages from the 'standard class libraries')

Q: Try to capture a sample of the compiler error output when you do not
remove our 'imposter' vecmath.jar. 


Miguel


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1651741&group_id=23629