Ship jdk7 ct.sym with jdk8?

[Joseph Darcy]

Hi Peter,

On 3/14/2013 2:59 PM, Peter Levart wrote:
>
> On 03/14/2013 05:46 PM, Joe Darcy wrote:
>> On 3/14/2013 4:08 AM, Peter Levart wrote:
>>> On 03/13/2013 09:44 PM, Joel Borggrén-Franck wrote:
>>>> On Mar 13, 2013, at 7:24 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>>
>>>>> On 3/12/2013 1:47 AM, Joel Borggrén-Franck wrote:
>>>>>> Why? It is just a file. If we want to make javac a more robust 
>>>>>> cross compiler (and I think we should) we should fix the 
>>>>>> logistics until we can do what we want.
>>>>> As a rule, the JDK Hg repos do *not* include binary files, just 
>>>>> source files. Therefore, there could be logistical issues in 
>>>>> simply storing the old ct.sym files in the repo. We'd ultimately 
>>>>> want to use some kind of implicit or explicit diff-based 
>>>>> compression of the cross-version information.
>>>>>
>>>> Or just inject the file at product build time, I take it for 
>>>> granted we can keep a reference implementations of our N-1 product 
>>>> in a stable enough location for this not to be an issue.
>>>>
>>>> Our infrastructure is what we make it to be. If it doesn't suit our 
>>>> purposes we should change it until it does. Also rules are there to 
>>>> suit or needs, if they are outdated we should change them.
>>>>
>>>> That being said, there are multiple ways to solve this particular 
>>>> problem, lets focus on what we should do instead of what our 
>>>> infrastructure may or may not allow us to do.
>>>>
>>>> cheers
>>>> /Joel
>>>
>>> Isn't the build environment already such that it has to have access 
>>> to "bootstrap" JDK which usually *is* one major version behind the 
>>> version of JDK/JRE it is building? Couldn't ct.sym file be 
>>> "provided" by the bootstrap JDK?
>>
>> You can also bootstrap a build of JDK N with another build of JDK N 
>> :-) In fact this is a common initial test of a JDK build to make sure 
>> it isn't DOA.
>>
>
> Ok, but the 1st JDK N build must have been built with the JDK N-1. And 
> from that on, by induction, each JDK N already has ct.(N-1).sym 
> included and can be used as bootstrap JDK to build JDK N and provide 
> it with ct.(N-1).sym... It's like virus ;-) ...
>

Thought someone might go there :-) That would more or less be feasible, 
but there are some wrinkles. Besides getting passed base case barrier of 
a JDK 8 without ct(N-1) being used to bootstrap a JDK 8 build, there are 
hazards to ct.sym being taken from a build dependency rather than from 
sources in the build itself. For example, there are subsets of the Java 
SE API that can be upgraded independently of the JDK platform. Once such 
component is jax-ws; jax-ws 2.0 shipped in JDK 6 GA but JDK 6u4 and 
later shipped with jax-ws 2.1, which made API changes. If a similar 
situation happened in the JDK 7 train and JDK 7 were used to bootstrap 
JDK 8, the ct.sym for the 7 platform would depend on which JDK 7 version 
was used to bootstrap, which is more fragile than desired!

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130314/d12ed0d7/attachment.html