Preview APIs in the Java Platform

[Cédric Champeau]

Le lun. 9 mars 2020 à 03:51, Mark Derricutt <mark at talios.com> a écrit :

>
>
> The Maven model/pom files have no means to express JVM version in their
> dependencies other than using a classifier. Or one could go, with tooling
> support the direction sbt in scala went with a version numbering scheme
> ontop of mavens that included the JDK.
>
> Using a classifier might be the simplest means - such as
> `com.example.foolib-1.2-previewjdk14`.
>
>
They shouldn't do this. They should use Gradle module metadata which has
been designed for this and understands what the JVM version means.
Classifiers are ugly, they have no semantics associated, and that's why
people get transparently upgraded from a JRE version of Guava to Android,
just because the version number happens to be higher. Please stop
recommending classifiers or version numbers for things they are not
designed to do. Use real metadata and tools which can handle that. Neither
Maven nor Sbt do. We have quite a few blog posts at https://blog.gradle.org
which explain this, I'm sad when such poor solutions are recommended.

That said, to come back to the topic, I agree that libraries published with
experimental features should not be published on Maven Central. It's like
the GPL: once you publish such a library, you're forcing all your consumers
to do the same. It also forces them to configure their build tools and IDE
differently, just because by accident they would transitively use a library
which happened to activate an experimental feature. Again Gradle module
metadata could help there, but we don't have an attribute to model the fact
that a variant of a library uses experimental features. We could do this,
not too hard, but I'm not convinced it's a good idea. Long story short, I
think experimental features or APIs should be limited to your toy projects,
but certainly not used by mainstream libraries. As a consumer, I don't want
my project to suddenly break because an experimental API changed in a new
JDK release, or that the JVM changed the implementation, or that the
bytecode format changed between two releases of the experimental feature. I
think the comparison with newer JDK releases (it's the same as if a library
is compiled for a newer version of the JDK) is not correct, because we're
talking about things which are deemed unstable, and promoted as such. If
they were stable, they wouldn't be experimental.

For Gradle we're thinking about modeling experimental as a first class
citizen so that people can be warned when they do such a thing as
publishing with experimental on. You must absolutely be aware of what you
do.