Where is the latest version of Java3D

I found two versions:

https://jogamp.org/deployment/java3d/1.7.0-pre1/
https://jogamp.org/deployment/java3d/1.6.2/

But somehow 1.7.0 seems to have been built 2 years earlier than 1.6.2

(1) Which one is the latest build?

(2) what's the correct j3d package?
Is it "org.jogamp.java3d" or "javax.media.j3d"?

I thought we switched to "org.jogamp.java3d" but in the latest github version of Java3D it seems to be "javax.media.j3d:

https://github.com/hharrison/java3d-core/blob/master/src/javax/media/j3d/Alpha.java

(3) Is the latest Java3D build compatible with latest Jogl build?

Hello

Java3D 1.6 still exists because some developers don't want to modify their import clauses, some bug fixes are backported but I strongly encourage all Java3D users to switch to Java3D 1.7 that should contain all bug fixes and that contains all new features.

Personally, I don't get the reason to refuse updating the import clauses, including in very large code bases. I did so, it's not the end of the world.

@Phil, can you reply more precisely about Java3D 1.7?

On 1/23/20 10:46 AM, gouessej [via jogamp] wrote:
> Hello

Thank you Julien.

>
> Java3D 1.6 still exists because some developers don't want to modify their
> import clauses, some bug fixes are backported but I strongly encourage all
> Java3D users to switch to Java3D 1.7 that should contain all bug fixes and
> that contains all new features.
>
> Personally, I don't get the reason to refuse updating the import clauses,
> including in very large code bases. I did so, it's not the end of the world.

At JogAmp we changed the namespace (import clause) for all packages
a while ago to pre-emptively avoid any (legal) issues with the
owner of said namespace.

We thought it is imperative to keep the project alive
in an independent fashion.

I strongly advise Java3D to follow suit and to abandon the original
namespace, as the latter may render commercial utilization
difficult due to granted terms of use of the running Java[tm] environment.

Hope it helps.

>
> @Phil, can you reply more precisely about Java3D 1.7?

Yes, Phil is currently the ruling maintainer of Java3D.

Cheers, Sven

Yes I totally agree with you, that's why this change was started by myself several years ago in Java3D 1.7. What a bad idea to keep "javax". JakartaEE >= 9 does the same, it drops the "javax" namespace.

Thank you.
But that still begs the question of why Java3D 1.7 built is 2 years ago whereas Java 1.6.2 built is much newer?
I guess I have to wait for @Phil to answer that question.

There's a Java3D 1.7.0 pre2 here:
https://github.com/philjord/java3d-utils/releases/tag/1.7.0-pre2

I'll have to update https://jogamp.org/deployment/java3d/ too, sorry.

Github should only be used as a mirror anyway.

On 1/24/20 10:06 AM, gouessej [via jogamp] wrote:
> There's a Java3D 1.7.0 pre2 here:
> https://github.com/philjord/java3d-utils/releases/tag/1.7.0-pre2

This is the git repo we would use for builds
and which Philip/phil now controls:
<https://jogamp.org/cgit/java3d/>
<https://jogamp.org/cgit/java3d/java3d-utils.git/>

~Sven

>
> I'll have to update https://jogamp.org/deployment/java3d/ too, sorry.

Julien and Phil have write access to this folder.

All good.

~Sven

Thank you.
So what's the deal with Harrison's repository then?
It seem to have some fixes that are missing in Phill's repository.

For example, Harrison support "j3d.numSamples" flag which I need. See here:

https://github.com/hharrison/java3d-core/blob/master/src/javax/media/j3d/JoglPipeline.java#L8318

But this flag seem to be missing from Phill's version. See here:
https://github.com/philjord/java3d-core/blob/master/src/main/java/org/jogamp/java3d/JoglPipeline.java#L8376

Are there any plans to add support for setting "numSamples" soon? or am I forced to used Harrison version?

Runiter,
You're dead right that fix is missing from the JoglPipeline of the 1.7.0 code line.

I'm not entirely sure why that one bug fix wasn't taken across, Harvey wrapped up and release 1.6.0 3 years ago, and in doing so put in a few final bug fixes.

