Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38571 > unrolled thread

Java Version

Back to article view | Back to comp.lang.java.programmer

Contents

  Java Version Eric Douglas <e.d.programmer@gmail.com> - 2018-08-28 13:17 -0700
    Re: Java Version Arne Vajhøj <arne@vajhoej.dk> - 2018-08-28 18:11 -0400
      Re: Java Version bursejan@gmail.com - 2018-08-28 16:00 -0700
        Re: Java Version bursejan@gmail.com - 2018-08-28 16:01 -0700
        Re: Java Version Arne Vajhøj <arne@vajhoej.dk> - 2018-08-28 19:40 -0400
        Re: Java Version Arne Vajhøj <arne@vajhoej.dk> - 2018-08-28 19:42 -0400
          Re: Java Version bursejan@gmail.com - 2018-08-28 16:56 -0700
            Re: Java Version bursejan@gmail.com - 2018-08-28 16:58 -0700
              Re: Java Version bursejan@gmail.com - 2018-08-28 17:06 -0700
                Re: Java Version bursejan@gmail.com - 2018-08-28 17:09 -0700
                  Re: Java Version bursejan@gmail.com - 2018-08-28 17:28 -0700
                  Re: Java Version bursejan@gmail.com - 2018-08-28 17:47 -0700
                    Re: Java Version bursejan@gmail.com - 2018-08-28 17:53 -0700

#38571 — Java Version

What Java version do you run?  Do you code for a business?  What size?

I saw this article yesterday.
https://jaxenter.com/java-influencers-series-part-3-148682.html
They ask if everyone is planning to upgrade to 11 just because it's about to be the only version with long term support.

My current business is a small business.  We started on 6 and moved to 7 and 8 because it was a pretty smooth transition.  9+ sounds like a lot more work, so we plan to move to 11 for the LTS but could be awhile before we fit that into our schedule.

I saw a job ad for a Java developer for a large business and they mentioned Java 6... They also mentioned Oracle software so no doubt they have a paid long term support contract for that..

[toc] | [next] | [standalone]

#38572

On 8/28/2018 4:17 PM, Eric Douglas wrote:
> What Java version do you run?  Do you code for a business?  What size?
> 
> I saw this article yesterday.
> https://jaxenter.com/java-influencers-series-part-3-148682.html
> They ask if everyone is planning to upgrade to 11 just because it's about to be the only version with long term support.
> 
> My current business is a small business.  We started on 6 and moved to 7 and 8 because it was a pretty smooth transition.  9+ sounds like a lot more work, so we plan to move to 11 for the LTS but could be awhile before we fit that into our schedule.
> 
> I saw a job ad for a Java developer for a large business and they mentioned Java 6... They also mentioned Oracle software so no doubt they have a paid long term support contract for that..

The SUN/Oracle policy has always been that if you pay you can get
support for a very long time, but that patches for free stopped after
some years.

Java 6

Release December 2006
Free: end patches June 2013 (+7 years)
Paid: end extended support December 2018 (+12 years)

Java 7

Release July 2011
Free: end patches May 2015 (+4 years)
Paid: end extended support July 2022 (+11 years)

Java 8

Release March 2014
Free: end patches January 2019 for commercial (+5 years)
Paid: end extended support March 2025 (+11 years)

Java 11

Release September 2018
Free: Oracle refer to OpenJDK
         openjdk.java.net will supposedly not offer long term support
         adoptopenjdk.net will per https://adoptopenjdk.net/support.html 
provide patches until September 2022 (+4 years)
Paid: end extended support September 2026 (+8 years)

I think that the viable route forward for many Java users will be to:
* continue with free Oracle Java 8 until January
* upgrade to OpenJDK 11 from adoptopenjdk.net

The alternative must be to pay.

But if that is the choice then I would make sure to get quotes
from other vendors like IBM and Azul before buying from Oracle to
make sure you get the best price.

Arne

[toc] | [prev] | [next] | [standalone]

#38573

Or you compile your Java byte code to JavaScript via:

