Allow new language features on older version targets?

[Glavo]

>
> That many people still use Java 8 (often alongside newer versions) doesn't
> mean that those applications are under heavy development and can benefit
> from
> new language features, or from new library features, as much as more active
> codebases.
>

I agree that this is the case for program developers, but the focus
of the problem is not on them. The main problem is the developers
of the libraries. As developers of the library, we need to choose the
lower java version as possible and stay here for a long time. Every
time we update Java, we are abandoning a group of users and splitting
the user group. This doesn't mean that we don't pursue new technologies.
I always install the latest JDK on my computer and use it to compile
Java 8 compatible code. I will solve the problem of porting with all
Java versions, but I can't choose to give up users of the old version
of Java, so I can only use Java 8 to develop class libraries forever.
I believe that making class libraries compatible with both new and old
versions of Java is a very common requirement. A considerable number
of these users can benefit from the new language features, but they
have to stay in the old version for more users. This problem can be
seen from the fact that many class libraries are compiled with Java 8
but carry module-info.class. This problem will also become more prominent
because Valhalla refuses us to provide class libraries that work well
on both old and new versions, even features such as Universal Generics
that should work on old Java.

The portion of people using alternative languages on the Java platform has
> remained more-or-less constant for many years...
>

Are you sure? It's not what I know. In my opinion, more and more users
are choosing Kotlin instead of Java -- and most of them choose Java 8
or 6 as the target version.

I just hate developing class libraries with kotlin or Scala. Their
interaction with Java is not as good as using java directly. Moreover,
Scala 3 contains too many bugs and introduces features I hate very much.
So I've been enduring the syntax of Java 8. So I have been enduring
the syntax of Java 8, so that I have begun to develop a compiler
compatible with the latest Java syntax and can take Java 8 as the
compilation target. But this will take a long time and will cost me a
lot of energy to maintain, so I am eager for an official solution.






Ron Pressler <ron.pressler at oracle.com> 于2021年10月13日周三 上午12:44写道：

> That many people still use Java 8 (often alongside newer versions) doesn't
> mean that those applications are under heavy development and can benefit
> from
> new language features, or from new library features, as much as more active
> codebases.
>
> In any event, you're proposing that we divert resources away from making
> new
> versions more attractive toward making older versions more attractive. I
> don't
> think this is a good strategy. The portion of people using alternative
> languages on the Java platform has remained more-or-less constant for many
> years, and I, for one, am happy that the platform caters to people with
> different programming tastes. Java's competitive focus is elsewhere.
>
> -- Ron
>
> > On 12 Oct 2021, at 09:14, Glavo <zjx001202 at gmail.com> wrote:
> >
> > Starting from Java 9, Java began to iterate rapidly and introduced
> > many new features, which made Java more expressive and modern.
> >
> > However, upgrading Java is always difficult and painful. It needs to
> > go through a series of cumbersome upgrade and migration processes.
> > In these steps, the transplantation at the syntax level is often easy,
> > because Java maintains good compatibility. However, due to subtle
> > changes in the behavior of the JVM and the standard library, it is
> > relatively difficult to upgrade the version of the java runtime.
> > At the same time, for client applications, upgrading the development
> > environment is much easier than upgrading the Java version of the
> > deployment environment (e.g., only Java 8 is currently available on
> > MIPS64el). For various reasons, a large number of users stay on the
> > old java version. According to the statistical report of JetBrains,
> > 71% of users still regularly use Java 8.0 in 2021.
> >
> > The most affected people are the developers of libraries. In order to
> > make the library more widely used, most library authors always need to
> > make their libraries use the lowest java version possible. This makes
> > it difficult for them to enjoy the expression upgrade brought by Java
> > update.
> >
> > This pain is not necessary. Although some language features of Java
> > require the cooperation of JVM and standard library, e.g. Record, but
> > this is not necessary for more features. At present, we can specify
> > the source version and target version respectively, but we can't make
> > the source version higher than the target version. I think this
> > artificial additional restriction can be removed after careful
> > consideration, so that more developers can enjoy the improvement of
> > expression ability brought by Java's new language features.
> >
> >
> > These features are pure language features that can be easily compiled
> > into older versions of Java bytecode:
> >
> >  * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance
> >    methods; Allow effectively-final variables to be used as resources
> >    in the try-with-resources statement;Allow diamond with anonymous
> >    classes if the argument type of the inferred type is denotable.
> >
> >  * Local-Variable Type Inference (JEP 286)
> >  * Local-Variable Syntax for Lambda Parameters (JEP 323)
> >  * Switch Expressions (JEP 361)
> >  * Text Blocks (JEP 378)
> >  * Pattern Matching for instanceof (JEP 394)
> >  * Pattern Matching for switch (JEP 406)
> >  * Record Patterns & Array Patterns (JEP 405)
> >
> >
> > These characteristics cannot be directly desugared, but can be accepted
> > by the old runtime:
> >
> >  * module-info.java (JEP 261): At present, it is a popular practice to
> >    use Java 8 compilation library and add module info to it. However,
> >    this practice has not been well supported by the official. Even
> >    with a build tool like gradle, it needs to be implemented by
> >    special means. If javac can accept module info when the target
> >    version is less than 9 and compile it to Java 9, it is very helpful
> >    to simplify modular existing code.
> >
> >  * Allow interface methods to be private (JDK-8071453): This seems to
> >    be allowed in jvmls 8, but it was not until Java 9 that it was
> >    introduced into the Java language.
> >
> >  * Sealed Classes (JEP 409): Javac generates
> PermittedSubclasses_attribute
> >    for sealed classes. This attribute will be ignored on the old
> >    runtime and will not destroy the program. Even if it cannot be
> >    guaranteed by the runtime before JDK 15, it can enhance the
> >    expressiveness of the language and make the code more compatible
> >    with the higher version runtime.
> >
> >  * Universal Generics (JDK-8261529): Universal generics seem to
> >    compile well into bytecode compatible with older Java version.
> >    I think it is particularly important to allow use of universal
> >    generic in older bytecodes. This allows the library to adapt it
> >    without compromising compatibility with older Java versions. This
> >    can erase many obstacles to Valhalla's promotion.
> >
> >
> > Now we can use some hacks to do similar things, like
> >
> >  https://github.com/bsideup/jabel
> >
> > But this is just hack. It is unofficial and non-standard. At the same
> > time, it also lacks tool support.
> >
> > We can also choose to switch to kotlin or Scala, both of them can emit
> > Java 8 bytecode. In fact, because of the need for compatibility, the
> > new language features of Java can't bring us more attraction because
> > we can't use it most of the time. Over time, kotlin and Scala, which
> > can have more language features on Java 8, have attracted us more and
> > more. These problems are not just in the Java 8 era. The need to be
> > compatible with old Java versions always exists, which makes it difficult
> > for many people to put new features of the Java language into production
> > for a long time. This will make Java less competitive with other JVM
> > languages.
>
>