Because of the package name change I couldn't easily pull those one off patches into the 1.7.0 code line so I manually took them across, checking now I see that the commit before the numSamples and the commit after it  were both taken across, but somehow I missed the numSamples commit.

I've released 1.7.0 (which is just waiting to be put up on maven central) so I'll patch this into dev 1.7.1 branch shortly if that works for you.

Thanks for spotting this problem.

Phil.

Just to reference teh other items on timelines etc.
1.7.0-final is the latest stable release of Java3D 1.7.0 released 3 months ago, it hasn't however been marked as a release in git-hub yet, because I need to wait for a successful push to maven central via the pom.xml file configuration in that commit (or any alterations to that file). Sven and I are working on this, but it is "behind" the jogl 2.4.0 release being configured and pushed to central.

https://jogamp.org/deployment/java3d/ can be updated now (I think I was waiting for the release in git-hub) I'll do this now.

With reference to the other minor release of Java 1.6.0 Harvey is just keeping that release up to date with critical/important alterations in the 1.7.0 code line now, because as Julien (et al) point out the package names diverged and some users are not able to use 1.7.0 for historic reasons.

Thanks Phil, your answers to my questions makes total sense. I now understand what's going on :)

A source of my confusion was that when I search "java3d github" in google, Harrison version shows up first and yours shows up second. So I assumed harrison was the official version.

I can wait until 1.7.1 is released.

Ok thanks, I've pushed it to dev 1.7.1 now.

There's a few really good pull requests from Egor  that will be in dev 1.7.1 shortly.

I've updated the deployment directory so 1.7.0-final now exists.

Harvey getting the search results is fair, I haven't done anywhere near the work he has done, but possibly in the future google will notice activity on my account...

I'll update the jogamp wiki and maintainers page to make it more obvious that I should be the main contact. We could put a java3d fork into the jogamp github repo to indicate which is the main java3d repo, I guess, that would be more Sven call than mine.

Another option might be to publicize that scm on jogamp should be seen as the latest version (which is of course a copy of my github repo)

Once again, thanks for looking into this and actually providing the bug reproduction and fix in full.

On 1/25/20 6:38 AM, philjord [via jogamp] wrote:
> Ok thanks, I've pushed it to dev 1.7.1 now.
>
> There's a few really good pull requests from Egor
> <https://github.com/etsinko> that will be in dev 1.7.1 shortly.
thank you Phil.

>
> I've updated the deployment directory so 1.7.0-final now exists
> <https://jogamp.org/deployment/java3d/1.7.0-final/>.
thank you
>
> Harvey getting the search results is fair, I haven't done anywhere near the
> work he has done, but possibly in the future google will notice activity on my
> account...
Everybody is helping out as they can and thank you for maintaining j3d now.

>
> I'll update the jogamp wiki and maintainers page to make it more obvious that
> I should be the main contact.
thank you.

> We could put a java3d fork into the jogamp
> github repo to indicate which is the main java3d repo, I guess, that would be
> more Sven call than mine.
I 'personally' only consider JogAmp's SCM as canonical,
but you are correct - I will and shall add this to github jogamp as well
and you would then need to push to that backup storage space too.

I just forked following repos from 'philjord' -> 'JogAmp'
- vecmath
- java3d-core
- java3d-utils
- java3d-examples (Phil, please add this to JogAmp's SCM as well)

I also gave philjord admin/owner access to all
of the JogAmp team on github, as we never created fine grained roles
over there. This is more than OK, as it only is a backup storage.
On JogAmp we have fine grained access control.

Now it is all up to Phil to keep these repos in sync.

>
> Another option might be to publicize that scm on jogamp
> <https://jogamp.org/cgit/java3d/java3d-core.git/> should be seen as the latest
> version (which is of course a copy of my github repo)
Everything will be, by definition,
a copy of j3d's maintainer (Phil now) maintained j3d repo of JogAmp :)


>
> Once again, thanks for looking into this and actually providing the bug
> reproduction and fix in full.

Thanks to all collaborating, past, present and future.

Yes, I need to follow up with the Maven work 'soon'.

Planned after I fixed all the SWT and High-DPI issues for 2.4.0 release.

In the meantime it should be possible to build JogAmp's j3d
using either: RC aggregated builds or local source builds
- jogamp/gluegen
- jogamp/jogl
- jogamp/vecmath
- jogamp/java3d-core

.. etc etc

If this is not possible today, I recommend to add this build feature.

Below I elaborate a little bit on these 'pull resources' features,
so you may stop reading here.

Cheers, Sven

...

IMHO it is very essential to build things using a manually maintained
and pulled version of dependencies,
not relying on 'some infrastructure of others'.

Might be b/c I am 'an old dog', but my experience has told me
to always keep a safe option open.

Today, whether it is gradle, maven or whatever, they might pull-in the world
as dependencies to build 'Hello World' :)

