Change: JogAmp Module's Java Language Version Constraints

Dear All,

after a long beating I had to take for keeping up with the
J2ME compatibility and hence the Java source level 1.3 constraints,
I give in bumping up the upper bar to 1.5 :)

Now we are 3 core developers (Michael, Rami and Sven) plus many others
who expressed their desire to 'enhance' this situation,
ie using new language features and styles etc.

Since JamVM, Dalvik and other mobile JVMs support the 1.5 language level
and we haven't seen anymore J2ME/CVM/CDC JVM running on multimedia devices
there is little reasoning continue it's support.

We have decided the following for all JogAmp modules, each should:

- support Java source level 1.5

- support JVM 1.5 (when using JVMs, besides others, ie dalvik)

- don't exceed dalvik's library features (level ??)
  http://developer.android.com/reference/packages.html

- implementation may use 1.5 features

- new API stuff may use 1.5 features

- old API stuff may change to 1.5 features after release 2.0

Cheers, Sven

--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

  no complains - great :)

JogAmp moved yesterday to Java 5 language level. Latest Jenkins builds
already went through cleanly.

http://jogamp.org/deployment/autobuilds/master/

we are now all happy to get rid of some internal backwards compatibility
codepaths.

best regards,
michael

On 02/08/2011 03:04 AM, Sven Gothel [via jogamp] wrote:
--
http://michael-bien.com/

Do you plan to benefit of the integer cache (see Integer.valueOf(int i))? The switch to Java 1.5 will be done after the release of the 2.0, why not doing it earlier?

On Friday, March 04, 2011 11:57:53 gouessej [via jogamp] wrote:
>
> Do you plan to benefit of the integer cache (see Integer.valueOf(int i))?

Please enlight me.
You mean the autoboxing is solved ?
Alternative to out IntIntHashMap ?

> The
> switch to Java 1.5 will be done after the release of the 2.0, why not doing
> it earlier?

We are on 1.5 right now. Don't get it, sorry.

~Sven

On 03/04/2011 04:15 PM, Sven Gothel [via jogamp] wrote:
>
> On Friday, March 04, 2011 11:57:53 gouessej [via jogamp] wrote:
>> Do you plan to benefit of the integer cache (see Integer.valueOf(int i))?
> Please enlight me.
> You mean the autoboxing is solved ?
> Alternative to out IntIntHashMap ?
>
java 5 has an internal mapping of at least +-128 Integer<->int entries
behind Integer.valueOf(int i).

answer: good idea we considered it already but we have in many cases
other values for 'i', e.g 64bit memory addresses. But yes this area is
certainly improvable.

It is also debatable if the state tracking is needed/should be
configurable in all situations, e.g i had an old custom jogl build
without state tracking at all for common things like VBOs as jogl was
still maintained by sun.

but:
even if it looks frightening on VisualVM there shouldn’t be any
noticeable performance impact. The objects are tiny and die young which
means they should not end up in the old genaration of the heap.

best regards,

michael

