public class TextBlocks {
public static void main(String[] args) {
System.out.println("""
Hello,
text blocks!""");
}
}From Idea to IDE
How Java Features Are Considered, Designed, And Shipped
Developer Advocate
Java Team at Oracle
Text Blocks
A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired.
language feature added in Java 15
triggered additions to
String:
formatted,indent,stripIndent,translateEscapes
Hallmarks
Java features:
come as syntax, VM capabilities, APIs
(or any combination)specified in JLS, JVMS, Javadoc, etc. &
implemented in openjdk/jdkfulfill clearly defined requirements
fit in seamlessly & have good tool support
Why did this take so long?
Evolution
Considerations for feature evolution/removal:
Does it hurt?
Is it used?
Can it be extended/improved?
Would a change/removal hurt?
Some Removals
- Single underscore as variable name ⛔⑨:
rarely used
prevents very useful language feature
easy to fix
- Applet API ⚠️⑰:
unused and unusable
- Concurrent mark sweep GC ⛔⑭:
maintenance cost
lots of alternative GCs
easy to fix
Prepare Your Code Bases For Future Java
Inside Java Newscast #41
Evolution
Features are extremely stable
but not immutable.
My guesstimates:
rate of change: 1%
survival rate: 99.9%
Evolution
But how does a feature become permanent?
Long story:
starts with an idea
refinement in explorations
prototype and proposal
preview feature
finalized feature
From Idea to IDE
| Features |
| Previews |
| Proposals |
| Explorations |
| Ideas |
Previews in Java 20
Specification
The concept of preview features was:
introduced by JEP 12
refined by a recent JEP draft
specified by JLS (e.g., for 19)
Artifacts
Required artifacts for preview features:
specified in JLS:
all preview features are mentioned
JLS changes/diffs are linked
implemented in openjdk/jdk, but:
disabled by default
by compiler and runtime
Enabling
Enabling:
for compiler and runtime
with--enable-previewgenerates compiler warnings
pins Java version
Example
Enabling For Compilation
Compiling with Java 14:
$ javac TextBlocks.java
> TextBlocks.java:4: error: text blocks are a preview
> feature and are disabled by default.
> System.out.println("""
> ^
> (use --enable-preview to enable text blocks)
> 1 error
$ javac --enable-preview --release 14 TextBlocks.java
> Note: TextBlocks.java uses preview language features.
> Note: Recompile with -Xlint:preview for details.Enabling For Execution
Running with Java 14:
$ java TextBlocks
> Error: LinkageError occurred while loading main class
> TextBlocks
> java.lang.UnsupportedClassVersionError:
> Preview features are not enabled for
> TextBlocks (class file version 58.65535).
> Try running with '--enable-preview'
$ java --enable-preview TextBlocks
> Hello,
> text blocks!Version Pinning
Compiled with Java 14, launched with 15:
$ java --enable-preview TextBlocks
> Error: LinkageError occurred while loading main class
> TextBlocks
> java.lang.UnsupportedClassVersionError:
> TextBlocks (class file version 58.65535)
> was compiled with preview features that are
> unsupported. This version of the Java Runtime
> only recognizes preview features for class
> file version 59.65535Goals & Considerations
Goals of preview features:
prevent (accidental) use in production
foster early IDE support
user experimentation and reports
review and refinement
Considerations:
"Is it surfaced correctly?"
"Are there unforeseen edge cases?"
Evolution
Preview features evolve a bit
(particularly on the surface)
and usually finalize.
My guesstimates:
duration: 12-24 months
rate of change: 5%
rate of progression: 95%
From Idea to IDE
| Features |
| Previews |
| Proposals |
| Explorations |
| Ideas |
Some Current Proposals
Specification
JEPs were introduced by JEP 1.
It was superseded by JEP 2.0 draft.
JEP Filters
JEPs (as JBS issues) by states:
JEP Progression (All)
drafted: 421
rejected: 26
still open: 55
candidate: 340
withdrawn: 18
open & active: 24
open & dormant: 13
delivered: 285
JEP Progression (Closed)
drafted: 329
candidate: 303 (90%)
delivered: 285 (85%)
Artifacts
Proposals are defined by JEPs.
Often also come with implementations in
project forks or feature branches of openjdk/jdk, e.g.:
Goals & Considerations
Goals of JEPs:
expose proposal to wider audience
seek feedback on the proposed solution
motivate, describe, archive proposals
with their contexts and consequences
Proposal considerations:
"Is this the right way to do it?"
Evolution
Proposals evolve noticeably
(particularly until Candidate)
and most are delivered.
My guesstimates:
duration: 6-36 months
rate of change: 40%
rate of progression: 85%
From Idea to IDE
| Features |
| Previews |
| Proposals |
| Explorations |
| Ideas |
Some Ongoing Explorations
"withers" for records (design notes)
a relaxed launch protocoll (design notes)
statements before
this/superin constructors
(some of the mails, issue)
Artifacts
mailing list exchanges
meetings
design notes (e.g. for Amber)
conference talks
(Roughly in order.)
Unspecified
Unlike the steps so far, this one is:
mostly unspecified
mostly unstructured
without barrier for contribution
Goals
assess feasibility
shape a general idea
to a specific proposalestimate complexity and effort
Considerations
"Does it fit into Java / the ecosystem?"
"Can it be implemented?"
"Can it be introduced?"
"What priority does it have?"
Evolution
During exploration, features evolve
fundamentally and many are dropped.
My guesstimates:
duration: 6-60 months
rate of change: 50-500%
rate of progression: 25-75%
From Idea to IDE
| Features |
| Previews |
| Proposals |
| Explorations |
| Ideas |
Existing Ideas
If only Java had $FEATURE, this would be so much more elegant.
(Stares procrastinatingly into distance…)
— Every Java Programmer
Existing Ideas
$FEATURE works great in $LANG.
Java needs $FEATURE!
— Every Java/$LANG Programmer
Existing Ideas
Even Brian Goetz has so many,
he needs a bunch of notebooks
to keep track of them.
Free For All
Ideas are cheap…
no specifications
no process
no barriers
no attention
…execution is everything.
Goals & Considerations
Goal is to make Java / the JVM better.
Considerations:
"Is this a good idea?"
"… for Java?"
"… now and/or in the future?"
Evolution
My guesstimates:
duration: 🤷🏾♂️
rate of change: 🤷🏾♂️
rate of progression: 🤷🏾♂️
The Full Journey
Got everything?
Let’s rewind.
The Full Journey
| Considerations | |
|---|---|
Idea | "Can it be good for Java?" |
Exploration | "How can it be implemented/introduced?" |
Proposal | "Is this the best way to implement it?" |
Preview | "Is it surfaced correctly?" |
Feature | "Does it hurt? Can it be changed/removed?" |
Contributing Don’ts
start with an implementation
write a JEP or file a feature issue
propose (just) a solution on a mailing list
assume to be the first one with that idea
forget to research past phases
Contributing Dos
be mindful of the phase
start with experimentation and reporting
describe problems and solicit input
discuss before coding
The Full Journey
| Spec | Artifacts | 📆 | 🧬 | 🚀 | |
|---|---|---|---|---|---|
Idea | — | 🌬, 📔 | 🤷🏾♂️ | 🤷🏾♂️ | 🤷🏾♂️ |
Explorat. | — | 🎟, 📬, … | 6-60 | 50-500% | 25-75% |
Proposal | JEP 1 | JEP / jdk 🌳 | 6-36 | 40% | 85% |
Preview | JLS | JLS diff / jdk | 12-24 | 5% | 95% |
Feature | JLS | JLS / jdk | ∞ | 0.5% |
Nota Bene
Incubating APIs:
belong into Proposal (not Preview)
come with alpha implementations
JEPs:
not all proposals need one
smaller changes rely on JBS issues
Why So Serious?
Every change impacts:
millions of developers
billions of lines of code
research, games, hobby projects,
and billions of Euros of annual revenue
Better safe than sorry.
So long…
More
Slides at slides.nipafx.dev⇜ Get my book!
Follow Nicolai
nipafx.dev/nipafx
Follow Java
inside.java // dev.java/java // /openjdk
Image Credits
From Idea to IDE
How Java Features Are Considered, Designed, And Shipped
Nicolai Parlog
nipafx.dev
/ @nipafx
Java
youtube.com/java
/ @java
Developer Advocate
Java Team at Oracle
Nicolai Parlog
/ nipafx.dev
/ @nipafx
Java
/ youtube.com/java
/ @java