CheerpJ 1.1 released Faster Java to JavaScript 
with better interop, exception handling, resource preloading
https://medium.com/leaningtech/cheerpj-1-1-released-3aca70c5b2da

A few days I had the dilemma, whether I should
discontinue my applets or not, and then I gave
it a try via their Chrome plugin:

Preview: Prolog Applets in Chrome Browser without Java.
https://plus.google.com/+JanBurse/posts/1a5GtGdf8Uf

I was very surprised I could run a end-to-end test,
everything worked fine, even the Swing GUI of the
applet, and not a single good old JVM was

installed in the browser. But I can tell yet of
the overall performance. I am still prepating
an applet console so that I can more

easily run some further benchmarks...

P.S.: I dont like the method proliferation in
JDK 7 etc.., even in java.lang.*, there is no
discipline of javax.* anymore, which

has the only effect, if you are not careful,
you suddently lock your self into a certain
higher JDK version. I still try to develop

against JDK 6, so that I also can use my
code for example Android. Oracle is really
creepy how they extend java.lang.*

with all kind of nonsense...

Am Mittwoch, 29. August 2018 00:12:11 UTC+2 schrieb Arne Vajhøj:
> On 8/28/2018 4:17 PM, Eric Douglas wrote:
> > What Java version do you run?  Do you code for a business?  What size?
> > 
> > I saw this article yesterday.
> > https://jaxenter.com/java-influencers-series-part-3-148682.html
> > They ask if everyone is planning to upgrade to 11 just because it's about to be the only version with long term support.
> > 
> > My current business is a small business.  We started on 6 and moved to 7 and 8 because it was a pretty smooth transition.  9+ sounds like a lot more work, so we plan to move to 11 for the LTS but could be awhile before we fit that into our schedule.
> > 
> > I saw a job ad for a Java developer for a large business and they mentioned Java 6... They also mentioned Oracle software so no doubt they have a paid long term support contract for that..
> 
> The SUN/Oracle policy has always been that if you pay you can get
> support for a very long time, but that patches for free stopped after
> some years.
> 
> Java 6
> 
> Release December 2006
> Free: end patches June 2013 (+7 years)
> Paid: end extended support December 2018 (+12 years)
> 
> Java 7
> 
> Release July 2011
> Free: end patches May 2015 (+4 years)
> Paid: end extended support July 2022 (+11 years)
> 
> Java 8
> 
> Release March 2014
> Free: end patches January 2019 for commercial (+5 years)
> Paid: end extended support March 2025 (+11 years)
> 
> Java 11
> 
> Release September 2018
> Free: Oracle refer to OpenJDK
>          openjdk.java.net will supposedly not offer long term support
>          adoptopenjdk.net will per https://adoptopenjdk.net/support.html 
> provide patches until September 2022 (+4 years)
> Paid: end extended support September 2026 (+8 years)
> 
> I think that the viable route forward for many Java users will be to:
> * continue with free Oracle Java 8 until January
> * upgrade to OpenJDK 11 from adoptopenjdk.net
> 
> The alternative must be to pay.
> 
> But if that is the choice then I would make sure to get quotes
> from other vendors like IBM and Azul before buying from Oracle to
> make sure you get the best price.
> 
> Arne

[toc] | [prev] | [next] | [standalone]

#38574

Corr.:
installed in the browser. But I cannot tell yet of
the overall performance. I am still prepating 

Also I have not yet studied their licensing model...

