New candidate JEP: 440: Record Patterns

Brian Goetz brian.goetz at oracle.com
Sat Mar 18 14:57:38 UTC 2023



> I am curious though - what are your thoughts on having multiple, super 
> granular JEP's that only do one thing, and then work on several of 
> them at once? Is the current form more preferred?

On a historical scale, these JEPs could be described as "super 
granular"!  Compare the N pattern matching JEPs so far (and more coming) 
to a feature like Lambda, which was one big JSR (including the streams 
library).  Which is to say, there's always room to make the glass bigger 
or smaller.

The forces that we are constantly trying to balance are:

  - Doing too much at once risks taking a long time before we deliver 
anything;
  - Doing too little in one JEP means that the feature doesn't cleanly 
"stand alone";
  - Each JEP has some overhead, and doing too many is impractical. In 
particular, having multiple JEPs for features that touch the same parts 
of the spec can be much more expensive, especially if they are not on 
the same track for when they will finalize.

The right balance will vary depending on the feature, the degree of 
coupling between sub-features, etc.  I'm sure that we'll continue to 
adjust, and in some cases, over-rotate.  But I don't think a "let's 
break each feature into ten JEPs, so we can late-bind to which 
sub-features we take" is a good idea in general.




More information about the amber-dev mailing list