JEPs proposed to target JDK 10 (2017/11/2) (original) (raw)

mark.reinhold at oracle.com mark.reinhold at oracle.com
Mon Nov 13 21:05:50 UTC 2017

2017/11/8 9:07:18 -0800, volker.simonis at gmail.com:

...

@Brian: You wrote: "For nontrivial projects, you are expected to work iteratively, progressively refining the design, interface, implementation, and test suite together, outside of the main code line, until it is ready, and then — and only then — do you start the process of proposing to target." That's actually exactly how I understand the process as well. However, looking at the reality, how many of the JEPs (except Jigsaw and some ports) have been developed in their own repositories before they have been integrated into the main line?

Many other JEPs were, or are being, developed in their own forests or repositories. Off the top of my head:

104: Annotations on Java Types 109: Enhance Core Libraries with Lambda 126: Lambda Expressions & Virtual Extension Methods 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data 128: Unicode BCP 47 Locale Matching 138: Autoconf-Based Build System 139: Enhance javac to Improve Build Speed 150: Date & Time API 169: Value Objects 174: Nashorn JavaScript Engine 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector 191: Foreign Function Interface 199: Smart Java Compilation, Phase Two 217: Annotations Pipeline 2.0 218: Generics over Primitive Types 222: jshell: The Java Shell (Read-Eval-Print Loop) 223: New Version-String Scheme 258: HarfBuzz Font-Layout Engine 265: Marlin Graphics Renderer 286: Local-Variable Type Inference 300: Augment Use-Site Variance with Declaration-Site Defaults 301: Enhanced Enums 302: Lambda Leftovers 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions 305: Pattern Matching 309: Dynamic Class-File Constants

Quite a few other, typically smaller, JEPs were, or are being, developed in their own branches in a sandbox forest/repository [1].

We have a serious process/infrastructure problem because creating a new clone is a much to heavyweight operation

What do you mean by "heavyweight"? Sure, it takes more disk space than we'd like, but even most laptops these days are big enough to hold a handful of forests/repositories (if not dozens), and fast enough that cloning another one is no big deal.

and branches are not yet a generally accepted "working model" in the OpenJDK.

We can almost certainly make more and better use of branches, or perhaps bookmarks, going forward, and now that we have a consolidated repository I suspect that various interested contributors will look more closely at that.

Let alone the fact of testing such a clone/branch (i.e. JPRT/Mach5 for the insiders :) I'm also not sure if other tools like JBS work well with branches for example. Finally, it is currently much easier to attract the attention of a potential Oracle reviewer/sponsor when you subdivide your JEP into small sub features. I wouldn't call that cheating - it's just the only viable way to get your work done if you're an external contributor.

So, to sum it up, I think we have a well defined and sound process but we really need the infrastructure and tools to execute it!

I agree that it'd be nice to have better infrastructure and tools, and as you know a number of efforts are under way on that front. In the meantime, however, if you have a question about a Proposed-to-Target JEP, and the answer to that question would be obvious if we had better infrastructure and tools, then please just ask the question of the JEP's owner.

Even perfect infrastructure and tools would be no substitute for conversation and collaboration, nor for the resulting trust that builds up over time.

[1] http://cr.openjdk.java.net/~chegar/docs/sandbox.html

More information about the jdk-dev mailing list