JogAmp 'Jbeil' RC Build 2.4.0-rc-20200202

JogAmp 'Jbeil' RC Build 2.4.0-rc-20200202

<https://jogamp.org/deployment/v2.4.0-rc-20200202/>
as linked to <https://jogamp.org/deployment/jogamp-next/>

Changes to previous RC:

1) SWT Interoperability
<https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#SWT_Interoperability>

Bug 1421 Resolved and verified
Bug 1422 Should be resolved now.
Bug 1423 Needs a unit test ..
Bug 1424 Open ..

2) High-DPI
<https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#High_DPI>

Bug 1374: Reopened
<https://jogamp.org/bugzilla/show_bug.cgi?id=1374#c3>

In particular NEWT child windows
on platform w/o native DPI scaling (Windows, X11..)
within other toolkits like AWT, Swing and SWT.

This is now understood and can be resolved for 2.4.0
as time allows.

++++

The builds ..
- https://jogamp.org/chuck/view/fwd/job/gluegen/936/
- https://jogamp.org/chuck/view/fwd/job/joal/659/
- https://jogamp.org/chuck/view/fwd/job/jogl/1503/
- https://jogamp.org/chuck/view/fwd/job/jocl/1146/

Open Bugs 2.4.0
- Bugzilla
<https://jogamp.org/bugzilla/buglist.cgi?list_id=2960&query_format=advanced&resolution=---&version=2.4.0>

- Wiki
<https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_2.4.0>


Other Bugs pushed to 2.4.1
- Bugzilla
<https://jogamp.org/bugzilla/buglist.cgi?list_id=2960&query_format=advanced&resolution=---&version=2.4.1>


- Wiki
<https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_2.4.1>



~Sven

Good job, I appreciate your pugnacity.

Hi,

I updated the special version of Sweet Home 3D 6.2 JAR Executable with JOGL 2.4.0-rc-20200202 (available here - 25.7 MB), and successfully tested it under the following Java / OS combinations:
- OpenJDK 13.0.1 / Windows 10 64 bit
- Oracle Java 10.0.2 / Windows 10 64 bit
- Oracle Java 8u121 / Windows 10 64 bit
- Oracle Java 8u131 / Windows XP 32 bit
- OpenJDK 13.0.1 / macOS 10.15
- Oracle Java 8u202 / macOS 10.15
- OpenJDK 13.0.1 / macOS 10.14
- Oracle Java 8u202 / macOS 10.14
- Oracle Java 8u144 / macOS 10.10
- OpenJDK 13.0.1 / Ubuntu 18 64 bit
- OpenJDK 11.0.2 / Ubuntu 18 64 bit
- Oracle Java 8u202 / Ubuntu 18 64 bit
- OpenJDK 1.8.0_232 / Ubuntu 16 32 bit

Feel free to test it under other combinations (just check that the About dialog displays Java 3D 1.6.1 which is bound to JOGL 2.4.0 RC 20200202).

I also tested it with Java 6u45 but it couldn't run, because JOGL seems to have been compiled with Java 1.8 target. Is there a good reason to drop Java 1.6 target? Do you really need the features of Java 7/8?

Thanks

On 2/3/20 6:31 PM, Manu [via jogamp] wrote:
Excellent, thank you Emmanuel for testing on these platforms!

> Feel free to test it under other combinations (just check that the
> /About/ dialog displays Java 3D 1.6.1 which is bound to JOGL 2.4.0 RC 20200202).
>
> I also tested it with Java 6u45 but it couldn't run, because JOGL seems to
> have been compiled with Java 1.8 target. Is there a good reason to drop Java
> 1.6 target? Do you really need the features of Java 7/8?

It is especially hard for me to cut off previous systems.
Yes indeed, a decision that I don't make lightly.

As of today, we probably don't yet use (much) of Java > 6 features (if at all).

However, we are forced to produce Java 8 bytecode and classfiles
<https://en.wikipedia.org/wiki/Java_class_file#General_layout>,
in particular compatibility with
'Java SE 8 = 52' and Java8-RT minimum version only.

This is due to Bug 1363 "Java 11+ Compatibility (Remove Warnings, Build and Run)"
of ours <https://jogamp.org/bugzilla//show_bug.cgi?id=1363>.

Java-11's javac is no more capable to produce bytecode/classfiles < 'Java SE
8', this is the lowest version.

Also see
<https://jogamp.org/cgit/gluegen.git/tree/make/jogamp-env.xml?id=6e98be1a1bc819b47e2cc52eb35d23a7489fdf1b>,
where I elaborate on this compatibility and made the decision in June 2019.
This was debated here and otherwise..

Before bringing up Java>=11 compatibility and hence dropping Java<8
in June 2019, I was especially resistant to this move as I avoid dropping
platforms
by design. While researching for Bug 1363, i realized that
- OpenJDK 1.8 was around for 3 years already and well supported

- OpenJDK 9 (1.9) also supported more mobile platforms,
  like iOS and Android.

- Android's 'JIT' does support Java 8 bytecode/etc to a certain degree
  for more than 3 years.

It is probably hard to find a currently supported VM,
being restricted to Java < 8.

Also please note that while I performed Bug 1363 and related
task like Android update (Bug 1417
<https://jogamp.org/bugzilla//show_bug.cgi?id=1417>)
I focused on backward compatibility whenever possible.

I avoided dropping pre Java-9 or pre Java-11 API hooks etc
as much as possible.

HOWEVER, if anybody dares to take up the task to at least maintain
source code compatible with Java 6 - we can talk about it.
This would require to set up one build system
supporting Java 6 using a maintained toolchain.

Thank you

~Sven

Thanks for all the reasons about dropping Java 6/7 support, and sorry if you had to repeat them.

As I include Java 3D 1.5.2 and Java 3D 1.6 with Sweet Home 3D for various reasons (see for example this thread), I will continue to use Java 3D 1.5.2 under Java 6/7 (still a few users are obliged to use Apple Java 6 under old Mac OS X computers) in the version of the program that will be updated with JOGL 2.4.

Keep in mind that dropping Java 7 support in JOGL will break Java 3D programs requiring Java 7 under macOS, because Java 3D 1.5.2 can't run with Java > 6 under that system. Hopefully those programs will upgrade to Java 8, if there are any.

Java3D <= 1.5 is none of our concerns and the problem you mentioned has several not very satisfying workaround but it doesn't require Java 7 for sure, numerous updates of Java 8 still support this configuration.

When people choose to buy Apple hardware, they have to face the consequences, it's not the kind of software designed to last, you shouldn't rely on the Java Runtime Environment installed on the system anyway, those Java3D programs should embed a JRE and sorry to repeat that but Java3D <= 1.5 is none of our concerns. Dropping Java 7 support in JOGL will force those programs to embed a more recent JRE, it's not very hard. Apple Java 6 is deprecated by Apple itself, it shouldn't be used. I'm not sure that JOGL still works on Mac OS X 10.6, it's terribly old.

In my humble opinion, as any program can embed its own JRE, as less and less people keep a JRE installed on the system, it doesn't make a lot of sense to support deprecated versions of Java and supporting at least the two latest LTS versions of Java is a good compromise. Moreover, it will become more and more complicated to support more than one LTS version because of some changes in Java. JogAmp shouldn't be constrained by debatable deployment strategies including the use of broken and unmaintained or mostly abandoned tools.

Dropping the support of some hardware doesn't make me laugh but it's not really what is going to happen, OpenJDK 8 works on Apple Mac Book Pro manufactured in 2007 as far as I remember, I don't see where those users forced to use Apple Java are especially when the concerned program embeds its own JRE.