> ~Sven
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/Change-JogAmp-Module-s-Java-Language-Version-Constraints-tp2448646p2633351.html
> To start a new topic under jogamp, email [hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/

It has an impact in TextRenderer, I would only like to remove my thing that does the same thing than Integer.valueOf().

It seems now that the target javac version of JOGL is 1.6 at this time.
I wonder if there are some reasons why it's not 1.5 anymore, and in case there's no reason, if it could target 1.5 to be able to run libraries under older Mac OS X systems where Java 1.6 was never made available.

On 12/16/2012 07:45 PM, Manu [via jogamp] wrote:
> It seems now that the target javac version of JOGL is 1.6 at this time.
> I wonder if there are some reasons why it's not 1.5 anymore, and in case
> there's no reason, if it could target 1.5 to be able to run libraries under
> older Mac OS X systems where Java 1.6 was never made available.

You probably refer to OSX version < 10.5.8,
i.e. 4 'sales' version earlier [10.4 .. 10.7].

Reason we have switched to 1.6 (Level 6.0) was mainly the availability of working
environments, which we made in January 2012.

We concluded it's best to compile the modules w/ a compliant compiler
of the target version (produce 1.6 class files w/ 1.6 javac and rt.jar)
instead of 'sneaking' in a 1.6 rt.jar of a 1.7 javac .. etc.

Since:
  - 1.5 (Level 5.0) was reaching EOL
  - OSX versions < 10.5.8 were reaching EOL
  - OpenJDK 6 and 7 availability on mobile/embedded devices
  - Android accepts Level 6.0 class files
we decided to pick the 1.6 class file version
w/ available tool-chains.

Further more, on OSX we only have 10.5, 10.6 and 10.7 test environments.
Actually not even a real 10.6 test box anymore, where 10.7 is tested by
'other users'.

Sure, decorations like '@Override' for interfaces is another 'beauty' argument,
but doesn't really cut the cake - sure not.

Maybe there are a few bytecode or class-file related differences between 5.0 and 6.0,
which allow further runtime optimizations, but I doubt it.
  <http://java.sun.com/performance/reference/whitepapers/6_performance.html>

+++

http://jogamp.org/git/?p=gluegen.git;a=commit;h=64639b805a32338385421f168e12c1ef7f749d00

https://jogamp.org/bugzilla/show_bug.cgi?id=516

+++

~Sven

> Emmanuel Puybaret

Thanks Sven for your detailed answer.
You're right, I was referring to Mac OS X versions 10.4 and 10.5, and particularly to PowerPC computers that can't be upgraded to 10.6. There must be quite a lot of computers of this kind that are still running.

If you support only Java 1.6 and more recent versions, then while calling (and I guess building) "Universal" libraries for Mac OS X? Or by "Universal", does it mean it supports Intel 32 bits and 64 bits architecture? It those libraries support also PowerPC, I guess you could remove that part because a full version of Java 6 never existed for this processor under Mac OS X.

On 12/17/2012 10:00 AM, Manu [via jogamp] wrote:
> Thanks Sven for your detailed answer.
> You're right, I was referring to Mac OS X versions 10.4 and 10.5, and
> particularly to PowerPC computers that can't be upgraded to 10.6.
Well, Java6 is avail for 10.5.8 64bit only .. I guess.

> There must
> be quite a lot of computers of this kind that are still running.
Yes, so it's a PowerPC 10.5 issue here .. actually.

>
> If you support only Java 1.6 and more recent versions, then while calling (and
> I guess building) "Universal" libraries for Mac OS X? Or by "Universal", does
> it mean it supports Intel 32 bits and 64 bits architecture? It those libraries
> support also PowerPC, I guess you could remove that part because a full
> version of Java 6 never existed for this processor under Mac OS X.

Right, thank you for this detail.

Now the question is - shall we support OSX PowerPC and jump little hoops for it ?
Obviously my opinion is 'no' so far.

However, if there is a huge audience for such platform - maybe we can produce
something for them, if they are willing to cooperate.
What comes to mind is some class-file converter .. and available build machine.
Again: I would like to stay out of such 'ugly' business :)

~Sven

> Emmanuel Puybaret

Since the release of version 4.0 of Sweet Home 3D, I can compute some statistics on the system / arch / Java version of the users who run the software, thanks to the agent set on the HTTP header when a request about updates of the software is done. Even if this is some partial results since no request will be sent if the user doesn't want it or he's not connected to the Internet, I can still give you the following results about the Java 5 and PowerPC architecture usage for one week:
467 users with a different IP address were running Sweet Home 3D under Java 5
101 users with a different IP address were running Sweet Home 3D on a PowerPC

This is not huge numbers but it's still too soon to say that Macs with a PowerPC or running an old Mac OS X version are dead.
Are these numbers big enough to motivate you to support Java 5 and/or PowerPC in JOGL?

How do those numbers relate to the total number of users that upgraded?  Are the powerPC folks
a large or small percentage at this point?

Harvey

hharrison wrote

How do those numbers relate to the total number of users that upgraded?  Are the powerPC folks
a large or small percentage at this point?

The previous numbers are out of 87860 users who requested if an upgrade is available (not who upgraded, something I can't know). So expressed as percentage, it gives 0.5% of users who use Java 5, and 0.11% who run Sweet Home 3D on a PowerPC (i.e. 1.4% of users under Mac OS X).
It's a small percentage, but why should they be abandoned?

I'm not sure we have a machine under Mac OS X with a Power PC microprocessor and maintaining this architecture would require a supplementary effort. If you think it is worth, write a bug report.

I've got such a machine, but I'm not sure I could spend time on testing every JOGL release.
And what about keeping Java 5 support? Would it be a lot of work?

We don't have compile dependencies on Java 1.6. Maybe we could use Java 1.5 only on platforms that really need it, for example if you resurrect the PowerPC support.

Then, if I build myself JOGL and GlueGen after setting compiler target to Java 1.5,  I could get the binaries I want, right?