Java 8 compatibility

[Charles Beyer]

Thomas,

Thank you for the thorough response.  I appreciate your reasoning behind
wanting to preserve JDK7 compatibility.  However, Java 7 becomes an
unsupported product this month.  It might be worth thinking about a
migration plan for the Truffle API and client projects.  As a concrete
example of why this is a problem, I have a very difficult time keeping JDK7
and JDK 1.8.0_31 installed on some of my machines because of corporate bots
that automatically remove versions with security vulnerabilities.

Regards,
Charles

On Sat, Apr 4, 2015 at 3:23 PM, Thomas Wuerthinger <
thomas.wuerthinger at oracle.com> wrote:

> Charles,
>
> Sorry to hear that the initial building process gave you a bad impression
> and thanks for your input. I agree that test coverage is a very important
> aspect of a project and we therefore have an extensive gate system that
> includes thousands of unittests “mx unittest”, bug detection tools “mx
> findbugs”, formatting checking tools “mx eclipseformat”, and tools for
> checking module dependencies “mx canonicalizeprojects”. We also create
> JaCoCo test coverage reports for every push.
>
> The reason behind our dependency on JDK7 when building Graal is not
> technical debt, but the requirement that the Truffle API must be usable for
> language implementations that require Java 7 for backwards compatibility.
> JRuby is the most prominent example for this at the moment. Building with
> JDK7 is the only way for us to ensure 100% that we do not break these
> language projects depending on Truffle.
>
> There are points of interaction between the compiler and the JDK in
> particular around compiler intrinsics where we replace JDK methods with
> more efficient representations in the compiler’s IR. Additionally, the
> compiler itself uses large part of the standard library. The differences a
> JDK version makes are usually not big and often none at all. However,
> fixing the JDK version Graal is built with makes sure that this is also the
> exact same version we run our extensive testing and benchmark structure
> with.
>
> That all said, we will investigate how we can make the initial build step
> for people new to Graal simpler. I hope with Graal becoming now more mature
> and stable, there will be a larger incentive for people to experiment with
> the technology (both in source and binary form).
>
> - thomas
>
>
> > On 04 Apr 2015, at 16:13, Charles Beyer <cjbeyer at gmail.com> wrote:
> >
> > To add data to the point I think Stefan is trying to make, I refrained
> from starting a Truffle/Graal project recently because of this bad first
> impression.
> >
> > It was a yellow flag that I needed an old JDK7 installed but a red flag
> that I need an old JDK8.  Also, I needed a different version of JDK8 for
> IGV than for building graal - another red flag.
> >
> > With a software system this complex, a big part in evaluating its use
> (for me) is trying to measure how professional the development team behind
> the project is.  Things like test coverage and how much technical debt has
> accumulated in the build system is a natural measure of that.  The current
> dependency requirements didn't leave me with a warm fuzzy feeling.
> >
> > That aside, I'm very excited about where the project is going so don't
> take this as trolling.  Rather, I just decided to wait until the JDK8
> dependency issue is resolved.
> >
> > -Charles
>
>


-- 
Charles Beyer,
cjbeyer at gmail.com
Seattle, WA