[rfc][icedtea-web] Java 7 bump

[Andrew Hughes]

----- Original Message -----
> On 04/07/2014 05:39 PM, Omair Majid wrote:
> > * Andrew Azores <aazores at redhat.com> [2014-04-07 17:24]:
> >> Here's my attempt at getting the build system properly checking for
> >> and working with Java 7.

Only just seen this via the archives. As the build system was originally
forked from IcedTea, it's probably worth keeping an eye on changes there
and porting over as necessary. In particular, the JDK list seems to be
outdated compared with IcedTea 2.x (see reply to commit).

> > Previously, a 6 was the a minimal version, but icedtea-web would
> > build/work with 7 too. The mirror of that would be requiring 7 but also
> > working with 8. But I don't think this patch works with just 8. Am I
> > mistaken?
> 
> I have both 7 and 8 (and 5 due to GCJ) installed on my machine here and
> the version check seemed to work properly in each case, switching
> between them with system-switch-java since the first location checked is
> now set by alternatives. With 5 it complained and failed, and with 7 or
> 8 it completed normally. So as far as I can tell, I think it works.
> 
> >
> >> Note that (1) almost all of what I know about autotools was learned
> >> today
> > This is amazing stuff!
> 
> Thanks :)
> 
> >
> >> -    for dir in /usr/lib/jvm/java-openjdk /usr/lib/jvm/icedtea6 \
> >> -    	      /usr/lib/jvm/java-6-openjdk /usr/lib/jvm/openjdk \
> >> -              /usr/lib/jvm/java-icedtea /usr/lib/jvm/java-gcj
> >> /usr/lib/jvm/gcj-jdk \
> >> -              /usr/lib/jvm/cacao ; do
> >> +    for dir in /etc/alternatives/java_sdk \
> >> +               /usr/lib/jvm/java-openjdk \
> >> +               /usr/lib/jvm/java-1.7.0-openjdk \
> >> +               /usr/lib/jvm/openjdk \
> >> +               /usr/lib/jvm/java-icedtea \
> >> +               /usr/lib/jvm/cacao ; do
> > Wouldn't it make sense to add '/usr/lib/jvm/icedtea7' and
> > '/usr/lib/jvm/java-7-openjdk' to the paths too? Or have those
> > distributions changed the paths?

With IcedTea, we put the most specific JDKs first and work down to
general alternatives.

    ICEDTEA6_VMS="/usr/lib/jvm/icedtea-6 /usr/lib/jvm/icedtea6 /usr/lib/jvm/java-6-openjdk
                  /usr/lib/jvm/java-1.6.0-openjdk.x86_64 /usr/lib64/jvm/java-1.6.0-openjdk
                  /usr/lib/jvm/java-1.6.0"
    ICEDTEA7_VMS="/usr/lib/jvm/icedtea-7 /usr/lib/jvm/icedtea7 /usr/lib/jvm/java-1.7.0-openjdk
                  /usr/lib/jvm/java-1.7.0-openjdk.x86_64 /usr/lib64/jvm/java-1.7.0-openjdk
                  /usr/lib/jvm/java-1.7.0"
    for dir in ${BOOTSTRAP_VMS} ${ICEDTEA7_VMS} ${ICEDTEA6_VMS} \
               /usr/lib/jvm/java-openjdk /usr/lib/jvm/openjdk /usr/lib/jvm/java-icedtea \
               /etc/alternatives/java_sdk_openjdk ; do

I've omitted BOOTSTRAP_VMS as it's irrelevant for ITW and won't work.

> >
> > I can't make up my mind whether we should try the well-known 7 or 8
> > locations. The default location may be 6, but it may also be the 7 or 8
> > VM the user wants to use.
> >
> >>       AC_PATH_PROG(JAVA, "gij")
> > Does 'gij' work? That's a 1.5 VM, right? Maybe this needs more cruft
> > removed.
> 
> I'm sure there's a lot more cruft I've missed.

GCJ and other Classpath JDKs aren't any particular version specifically, because
the TCK has never been made available to check this compatibility. Classpath contains
a number of 1.6 classes/methods and I think even some 7 now. What code it will compile
depends on what version of ecj is used with it.

For this reason and others, I prefer to test for required features, rather than versions
i.e. if you want to know if it can compile code with the diamond operator, compile some.
This is generally how all autotools tests work e.g.

checking for gcc... gcc
checking whether the C compiler works... yes
...
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
etc.

> 
> >
> >> -    AC_MSG_ERROR("A 1.5-compatible Java VM is required.")
> >> +    AC_MSG_ERROR("A 1.7-compatible Java VM is required.")
> > 1.7 or newer, right?
> 
> Well, yea. The 1.8 VM can still be called 1.7-compatible though, can't it?
> 
> >
> >>     JAVA_VERSION=`$JAVA -version 2>&1 | sed -n
> >>     '1s/@<:@^"@:>@*"\(.*\)"$/\1/p'`
> >> +  AC_MSG_RESULT($JAVA_VERSION)
> >>     HAVE_JAVA7=`echo $JAVA_VERSION | awk '{if ($(0) >= 1.7) print "yes"}'`
> >> -  if  ! test -z "$HAVE_JAVA7" ; then
> >> -    VERSION_DEFS='-DHAVE_JAVA7'
> >> +  HAVE_JAVA8=`echo $JAVA_VERSION | awk '{if ($(0) >= 1.8) print "yes"}'`
> >> +  if test -z "$HAVE_JAVA7"; then
> > This test is for just 7. I take it you meant to test 8 here too?
> >
> > Thanks,
> > Omair
> >
> 
> It tests and requires that at least 7 is in use, otherwise it fails out.
> If 8 or higher is in use, then it does the same trick with -DHAVE_JAVA8
> so that the plugin can add 1.8 to its MIME types. Using
> system-switch-java and reconfiguring/building, then checking
> about:plugins in Firefox does show that when using 8, an additional MIME
> type for it is added, just as before with 6 vs 7.

Is the JDK determined at compile-time or at run-time? If I build with a 7 JDK,
can I later run with an 8 JDK and it be recognised as such?

> 
> Thanks,
> 
> --
> Andrew A
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07