Initial RFR: 8187302: [Nestmates] Prepare for classfile version 54 and javac "release" update

[David Holmes]

Hi Maurizio,

I didn't see your public comment before my private reply so I'll repeat 
that reply here - as there's nothing really private about it. :)

On 8/09/2017 12:59 AM, Maurizio Cimadamore wrote:
> As discussed individually, I believe that bumping classfile version (or 
> source version) is not something that an experimental branch should do. 
> The risk of doing so is that multiple developers will be doing the same 
> change (perhaps in slightly incompatible ways) and create an integration 
> hell.

The work I'm doing _has_ to involve a change to the classfile version 
and I need the related changes to the javac --release so that I can 
control that. So regardless of whether I end up pushing this change from 
the nestmates branch I'm going to need the change. And the same is 
likely true for a project like condy.

> So I believe it would be best to assume that any given experimental 
> branch adds some experimental behavior on top of the latest version 
> (whatever that is at a given point in time). If certain features need to 
> be constrained further (see MVT, where we don't want all classfiles to 
> be able to exploit value opcodes), minor version can be used for that 
> purpose.

I don't see any difference between using v54 versus v53.1 ??? I still 
need a different classfile version and I still need a way to tell javac 
to produce it.

> When it's time to target a specific JDK N, I think the work to setup 
> appropriate source/version numbers should happen in the upstream repo; 
> once that's settled, changes will flow onto the branches - which will 
> then changed to target the desired version number. Then a patch for the 
> branch is extracted and pushed upstream (after due review, etc.).

I would be happy to leave this exercise to someone else in another repo 
to merge into mainline. But there are two significant problems with that:

1. It doesn't help me! I need to be able to work with the updated 
version information _now_, so that I can complete this feature. So I'm 
going to have to apply those changes in vahalla-nestmates even if I 
never intend to actually migrate them. Same would be true for the Condy 
folk.

2. Someone somewhere has to be given this task and work on it to ensure 
it is ready to push to mainline as soon as 10/18.3 has forked. If that 
isn't me or someone from condy then who will do it? Plus even if the 
version change pushes immediately after the fork, that will still delay 
the completion of nestmates/condy as we will have to pull those changes 
back into the project repos (or more likely a separate mainline sandbox 
by this stage) and then finish of the features so we can push them.

Given that, it really makes no difference if I include these changes 
with nestmates, or someone from condy includes them with condy. We will 
both need a local variant of them anyway, and whomever does the push 
doesn't have a messy integration. If a third-party does the push 
"upstream" then we both have a messy integration.

And if condy and nestmates are in different releases anyway then the 
exercise has to happen twice.

> I would not be surprised if, now that we're moving to a more regular 
> release cadence, some of these tasks (update classfile version/source 
> version) would be automated and automatically applied after a new 
> version has 'forked off'.

That would be nice I think, but I'd still need a way to manually trigger 
that _now_ so that I can base my work on it _now_.

Cheers,
David
-----

> Maurizio
> 
> 
> On 07/09/17 14:20, Karen Kinnear wrote:
>> 10 is planning to bump to 54 for condy
>>
>> Karen
>>
>>> On Sep 7, 2017, at 6:48 AM, David Holmes<david.holmes at oracle.com>  wrote:
>>>
>>> Hi Remi,
>>>
>>> On 7/09/2017 7:39 PM, Remi Forax wrote:
>>>> Hi David,
>>>> Having 10 -> v53 and 11 -> v54 is weird,
>>> How is that weird? I just incremented the value. If it turns out that 10 needs to bump to 54 then I'd bump 11 to 55.
>>>
>>>> perhaps, --release 99 is better than release 11.
>>> ???
>>>
>>> David
>>>
>>>> Rémi
>>>> ----- Mail original -----
>>>>> De: "David Holmes"<david.holmes at oracle.com>
>>>>> À: "valhalla-dev"<valhalla-dev at openjdk.java.net>
>>>>> Envoyé: Jeudi 7 Septembre 2017 10:54:04
>>>>> Objet: Initial RFR: 8187302: [Nestmates] Prepare for classfile version 54 and javac "release" update
>>>>> webrev:http://cr.openjdk.java.net/~dholmes/8187302/webrev/
>>>>>
>>>>> (please ignore the two hotspot test changes)
>>>>>
>>>>> This changes prepares for switching to release 11 and classfile version
>>>>> 54 so that I can put classfile version checks where needed, and compile
>>>>> tests the right way, where needed.
>>>>>
>>>>> Initially the default remains release 10 and v53, but --release 11 can
>>>>> be used to explicitly use v54.
>>>>>
>>>>> I think I have found everything that needs updating to allow use of
>>>>> release 11 and v54 classfiles.
>>>>>
>>>>> Testing so far is minimal: javac Foo.java -> v53
>>>>>                             javac --release 11 Foo.java -> v54
>>>>>
>>>>> langtools/tools/javac testing also conducted.
>>>>>
>>>>> Thanks,
>>>>> David
>