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

[mark.reinhold at oracle.com]

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.

- Mark


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