JEP 12: Treatment of standard APIs supporting preview features

[Stephen Colebourne]

Previewing APIs or language features seems great at first glance. We
get to play with new stuff before final release. However, I am
concerned that mandating these as part of the SE specification is
entirely the wrong way to go. By mandating it, the effect is to
require other JVM/JDK/IDE/Tool teams to commit to potentially
considerable amounts of work for features that may yet change
radically. This is highly undesirable and totally unrealistic IMO,
especially given the strain a 6 month cadence is already going to
place on some of these teams.

The primary goal of JEP 12 is broader testing/experimentation of the
feature, but this has always been difficult to obtain, and I'm
unconvinced that bundling the feature in the main JDK binary makes
that much difference (very few people try RC versions of open source
projects, even though they are easily accessed in Maven central for
example). And for language changes, most of the time developers have
to use basic tools anyway, as the tool chain simply will not be
updated early enough for the meaningful feedback that is desired.

It seems to me that the best outcome for this feedback is Early Access
(EA) releases, as now. While the level of feedback may be
disappointing, I do not believe that the JEP proposal for preview
features will garner more feedback, yet it has dramatically higher
cost for the community. For EA releases, the question of library
changes vs language feature posed below goes away - the library
changes would simply be part of the preview release.

Stephen


On 5 March 2018 at 22:16, Dan Smith <daniel.smith at oracle.com> wrote:
> JEP 12 proposes standardization of a "preview feature" capability in the Java language and JVM. It does not propose "preview features" in the standard API. I think this leaves the platform in an unstable place, so I want to spur a discussion about how interactions with APIs should be handled.
>
> The document has this to say about Java SE APIs:
>
> ---
>
> The feature "must receive appropriate treatment in the reflective and debugging APIs of the Java SE Platform"
>
> "A preview language or VM feature in Java SE $N may rely on any API defined by Java SE $N. This includes APIs introduced in Java SE $N specifically to support the preview feature."
>
> "If a preview language feature of Java SE $N is a declaration form (e.g., record type declarations) rather than a statement or expression form, then it is legitimate for the Language Model API and/or the Annotation Processing API to model the declaration form."
>
> ---
>
> A defining characteristic of preview features is that we reserve the right to back out or redesign the feature. We make no compatibility promises. Putting something in an SE API is a compatibility promise.
>
> So, for example: the for-each language feature depends on the java.lang.Iterable interface and some "extends" clauses added to existing interfaces. If it had been released as a preview feature, the choices would be:
>
> - Introduce java.lang.Iterable as a standard API, and if it turns out that we abandon for-each, or its use of this API, it just remains as cruft. Maybe it gets deprecated.
>
> - Design the preview feature in terms of the existing API (like Collection). Unfortunately, this means there won't be a chance to get any feedback on the API part of the feature until the language part is finalized.
>
> - Introduce Iterable as a "preview standard API". Since the change touches existing classes, we'd really need something like a separate 'java.base' bundle, which would take priority over the standard bundle when the compiler/vm operates in preview mode. Lots of unexplored complexity here.
>
> API dependencies vary widely from feature to feature—many have none. But I think it would be helpful to think through some of the more challenging scenarios, assume the feature gets dropped, and work out what we want to happen next.
>
> —Dan