Circular dependency between java3d-core and java3d-utils

[ctrueden]

The class javax.media.j3d.Font3D of j3d-core imports classes from package com.sun.j3d.utils.geometry, which is part of j3d-core-utils. And the j3d-core-utils project imports many classes from j3d-core. This creates a circular dependency between artifacts.

My understanding is that the java3d-utils should depend on java3d-core, but not vice versa. Correct? If so, what is the best way to correct this issue?

[hharrison]

It has always been that way which is why you have to build java3d and
java3d-utils together as one build currently.

There used to be more circular issues that I removed over time, this is the
last one.

Harvey

On Thu, Apr 9, 2015 at 9:32 AM, Curtis Rueden notifications@github.com
wrote:

The class javax.media.j3d.Font3D of java3d-core imports classes from
package com.sun.j3d.utils.geometry, which is part of java3d-utils. And
the java3d-utils project imports many classes from java3d-core. This
creates a circular dependency between artifacts.

My understanding is that the java3d-utils should depend on java3d-core,
but not vice versa. Correct? If so, what is the best way to correct this
issue?

—
Reply to this email directly or view it on GitHub
#17.

[ctrueden]

Thanks for the quick reply, @hharrison. The easiest way to fix it would be to just merge the two projects! But I understand if that is deemed somehow too disruptive of a change.

Do you have a preferred approach for eliminating the remaining circular references? There are several reasons it would be a really good idea to completely address this issue. For one thing, Maven does not support circular dependencies. So it will not be possible to address #14 properly until this issue is resolved.

[hharrison]

I'll try and give a brain dump of the issues involved while I have a few
minutes.

1. Merging the two projects

• incompatible licenses (well, kind of)
• fedora would be willing to ship Java3d-core, but would not be wiling to
  ship java3d-utils
  so I'd vastly prefer any solution that makes java3d-utils sit on top of
  j3dcore without any
  circular dependency.

2. The only remaining dependency is using the triangulator and normal
   generator from j3d-utils
   to break text characters into triangle arrays, if suitably licensed code
   could be writen/borrowed
   we could add that directly to java3d and be done with it. (I don't really
   have the time currently)

3. We could ask Oracle to release a plain BSD-licensed version of the files
   in question, import those
   to java3d-core and remove them from java3d-utils...but getting anyone over
   there to pay attention
   has been fruitless.

4. Clever option 4 that you come up with ;-)

Harvey

On Thu, Apr 9, 2015 at 9:40 AM, Curtis Rueden notifications@github.com
wrote:

Thanks for the quick reply, @hharrison https://github.com/hharrison.
The easiest way to fix it would be to just merge the two projects! But I
understand if that is deemed somehow too disruptive of a change.

Do you have a preferred approach for eliminating the remaining circular
references? There are several reasons it would be a really good idea to
completely address this issue. For one thing, Maven does not support
circular dependencies. So it will not be possible to address #14
#14 properly until this
issue is resolved.

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

[ctrueden]

Here are some "option 4" possibilities:

4a) In Font3D, access GeometryInfo and NormalGenerator only via reflection. And if the classes are not found, then somehow fail gracefully, or throw an appropriate exception.

• This is a quick and dirty hack. The downside is that reflection brings class loading issues with it. You have to be very careful that things still work as expected when custom class loaders (e.g., OSGi) are being used.

4b) Use dependency injection / service discovery. Specifically: add some kind of geometry service that declares the needed API, then call it from Font3D. Provide a stub implementation that simply throws exceptions in j3d-core. And in j3d-core-utils, provide a geometry service that calls into GeometryInfo and NormalGenerator to do the work.

• To do this, we'd have to settle on a reasonable services framework. Probably easiest to use Java's built-in ServiceLoader; this is how e.g. JSR-223 scripting languages are provided.

4c) Split the projects into more pieces, to ensure the dependency graph has no cycles. This would also be disruptive, and have significant consequences, including making the project structure less intuitive. I list it here mainly for completeness.

If option 4a or 4b interests you, let me know and I can look into creating a patch set for it.

[ctrueden]

@hharrison OK, I took a crack at option 4b. Right now I implemented on top of my maven branch, since that was much easier for me (makes developing in Eclipse a breeze). But if you like the approach, I am willing to rebase it over master so that it works with the Ant-based build system. Just let me know.

• 6206d42
• https://github.com/ctrueden/java3d-utils/commit/94df54c2ea1192459181907f69b48df1db3b8091

[hharrison]

Merged your changes as-proposed into version 1.6.2, thanks a lot for the work and sorry for the wait!