Am Mittwoch, 29. August 2018 01:00:37 UTC+2 schrieb burs...@gmail.com:
> Or you compile your Java byte code to JavaScript via:
> 
> CheerpJ 1.1 released Faster Java to JavaScript 
> with better interop, exception handling, resource preloading
> https://medium.com/leaningtech/cheerpj-1-1-released-3aca70c5b2da
> 
> A few days I had the dilemma, whether I should
> discontinue my applets or not, and then I gave
> it a try via their Chrome plugin:
> 
> Preview: Prolog Applets in Chrome Browser without Java.
> https://plus.google.com/+JanBurse/posts/1a5GtGdf8Uf
> 
> I was very surprised I could run a end-to-end test,
> everything worked fine, even the Swing GUI of the
> applet, and not a single good old JVM was
> 
> installed in the browser. But I can tell yet of
> the overall performance. I am still prepating
> an applet console so that I can more
> 
> easily run some further benchmarks...
> 
> P.S.: I dont like the method proliferation in
> JDK 7 etc.., even in java.lang.*, there is no
> discipline of javax.* anymore, which
> 
> has the only effect, if you are not careful,
> you suddently lock your self into a certain
> higher JDK version. I still try to develop
> 
> against JDK 6, so that I also can use my
> code for example Android. Oracle is really
> creepy how they extend java.lang.*
> 
> with all kind of nonsense...
> 
> Am Mittwoch, 29. August 2018 00:12:11 UTC+2 schrieb Arne Vajhøj:
> > On 8/28/2018 4:17 PM, Eric Douglas wrote:
> > > What Java version do you run?  Do you code for a business?  What size?
> > > 
> > > I saw this article yesterday.
> > > https://jaxenter.com/java-influencers-series-part-3-148682.html
> > > They ask if everyone is planning to upgrade to 11 just because it's about to be the only version with long term support.
> > > 
> > > My current business is a small business.  We started on 6 and moved to 7 and 8 because it was a pretty smooth transition.  9+ sounds like a lot more work, so we plan to move to 11 for the LTS but could be awhile before we fit that into our schedule.
> > > 
> > > I saw a job ad for a Java developer for a large business and they mentioned Java 6... They also mentioned Oracle software so no doubt they have a paid long term support contract for that..
> > 
> > The SUN/Oracle policy has always been that if you pay you can get
> > support for a very long time, but that patches for free stopped after
> > some years.
> > 
> > Java 6
> > 
> > Release December 2006
> > Free: end patches June 2013 (+7 years)
> > Paid: end extended support December 2018 (+12 years)
> > 
> > Java 7
> > 
> > Release July 2011
> > Free: end patches May 2015 (+4 years)
> > Paid: end extended support July 2022 (+11 years)
> > 
> > Java 8
> > 
> > Release March 2014
> > Free: end patches January 2019 for commercial (+5 years)
> > Paid: end extended support March 2025 (+11 years)
> > 
> > Java 11
> > 
> > Release September 2018
> > Free: Oracle refer to OpenJDK
> >          openjdk.java.net will supposedly not offer long term support
> >          adoptopenjdk.net will per https://adoptopenjdk.net/support.html 
> > provide patches until September 2022 (+4 years)
> > Paid: end extended support September 2026 (+8 years)
> > 
> > I think that the viable route forward for many Java users will be to:
> > * continue with free Oracle Java 8 until January
> > * upgrade to OpenJDK 11 from adoptopenjdk.net
> > 
> > The alternative must be to pay.
> > 
> > But if that is the choice then I would make sure to get quotes
> > from other vendors like IBM and Azul before buying from Oracle to
> > make sure you get the best price.
> > 
> > Arne

[toc] | [prev] | [next] | [standalone]

#38575

On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> Or you compile your Java byte code to JavaScript via:
> 
> CheerpJ 1.1 released Faster Java to JavaScript
> with better interop, exception handling, resource preloading
> https://medium.com/leaningtech/cheerpj-1-1-released-3aca70c5b2da
> 
> A few days I had the dilemma, whether I should
> discontinue my applets or not, and then I gave
> it a try via their Chrome plugin:
> 
> Preview: Prolog Applets in Chrome Browser without Java.
> https://plus.google.com/+JanBurse/posts/1a5GtGdf8Uf
> 
> I was very surprised I could run a end-to-end test,
> everything worked fine, even the Swing GUI of the
> applet, and not a single good old JVM was
> 
> installed in the browser. But I can tell yet of
> the overall performance. I am still prepating
> an applet console so that I can more
> 
> easily run some further benchmarks...

