OSGi: need J3D 1.6 source code for a patch

Hello, I need J3D to run in an OSGi environment. The problem is that is is not compatible as is. Good news is that with very few changes, J3D may be converted to a nice working bundle.

As I was not able to find J3D 1.6.0 sources, I patched J3D 1.6.0 with a source from the 1.5 version. This works fine for most OS/JDK versions. However it seems to fail with some combination of OS/Java such as RHED6 & Java 1.6.0_45 (works ok with 1.6.0_18).

Where may I find J3D 1.6.0 or later sources?

On 10/31/2013 10:46 AM, JeanPhi [via jogamp] wrote: Dunno about 1.6.0 in particular,
but Harvey maintains the compatible JogAmp continuation
based on same source code.

If you are reluctant to use the new Java3D version,
you still can find the whole 'history' in the git resources below.

However, I we sure would like to see you using our latest
code - and allow Harvey to merge it.

Pls contact Harvey (here) .. he probably will reply soon.

http://jogamp.org/git/?p=java3d/java3d-core.git;a=summary
http://jogamp.org/git/?p=java3d/java3d-utils.git;a=summary
http://jogamp.org/git/?p=java3d/vecmath.git;a=summary

~Sven

I'm not too sure what you call new Java3D version  - sorry

In fact I just want at least J3D 1.6.0 to work as OSGi bundle. I can also provide the change in order to let it work as bundle if it can be added to the "new" J3D.

Is the 1.6.0-pre8 you mentioned > 1.6.0 "official"?

Hi

JeanPhi wrote

I'm not too sure what you call new Java3D version  - sorry

In fact I just want at least J3D 1.6.0 to work as OSGi bundle. I can also provide the change in order to let it work as bundle if it can be added to the "new" J3D.

Is the 1.6.0-pre8 you mentioned > 1.6.0 "official"?

The source code of Java3D is here:
https://github.com/hharrison/java3d-core
https://github.com/hharrison/java3d-utils
https://github.com/hharrison/vecmath

Java3D (<= 1.5.x) was originally maintained by Sun/Oracle but it stopped doing it several years ago. I initiated the port of Java3D to JOGL 2 (Java3D 1.6) and Harvey goes on maintaining it now. This is the only actively maintained version currently available of Java3D, this is the version 1.6.0 pre8.

Best regards.

Edit.: Sven already gave you the link to the source code, sorry.

Ok, thanks!

However I'm not used to GIT and my company does not allow internet connection from development machines. I don't find any source file via browsing the mentioned source url

Clicking everywhere always lead to more or less the same page... is there a way to download the source code as an archive?

There is a button named "Download ZIP" in the bottom right corner of each Github page I gave you in my previous post.

If you want to make pull requests, you'll need GIT and I advise you to learn how to use it, it is not very difficult. I was accustomed to use SVN in the past.

What kind of changes are required for OSGI?  There is no java3d 1.6.0 release yet, only prereleases, the current release is
1.6.0-pre8.  If you're willing to maintain the OSGI stuff, I'm certainly willing to take your patches.

Harvey

Yes Harvey could take JeanPhi's patches sent by email or whatever, just make things clear. GIT is not mandatory but it is the preferred way. JeanPhi, your contributions would still mention the attribution (the paternity of the changes).

Each OSGi bundle has its own class loader. Each object related class belongs to a classloader. Hence there are as many class instances per object type as number of bundles which uses it.

J3D initializes itself at class loading. So, in an OSGi world this means one initialization per bundle which makes use of J3D. This is a big problem as Java prevents JNI code from being loaded more than once.

So the cure is to decouple class loading and initialization. At present time I patched VirtualUniverse changing the static {} block to a static method init() {}. Then I created a bundle with a basic blueprint configuration <bean class="...J3DInitializer"/> along with the simple implementation:
public final class J3DInitializer {
 static {
  VirtualUniverse.init();
  // Log init ok
 }
}

The drawback is that previous code which makes use of J3D will not work without explicit call to init().

What can easily be done is to deprecate VirtualUniverse and clone it to J3DUniverse or so with the static method renamed to init() as above.

Could be good also if you could provide J3D as a bundle (means manifest file containing OSGi entries + bundle activator or blueprint as above).

Hmm, at this point I'm not really that interested if it is going to break existing users, if you can find a way to do this that
wouldn't break old uses, I'd still be interested in the patches.

Did Java3d ever work as an OSGi bundle?  Is this a regression in the changes i've made, or is this a new use case?

Cheers,

Harvey

It's a new use case, as far as I know J3D has never been a bundle.

You can do what I suggested not to break existing usage, i.e. deprecate VirtualUniverse, copy-paste it as a new class and change its static { ... } method to a public static init() { ... } one. This would be a first step to build a bundle around J3D.

Then, a plus would be to fill the manifest file with OSGi ad'hoc entries and create a BundleActivator to call the new init() method.

Are you using Maven?

The framework uDig already supports Java3D as an OSGI bundle but it uses an old version.

Some tools can transform jars to bundles but this not mean that the initial jars are bundles.

Anyway, would it be possible to deprecate VirtualUniverse and add the new one?

We can't deprecate VirtualUniverse, the stable release of Java3D 1.6 is coming very soon. The aim of this project consists in keeping Java3D in maintenance mode, with almost no change in the public API, so that developers using Java3D 1.5.2 don't need to modify their source code. A new "feature" can be added into Java3D if and only if it has a very low impact. I have nothing against OSGI, I used it for years but Harvey is alone most of the time to maintain Java3D, some developers sometimes contribute, I would like to find a solution allowing to support OSGI with Java3D 1.6 as is. I know that some corporations made OSGI bundles for JOGL, it should be possible to do the same with Java3D without changing the source code.

Keep in mind that Java3D isn't future proof, it doesn't support the Core Profile, it has no NEWT canvas, it doesn't support Android. Maybe we can study how the maintainers of other engines solve this kind of problem, some Ardor3D users tried to make an OSGI bundle.

Ok.

Would it be possible at leat to create the OSGi clone of VirtualUniverse?

Does it require to copy/paste the whole source code of VirtualUniverse?

Yes. The cause is that any reference to VirtualUniverse would call its static {} method wich would try to initialize... and fail if already initialized.

Ah another point is there are a lot of system.out in VirtualUniverse; use of logging instead would be welcome!

Hum, I just checked and VirtualUniverse is referenced by other classes. So it will be a bit more complicated:
1. All(*) references to VirtualUniverse must point to the new "cloned" class (let's call it J3DUniverse)
2. VirtualUniverse methods should delegate to J3DUniverse
*. Don't change non-mandatory classes such as LocaleFactory, SimpleUniverse...

Would developers have to call J3DUniverse.init()? Maybe the static initializer of VirtualUniverse could call J3DUniverse.init().

If Java 3D has to be packaged as an OSGI bundle, JOGL will have to be available as an OSGI bundle too.

Developers would have either to call J3DUniverse.init() and use only J3DUniverse or to continue using VirtualUniverse (which self-initiates).

I would say building a bundle over an existing jar is not difficult (especialy whith Maven). The real problem is static usage within the code as static means static for a given classloader. So, allowing to initiate J3D without static involvement is the very first step.

PS: at present time I embed utils and vecmath which is not nice but is sufficient for what I have to do