[Source] problem with jgeom build, java3d dependency
Don Brutzman
brutzman at nps.edu
Thu Jan 2 13:44:54 PST 2014
Vince, I updated my version of jgeom to launch the new "example" target in the build.xml that launches ArbitraryNURBSGeometry.java.
<target name="example"
description="Run simple demonstration application"
depends="dist">
<java classname="net.jgeom.j3d.examples.ArbitraryNURBSGeometry" fork="true">
<classpath>
<pathelement location="${dist}/lib/jgeom-core.jar"/>
<pathelement location="${lib.dir}/vecmath.jar"/>
<pathelement location="${lib.dir}/j3dcore.jar"/>
<pathelement location="${lib.dir}/j3dutils.jar"/>
</classpath>
</java>
</target>
I get a pretty curious error:
ant -f C:\\code\\java\\jgeom-code\\trunk example
init:
compile:
dist:
example:
Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: C:\Windows\j3dcore-ogl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1880)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at javax.media.j3d.NativePipeline$1.run(NativePipeline.java:231)
at java.security.AccessController.doPrivileged(Native Method)
at javax.media.j3d.NativePipeline.loadLibrary(NativePipeline.java:200)
at javax.media.j3d.NativePipeline.loadLibraries(NativePipeline.java:157)
at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:987)
at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:299)
at net.jgeom.j3d.examples.ArbitraryNURBSGeometry.init(Unknown Source)
at com.sun.j3d.utils.applet.MainFrame.run(MainFrame.java:267)
at java.lang.Thread.run(Thread.java:744)
So it looks like the j3dcore.jar we loaded into the jgeom/lib directory isn't portable? :(
Looking back through our past thread below, the Oracle distribution page does include java3d versions for different OS's.
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138252.html
I downloaded the AMD64 version and installed it, which landed in
C:\Program Files\Java\Java3D\1.5.1
Then copied over the three .jar files found there into the jgeom/lib directory but no joy, same error.
Sure enough the files are in my Windows operating system, not hardwired somehow into the .jar files.
Don at it153485 /cygdrive/c/windows
$ ls -al j3d*
-rwx------+ 1 Administrators None 823296 Jun 30 2008 j3dcore-d3d.dll
-rwx------+ 1 Administrators None 163840 Jun 30 2008 j3dcore-ogl.dll
-rwx------+ 1 Administrators None 40960 Jun 30 2008 j3dcore-ogl-cg.dll
-rwx------+ 1 Administrators None 49152 Jun 30 2008 j3dcore-ogl-chk.dll
I suspect that the path you have in the jgeom build.xml is getting honored, but the system .dll that is previously installed is taking priority despite a fresh install.
Sure enough, my Windows control panel shows both 1.5.1 and 1.5.2 installed... will uninstall both and reboot, back in a few minutes...
Hunh. Only good thing, I guess, is that this is why we work in open standards, so that our actual models might stay workable regardless of the twists/turns associated with commercial companies.
On 11/27/2013 5:45 AM, Vincent Marchetti wrote:
> Don,
>
> I gather from this that you've solved one problem and thus found
> another -- which I may have solved, see below.
>
> The problem you found was that the more recently submitted source
> file src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java
> depends at compile-time on the package javax.media.j3d ('Java3d')
> which either wasn't on your system or wasn't in the search path of
> your development environment. You solved the problem by installing
> this package and/or setting your search paths to find it. You raised
> the possibility of distributing this package with jgeom.
>
> I'm not sure if distributing javax.media.j3d package with jgeom is a
> good idea (even though we partially do this by including vecmath.jar
> in our distribution). I may have to ponder this over some pumpkin
> pie, or at least try to find out what the Best Practices are thought
> to be for this. I thought the javax.* packages were supposed to be
> standard extensions, preinstalled or maintained by the JRE; and I
> wonder what other incompatibilities will be introduced if we start
> substituting our own updates to Java3d.
>
> On my own system (the venerable Mac OS X 10.6.8, running Java 1.6) I
> didn't have this problem -- I built everything from command line with
> 'ant', and it found the system-installed Java3d package without a
> problem. I skipped immediately to the second problem you found, that
> the new source
> src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java also
> depends for compilation on the package net.jgeom.j3d.objects . I
> found this in another archive Sam Gerber sent us called 'jgeom
> extras'. I have entered this into the archive, and its jgeom
> dependencies, into the jgeom repository.
>
> So my status report is that the svn.code.sf.net/p/jgeom/code
> repository at rev 21 builds using my system-installed Java3d. I have
> not been able to actually run the ArbitraryNURBSGeometry applet.>
> Vince
>
> On Nov 24, 2013, at 9:06 PM, Don Brutzman wrote:
>
>> [cc: source at web3d.org mailing list which would seem to have some overlap with jgeom - does that seem OK? it is the 'source' list, after all... and there are multiple overlaps of interest, especially since jgeom is used by Xj3D. or perhaps there is a better place for jgeom discussion?]
>>
>> Hi Vince. There is a problem with the jgeom build that has been lingering for awhile. Error log excerpt:
>>
>> https://savage.nps.edu/jenkins/job/jgeom/
>> https://savage.nps.edu/jenkins/job/jgeom/109/console
>>
>> Looks like ArbitraryNURBSGeometry.java failing, it is looking for java3d. This file was checked in some time ago as an example use of jgeom.
>>
>>> Started by timer
>>> Building in workspace /var/lib/jenkins/jobs/jgeom/workspace
>>> Updating http://svn.code.sf.net/p/jgeom/code/trunk at revision '2013-11-24T07:08:17.007 -0800'
>>> At revision 20
>>> no change for http://svn.code.sf.net/p/jgeom/code/trunk since the previous build
>>> [workspace] $ /usr/java/apache-ant-1.8.2/bin/ant all
>>> Buildfile: /var/lib/jenkins/jobs/jgeom/workspace/build.xml
>>>
>>> init:
>>>
>>> compile:
>>> [javac] Compiling 59 source files to /var/lib/jenkins/jobs/jgeom/workspace/build
>>> [javac] /var/lib/jenkins/jobs/jgeom/workspace/src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java:26: error: package javax.media.j3d does not exist
>>> [javac] import javax.media.j3d.Alpha;
>>> [javac] ^
>>> [javac] /var/lib/jenkins/jobs/jgeom/workspace/src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java:27: error: package javax.media.j3d does not exist
>>> [javac] import javax.media.j3d.AmbientLight;
>>> [javac] ^
>> etc. etc.
>>
>> Not 100% sure, but it looks like the latest java3d (built back in the days of Sun Microsystems) is at
>> http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138252.html
>>
>> Latest version found there is java3d 1.5.2 which README says requires JDK 1.5.0 or later
>>
>> /cygdrive/c/Program Files (x86)/Java/Java3D/1.5.2/lib/ext
>> $ ls -al
>> -rwx------+ 1 SYSTEM SYSTEM 2957997 Jun 30 2008 j3dcore.jar
>> -rwx------+ 1 SYSTEM SYSTEM 1704635 Jun 30 2008 j3dutils.jar
>> -rwx------+ 1 SYSTEM SYSTEM 318956 Jun 30 2008 vecmath.jar
>>
>> Inspecting this downloaded vecmath.jar shows
>>>
>>> Extension-Name: javax.vecmath
>>> Implementation-Version: 1.5.2
>>
>> We already have vecmath.jar version 1.5.1 in the jgeom/lib directory:
>>> Extension-Name: javax.vecmath
>>> Implementation-Version: 1.5.1
>>
>> So upgrading that shouldn't be a problem... Wondering if we should place all three of these later java3d jars in the jgeom/lib directory? Seems safe to do.
>>
>> So I tested that. Adding them on my local copy of jgeom (and updating the netbeans project lib references) greatly cleans up the errors in this class, leaving only:
>>
>>> Compiling 59 source files to C:\java\jgeom\build
>>> C:\java\jgeom\src\java\net\jgeom\j3d\examples\ArbitraryNURBSGeometry.java:42: error: package net.jgeom.j3d.objects does not exist
>>> import net.jgeom.j3d.objects.NurbsSurfaceShape;
>>> C:\java\jgeom\src\java\net\jgeom\j3d\examples\ArbitraryNURBSGeometry.java:154: error: cannot find symbol
>>> NurbsSurfaceShape nss = new NurbsSurfaceShape(ns);
>>> symbol: class NurbsSurfaceShape
>>> location: class ArbitraryNURBSGeometry
>>> C:\java\jgeom\src\java\net\jgeom\j3d\examples\ArbitraryNURBSGeometry.java:154: error: cannot find symbol
>>> NurbsSurfaceShape nss = new NurbsSurfaceShape(ns);
>>> symbol: class NurbsSurfaceShape
>>> location: class ArbitraryNURBSGeometry
>>
>> So it would seem that the jgeom class library evolved since this earlier example was written.
>>
>> Anyway, let me know if you agree that we should check in this version of java3d to the jgeom libs, and we can then continue troubleshooting this example (and maybe get some others too).
>>
>> All feedback welcome, thanks for looking at this.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
More information about the Source
mailing list