This *might* be OK, but nobody can really tell and nobody is able to give
their right arm for this convenience.
I don't argue that such convenience is indeed very convenient and hence nice
to speed up building projects, but if you are building a mission critical
application this might not be what you want :)

One reason why it might come in handy to have one maven'ish build-view
and one traditional build-view.

A project's security level has a inverse correlation to the number of
dependencies, this includes the tools to build the beasts.

~Sven

On 1/25/20 6:38 AM, philjord [via jogamp] wrote:
> Ok thanks, I've pushed it to dev 1.7.1 now.
>
> There's a few really good pull requests from Egor
> <https://github.com/etsinko> that will be in dev 1.7.1 shortly.

Please promote dev1.7.1 branches for the other java3d repos as well,
so a user can simply align these when building themselves.

Please sync JogAmp's java3d git repos to JogAmp's github java3d repos,
I just added 'java3d-examples' to JogAmp's java3d git repos for you.

   'jogamp.org/srv/scm/java3d/java3d-examples.git'

Thank you.

Cheers, Sven

On 1/25/20 11:06 AM, Sven Gothel [via jogamp] wrote:
> In the meantime it should be possible to build JogAmp's j3d
> using either: RC aggregated builds or local source builds
> - jogamp/gluegen
> - jogamp/jogl
> - jogamp/vecmath
> - jogamp/java3d-core
>

I personally use the following layout currently

- jogamp/gluegen
- jogamp/joal
- jogamp/jogl
- jogamp/java3d/vecmath
- jogamp/java3d/java3d-core
- jogamp/java3d/java3d-utils

(as reflected by other JogAmp SCM)

But if you pick up a 'manual build view',
it is up to you to chose and force upon us.

~Sven

I'll try and make it more obvious on my github repos that Java3D 1.6 is unlikely to see any more changes and add a pointer to the jogamp repos. Phil, in future if you do make any bugfixes in 1.7 that you think may also apply to 1.6, let me know and I may do further bugfix only releases, or if something changes on the jogl side that requires a fixup.

FYI, there was one final commit made to vecmath on my master branch after 1.6.2 that you may be interested in, removes the only AWT dependency in that package.

Best of luck with Java3D Phil!

Harvey

Thanks Harvey, I'll definitely let you know of anything that's common between them that needs fixing.
I took out that Color4f to Color method quite a while back, it was a poor bit of dependency oversight.

Phil.

Sven,
I agree heartily with your thoughts on being able to build by finding dependencies and understanding what version is where and what's being used.

I've always built Java3D this way until recently.

In the Android world it seems almost all development is aggressively based around gradle.build managing all dependencies for a developer, such that no one would use a library if it wasn't published on something like maven central.

In truth it seems the modern "framework development"world would like to hide all implementation details from the "developer", no one needs to know anything other than the magical string incantations that make magic happen, Android layouts work only via trial and error, you can never simply understand what's required.

So I'm pushing down the path of full mavenisation for Javas3D, not because I like it or want to, but because the target user audience I'd like to appeal to (Android developers and eventually iOS) demand it.

 

The libraries should be on JogAmp Maven development repository too, too much centralization might lead to disasters, Maven Central shouldn't be your single point of failure. It's convenient for numerous developers but Maven and Gradle should go on working even without Maven Central.

On 1/29/20 6:42 AM, philjord [via jogamp] wrote:
Amen indeed.

>
> So I'm pushing down the path of full mavenisation for Javas3D, not because I
> like it or want to, but because the target user audience I'd like to appeal to
> (Android developers and eventually iOS) demand it.

Yes, sure - we need to serve them as well - regardless.

~Sven