valhalla openjdk repository

Maurizio Cimadamore maurizio.cimadamore at
Tue May 16 20:58:13 UTC 2017

On 16/05/17 21:14, Remi Forax wrote:
> Hi Karen, hi all,
> the main issue i see with branches is that, they easily becomes incompatibles, which means that less people will test before things are integrated in main workspace.
> by example for amber, lvti and lambda-leftover both change the frontend compiler in an incompatible way,
> even if it can be easily fixed, it's an unnecessary barrier for testing in my opinion.
> I believe that the default repo should contains the code of all branches automatically integrated so people will be able to test without messing with branches.
Hi Remi,
the branch-based solution is an attempt to work with openjdk projects in 
a more flexible way. Big projects such as valhalla or amber, often ends 
up (either accidentally, as Valhalla), or by design (as Amber) to be 
containers for several isolated sub-projects. From a perspective of 
trying to keep the code fresh, it is much better to try not to put 
everything in the same place - as that will lead to the usual issues:

* proliferation of both compile-time and runtime-flags
* accumulation of dead code
* increasing pain when doing merges (which are mostly a manual process)

I agree that, when it comes to try the bits out, the branch-based 
approach feels inferior to what we had before, but we have ideas on how 
to improve on that. In the current infrastructure we can easily setup 
'dependent' branches, which can contain multiple branches at once, and 
also receive the automatic merge treatment. So it's just a matter of 
mere infra programming to create branches for the subset of features 
that feel more ready for widespread testing.

Another obstacle to all this is availability of binary snapshot - as 
we'd like to reduce entry barrier and not to have people mess with 
source code in order to test. This is another thing in our radar which 
will be addressed.

So, while I agree that some edges of the new infra are sharp, I think 
this approach has a lot more room to improve than the old one - and it 
makes for a much saner process when it comes to integrate the various 
features into separate JDK changesets (and reviews) - not so long ago 
I've spent a significant portion of my time - and sanity! - trying to 
extract a set of curated patches out of the monolithic lambda repositories.

> Rémi
> ----- Mail original -----
>> De: "Karen Kinnear" <karen.kinnear at>
>> À: valhalla-dev at
>> Envoyé: Mardi 16 Mai 2017 00:05:04
>> Objet: valhalla openjdk repository
>> Please hold off making changes to the valhalla openjdk repository until further
>> notice.
>> We are in the process of updating the parent to be based off of jdk10/hs to have
>> the
>> latest changes.
>> When the repository is ready, I will let you know.
>> We are moving to a branch model, so that we will NOT be pushing changes to the
>> valhalla/valhalla repository.
>> Instead we will create branches underneath that for specific projects, including
>> to start with
>> mvt (minimal value types) and
>> nest mates (JEP 181: nested class access controls)
>> Once those are created, give us time to push the merged code to mvt and then I
>> will
>> notify you that the repository is open for business.
>> thanks,
>> Karen
>> p.s. Note that we have saved the existing valhalla repository to
>> valhalla/valhalla9 and made it read-only

More information about the valhalla-dev mailing list