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

Fri Sep 8 08:38:19 UTC 2017

Hi David,
I think you raise many valid points, but I also think that this 
discussion should not happen as part of a review in valhalla-dev

We're in a transitory phase - a bit caught between different ways to do 
things. Organizing repos in branches is the first attempt to move things 
in a way so that features are hosted in separate places, so that they 
can target different JDK mainlines. Now we need to create rules and 
processes around that, so that things will go smoothly most of the times 
- and insert automation whenever possible. There are simply too many 
manual processes that need to happen right now - bump sourcefile 
version, bump classfile version, bump ASM to name a few - for some of 
which it's just matter of burping the patch - but others (esp. ASM) are 
far more delicate, and require several degrees of clearance to go 
through - all which require time. This is obviously not sustainable if 
we're to ship every 6 months.

So, I think on this one we need to take a more holistic approach, and 
think about the changes that we wanna see happening that would make us 
confident that we'd landed in a good place - and then implement those 
changes. If every dev solves his/her own problems in an ad-hoc (even if 
correct) way, then everybody loses.

I suggest we bring up this discussing in a wider mailing list, such as 
discuss at o.j.n and see whether we can come up with a good model for 
reasoning about these things in the light of the recent news about the 
new release model.

Cheers
Maurizio

On 07/09/17 22:38, David Holmes wrote:
> 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
>>