Initial RFR: 8187302: [Nestmates] Prepare for classfile version 54 and javac "release" update
david.holmes at oracle.com
Thu Sep 7 21:38:07 UTC 2017
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
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
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
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_.
> On 07/09/17 14:20, Karen Kinnear wrote:
>> 10 is planning to bump to 54 for condy
>>> 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.
>>>> ----- 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
>>>>> (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.
More information about the valhalla-dev