That seems like reasonable choice for applets.

But probably not for Java EE, Hadoop etc..

Arne

[toc] | [prev] | [next] | [standalone]

#38576

On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
>                 I still try to develop
> against JDK 6, so that I also can use my
> code for example Android.

I don't understand that.

Android does not implement full runtime of any Java version.

And the language support is up to Java 8 in latest
versions I believe.

Arne

[toc] | [prev] | [next] | [standalone]

#38577

The language level is independent of the Android
Libraries. Language features along the code and
not along the interface are not seen in the

Android Libraries, since they are only seen as
interfaces. If you open an Android library in
my IDE, you only see:

public final class Class<T> 
   implements Serializable, GenericDeclaration, 
              Type, AnnotatedElement {

        Class() {
        throw new RuntimeException("Stub!");
    }

    public String toString() {
        throw new RuntimeException("Stub!");
    }

    public String toGenericString() {
        throw new RuntimeException("Stub!");
    }

BTW: Same case with Java. So all that counts would
be only language features that affect the interfaces.
But generic types were already introduced

in JDK 6. So with JDK 6 you are on the safe side.
And some packages that are not in the intersetion
between Java and Android, 

you figure these out quickly.

The Android libraries byte code on the other hand
uses version 52.0, thats right. But then if you
stay in the JDK 6 for the non GUI

part, this doesn't mean I would recommend the
same for the GUI and Android specific part.
Maybe there you should profit from

the latest development. 

Am Mittwoch, 29. August 2018 01:42:28 UTC+2 schrieb Arne Vajhøj:
> On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> >                 I still try to develop
> > against JDK 6, so that I also can use my
> > code for example Android.
> 
> I don't understand that.
> 
> Android does not implement full runtime of any Java version.
> 
> And the language support is up to Java 8 in latest
> versions I believe.
> 
> Arne

[toc] | [prev] | [next] | [standalone]

#38578

Corr.:
BTW: Same case with Java.

By that I mean, for Java libraries you also 
need to only look for interface compatibility
I guess. If the code involves side effects,

well then you possibly need to know more
about the libraries....

Am Mittwoch, 29. August 2018 01:56:41 UTC+2 schrieb burs...@gmail.com:
> The language level is independent of the Android
> Libraries. Language features along the code and
> not along the interface are not seen in the
> 
> Android Libraries, since they are only seen as
> interfaces. If you open an Android library in
> my IDE, you only see:
> 
> public final class Class<T> 
>    implements Serializable, GenericDeclaration, 
>               Type, AnnotatedElement {
> 
>         Class() {
>         throw new RuntimeException("Stub!");
>     }
> 
>     public String toString() {
>         throw new RuntimeException("Stub!");
>     }
> 
>     public String toGenericString() {
>         throw new RuntimeException("Stub!");
>     }
> 
> BTW: Same case with Java. So all that counts would
> be only language features that affect the interfaces.
> But generic types were already introduced
> 
> in JDK 6. So with JDK 6 you are on the safe side.
> And some packages that are not in the intersetion
> between Java and Android, 
> 
> you figure these out quickly.
> 
> The Android libraries byte code on the other hand
> uses version 52.0, thats right. But then if you
> stay in the JDK 6 for the non GUI
> 
> part, this doesn't mean I would recommend the
> same for the GUI and Android specific part.
> Maybe there you should profit from
> 
> the latest development. 
> 
> Am Mittwoch, 29. August 2018 01:42:28 UTC+2 schrieb Arne Vajhøj:
> > On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> > >                 I still try to develop
> > > against JDK 6, so that I also can use my
> > > code for example Android.
> > 
> > I don't understand that.
> > 
> > Android does not implement full runtime of any Java version.
> > 
> > And the language support is up to Java 8 in latest
> > versions I believe.
> > 
> > Arne

[toc] | [prev] | [next] | [standalone]

#38579

For the CheerpJ test I even used:

   bytecode version: 49.0 (Java 5.0)
 
There are applet issues:

   "I can not launch my java application 
   as a web applet in HTML (I am using HTML 
   4.01, I know it doesn't work in html5). 
   The error message it returns is:
   java : Unsupported major.minor version 52.0
   https://stackoverflow.com/questions/23249331/java-unsupported-major-minor-version-52-0

I think there is an interim time, where 
both 49.0 and 52.0 are support by the 
usual Java runtimes. Not sure.

But with respect to some Tomcat Servers, Applets 
etc.. I habitually compile with target 1.5. I did 
not yet check CheerpJ with a different target.

Am Mittwoch, 29. August 2018 01:58:45 UTC+2 schrieb burs...@gmail.com:
> Corr.:
> BTW: Same case with Java.
> 
> By that I mean, for Java libraries you also 
> need to only look for interface compatibility
> I guess. If the code involves side effects,
> 
> well then you possibly need to know more
> about the libraries....
> 
> Am Mittwoch, 29. August 2018 01:56:41 UTC+2 schrieb burs...@gmail.com:
> > The language level is independent of the Android
> > Libraries. Language features along the code and
> > not along the interface are not seen in the
> > 
> > Android Libraries, since they are only seen as
> > interfaces. If you open an Android library in
> > my IDE, you only see:
> > 
> > public final class Class<T> 
> >    implements Serializable, GenericDeclaration, 
> >               Type, AnnotatedElement {
> > 
> >         Class() {
> >         throw new RuntimeException("Stub!");
> >     }
> > 
> >     public String toString() {
> >         throw new RuntimeException("Stub!");
> >     }
> > 
> >     public String toGenericString() {
> >         throw new RuntimeException("Stub!");
> >     }
> > 
> > BTW: Same case with Java. So all that counts would
> > be only language features that affect the interfaces.
> > But generic types were already introduced
> > 
> > in JDK 6. So with JDK 6 you are on the safe side.
> > And some packages that are not in the intersetion
> > between Java and Android, 
> > 
> > you figure these out quickly.
> > 
> > The Android libraries byte code on the other hand
> > uses version 52.0, thats right. But then if you
> > stay in the JDK 6 for the non GUI
> > 
> > part, this doesn't mean I would recommend the
> > same for the GUI and Android specific part.
> > Maybe there you should profit from
> > 
> > the latest development. 
> > 
> > Am Mittwoch, 29. August 2018 01:42:28 UTC+2 schrieb Arne Vajhøj:
> > > On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> > > >                 I still try to develop
> > > > against JDK 6, so that I also can use my
> > > > code for example Android.
> > > 
> > > I don't understand that.
> > > 
> > > Android does not implement full runtime of any Java version.
> > > 
> > > And the language support is up to Java 8 in latest
> > > versions I believe.
> > > 
> > > Arne

[toc] | [prev] | [next] | [standalone]

#38580

I guess with target 1.5 you get the generic
types not included in the byte code, so code 
that would do reflection on these wouldn't work.

Not sure. generic types are useful for compilation, 
but then at runtime I don't need them, so I use 
target 1.5 habitually...

Am Mittwoch, 29. August 2018 02:07:06 UTC+2 schrieb burs...@gmail.com:
> For the CheerpJ test I even used:
> 
>    bytecode version: 49.0 (Java 5.0)
>  
> There are applet issues:
> 
>    "I can not launch my java application 
>    as a web applet in HTML (I am using HTML 
>    4.01, I know it doesn't work in html5). 
>    The error message it returns is:
>    java : Unsupported major.minor version 52.0
>    https://stackoverflow.com/questions/23249331/java-unsupported-major-minor-version-52-0
> 
> I think there is an interim time, where 
> both 49.0 and 52.0 are support by the 
> usual Java runtimes. Not sure.
> 
> But with respect to some Tomcat Servers, Applets 
> etc.. I habitually compile with target 1.5. I did 
> not yet check CheerpJ with a different target.
> 
> Am Mittwoch, 29. August 2018 01:58:45 UTC+2 schrieb burs...@gmail.com:
> > Corr.:
> > BTW: Same case with Java.
> > 
> > By that I mean, for Java libraries you also 
> > need to only look for interface compatibility
> > I guess. If the code involves side effects,
> > 
> > well then you possibly need to know more
> > about the libraries....
> > 
> > Am Mittwoch, 29. August 2018 01:56:41 UTC+2 schrieb burs...@gmail.com:
> > > The language level is independent of the Android
> > > Libraries. Language features along the code and
> > > not along the interface are not seen in the
> > > 
> > > Android Libraries, since they are only seen as
> > > interfaces. If you open an Android library in
> > > my IDE, you only see:
> > > 
> > > public final class Class<T> 
> > >    implements Serializable, GenericDeclaration, 
> > >               Type, AnnotatedElement {
> > > 
> > >         Class() {
> > >         throw new RuntimeException("Stub!");
> > >     }
> > > 
> > >     public String toString() {
> > >         throw new RuntimeException("Stub!");
> > >     }
> > > 
> > >     public String toGenericString() {
> > >         throw new RuntimeException("Stub!");
> > >     }
> > > 
> > > BTW: Same case with Java. So all that counts would
> > > be only language features that affect the interfaces.
> > > But generic types were already introduced
> > > 
> > > in JDK 6. So with JDK 6 you are on the safe side.
> > > And some packages that are not in the intersetion
> > > between Java and Android, 
> > > 
> > > you figure these out quickly.
> > > 
> > > The Android libraries byte code on the other hand
> > > uses version 52.0, thats right. But then if you
> > > stay in the JDK 6 for the non GUI
> > > 
> > > part, this doesn't mean I would recommend the
> > > same for the GUI and Android specific part.
> > > Maybe there you should profit from
> > > 
> > > the latest development. 
> > > 
> > > Am Mittwoch, 29. August 2018 01:42:28 UTC+2 schrieb Arne Vajhøj:
> > > > On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> > > > >                 I still try to develop
> > > > > against JDK 6, so that I also can use my
> > > > > code for example Android.
> > > > 
> > > > I don't understand that.
> > > > 
> > > > Android does not implement full runtime of any Java version.
> > > > 
> > > > And the language support is up to Java 8 in latest
> > > > versions I believe.
> > > > 
> > > > Arne

[toc] | [prev] | [next] | [standalone]

#38581

Strange things happen right now:

Class File Version Number is 54.0 

The class file version has been changed 
from 53 (or 44 + 9) to 54 (44 +10), even 
though JDK 10 did not introduce other 
changes to the class file format.

The OpenJDK community has adopted a new 
time-based release model, in which major 
releases of the Java platform occur every 
6 months. As a consequence, it is anticipated 
that class file changes will also occur 
more rapidly. To ensure predictability for 
the tooling that processes class file bytes, 
the class file version will be incremented 
every major release even if there are no 
other changes to the class file format. 
In effect, the class file version will 
be 44 + $FEATURE, where $FEATURE is the 
feature-release counter (previously referred 
to as the major number) of the Java SE Platform 
and the JDK version string.

http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#Remaining

Am Mittwoch, 29. August 2018 02:09:34 UTC+2 schrieb burs...@gmail.com:
> I guess with target 1.5 you get the generic
> types not included in the byte code, so code 
> that would do reflection on these wouldn't work.
> 
> Not sure. generic types are useful for compilation, 
> but then at runtime I don't need them, so I use 
> target 1.5 habitually...
> 
> Am Mittwoch, 29. August 2018 02:07:06 UTC+2 schrieb burs...@gmail.com:
> > For the CheerpJ test I even used:
> > 
> >    bytecode version: 49.0 (Java 5.0)
> >  
> > There are applet issues:
> > 
> >    "I can not launch my java application 
> >    as a web applet in HTML (I am using HTML 
> >    4.01, I know it doesn't work in html5). 
> >    The error message it returns is:
> >    java : Unsupported major.minor version 52.0
> >    https://stackoverflow.com/questions/23249331/java-unsupported-major-minor-version-52-0
> > 
> > I think there is an interim time, where 
> > both 49.0 and 52.0 are support by the 
> > usual Java runtimes. Not sure.
> > 
> > But with respect to some Tomcat Servers, Applets 
> > etc.. I habitually compile with target 1.5. I did 
> > not yet check CheerpJ with a different target.
> > 
> > Am Mittwoch, 29. August 2018 01:58:45 UTC+2 schrieb burs...@gmail.com:
> > > Corr.:
> > > BTW: Same case with Java.
> > > 
> > > By that I mean, for Java libraries you also 
> > > need to only look for interface compatibility
> > > I guess. If the code involves side effects,
> > > 
> > > well then you possibly need to know more
> > > about the libraries....
> > > 
> > > Am Mittwoch, 29. August 2018 01:56:41 UTC+2 schrieb burs...@gmail.com:
> > > > The language level is independent of the Android
> > > > Libraries. Language features along the code and
> > > > not along the interface are not seen in the
> > > > 
> > > > Android Libraries, since they are only seen as
> > > > interfaces. If you open an Android library in
> > > > my IDE, you only see:
> > > > 
> > > > public final class Class<T> 
> > > >    implements Serializable, GenericDeclaration, 
> > > >               Type, AnnotatedElement {
> > > > 
> > > >         Class() {
> > > >         throw new RuntimeException("Stub!");
> > > >     }
> > > > 
> > > >     public String toString() {
> > > >         throw new RuntimeException("Stub!");
> > > >     }
> > > > 
> > > >     public String toGenericString() {
> > > >         throw new RuntimeException("Stub!");
> > > >     }
> > > > 
> > > > BTW: Same case with Java. So all that counts would
> > > > be only language features that affect the interfaces.
> > > > But generic types were already introduced
> > > > 
> > > > in JDK 6. So with JDK 6 you are on the safe side.
> > > > And some packages that are not in the intersetion
> > > > between Java and Android, 
> > > > 
> > > > you figure these out quickly.
> > > > 
> > > > The Android libraries byte code on the other hand
> > > > uses version 52.0, thats right. But then if you
> > > > stay in the JDK 6 for the non GUI
> > > > 
> > > > part, this doesn't mean I would recommend the
> > > > same for the GUI and Android specific part.
> > > > Maybe there you should profit from
> > > > 
> > > > the latest development. 
> > > > 
> > > > Am Mittwoch, 29. August 2018 01:42:28 UTC+2 schrieb Arne Vajhøj:
> > > > > On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> > > > > >                 I still try to develop
> > > > > > against JDK 6, so that I also can use my
> > > > > > code for example Android.
> > > > > 
> > > > > I don't understand that.
> > > > > 
> > > > > Android does not implement full runtime of any Java version.
> > > > > 
> > > > > And the language support is up to Java 8 in latest
> > > > > versions I believe.
> > > > > 
> > > > > Arne

[toc] | [prev] | [next] | [standalone]

#38582

Corr.:
My bad. To strip the generics you need a tool
or options. target 1.5 has also generics, they
were already introduced in 1.5.

Then the runtime 1.6 has for example things 
introduced like Math.getExponent(), so if you
use target 1.5, you might still run it,

for example when this target is in the range
of a JVM with higher major >=1.6.

Am Mittwoch, 29. August 2018 02:09:34 UTC+2 schrieb burs...@gmail.com:
> I guess with target 1.5 you get the generic
> types not included in the byte code, so code 
> that would do reflection on these wouldn't work.
> 
> Not sure. generic types are useful for compilation, 
> but then at runtime I don't need them, so I use 
> target 1.5 habitually...
> 
> Am Mittwoch, 29. August 2018 02:07:06 UTC+2 schrieb burs...@gmail.com:
> > For the CheerpJ test I even used:
> > 
> >    bytecode version: 49.0 (Java 5.0)
> >  
> > There are applet issues:
> > 
> >    "I can not launch my java application 
> >    as a web applet in HTML (I am using HTML 
> >    4.01, I know it doesn't work in html5). 
> >    The error message it returns is:
> >    java : Unsupported major.minor version 52.0
> >    https://stackoverflow.com/questions/23249331/java-unsupported-major-minor-version-52-0
> > 
> > I think there is an interim time, where 
> > both 49.0 and 52.0 are support by the 
> > usual Java runtimes. Not sure.
> > 
> > But with respect to some Tomcat Servers, Applets 
> > etc.. I habitually compile with target 1.5. I did 
> > not yet check CheerpJ with a different target.
> > 
> > Am Mittwoch, 29. August 2018 01:58:45 UTC+2 schrieb burs...@gmail.com:
> > > Corr.:
> > > BTW: Same case with Java.
> > > 
> > > By that I mean, for Java libraries you also 
> > > need to only look for interface compatibility
> > > I guess. If the code involves side effects,
> > > 
> > > well then you possibly need to know more
> > > about the libraries....
> > > 
> > > Am Mittwoch, 29. August 2018 01:56:41 UTC+2 schrieb burs...@gmail.com:
> > > > The language level is independent of the Android
> > > > Libraries. Language features along the code and
> > > > not along the interface are not seen in the
> > > > 
> > > > Android Libraries, since they are only seen as
> > > > interfaces. If you open an Android library in
> > > > my IDE, you only see:
> > > > 
> > > > public final class Class<T> 
> > > >    implements Serializable, GenericDeclaration, 
> > > >               Type, AnnotatedElement {
> > > > 
> > > >         Class() {
> > > >         throw new RuntimeException("Stub!");
> > > >     }
> > > > 
> > > >     public String toString() {
> > > >         throw new RuntimeException("Stub!");
> > > >     }
> > > > 
> > > >     public String toGenericString() {
> > > >         throw new RuntimeException("Stub!");
> > > >     }
> > > > 
> > > > BTW: Same case with Java. So all that counts would
> > > > be only language features that affect the interfaces.
> > > > But generic types were already introduced
> > > > 
> > > > in JDK 6. So with JDK 6 you are on the safe side.
> > > > And some packages that are not in the intersetion
> > > > between Java and Android, 
> > > > 
> > > > you figure these out quickly.
> > > > 
> > > > The Android libraries byte code on the other hand
> > > > uses version 52.0, thats right. But then if you
> > > > stay in the JDK 6 for the non GUI
> > > > 
> > > > part, this doesn't mean I would recommend the
> > > > same for the GUI and Android specific part.
> > > > Maybe there you should profit from
> > > > 
> > > > the latest development. 
> > > > 
> > > > Am Mittwoch, 29. August 2018 01:42:28 UTC+2 schrieb Arne Vajhøj:
> > > > > On 8/28/2018 7:00 PM, bursejan@gmail.com wrote:
> > > > > >                 I still try to develop
> > > > > > against JDK 6, so that I also can use my
> > > > > > code for example Android.
> > > > > 
> > > > > I don't understand that.
> > > > > 
> > > > > Android does not implement full runtime of any Java version.
> > > > > 
> > > > > And the language support is up to Java 8 in latest
> > > > > versions I believe.
> > > > > 
> > > > > Arne

[toc] | [prev] | [next] | [standalone]

#38583

For example I just compiled some code with:

        Math.getExponent(3.1415f);

to target -1.5. The compiler didn't say anything, 
only the IDE had it underlined with a warning.
So the byte code version cannot very much

ensure predictability for the tooling, not like
oracle advertised the byte code version...

Am Mittwoch, 29. August 2018 02:47:18 UTC+2 schrieb burs...@gmail.com:
> Corr.:
> My bad. To strip the generics you need a tool
> or options. target 1.5 has also generics, they
> were already introduced in 1.5.
> 
> Then the runtime 1.6 has for example things 
> introduced like Math.getExponent(), so if you
> use target 1.5, you might still run it,
> 
> for example when this target is in the range
> of a JVM with higher major >=1.6.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web