Please note that it's not just language features, I would say it's more
about library APIs that jdk.compiler uses. The most obvious such change
in the past is the modules API. In JDK 9, we had to keep the
jdk.compiler modules (with friends) compatible with both a pre modules
and post modules environment. Being able to scrap all those extra
workarounds (reflective access, duplicate implementations, filtered
classes at compile time etc) already in 10 made development and
maintenance of that source much simpler.
I agree that OpenJDK is mainly for users, but my view of users is mainly
the people using OpenJDK, not the ones building it. Sure, it is an open
source project and as such a user is free to download and build from
source on their own. However, the vast majority is downloading prebuilt
binaries. Given that, I see the main conflict in this case rather being
between OpenJDK developers and the package maintainers/distributors who
regularly have to build it.
I don't really think it's fair that the OpenJDK developers should have
to pay a heavy development and maintenance tax just to make it a little
bit more convenient to build the product from source.
/Erik
On 2018-03-23 19:13, John Paul Adrian Glaubitz wrote:
On 03/24/2018 01:07 AM, Magnus Ihse Bursie wrote:
But if javac developers are seriously hindered in their effort to enhance Java
due to this, then maybe developer convenience is not as important.
But is using the latest Java features really so important for OpenJDK
development? I mean, do people seriously say "Oh, we have type inference
for variables now. We have to use it immediately, it's making the code so
much better and faster!!!" (sorry, couldn't resist the hyperbole).
I mean, in the end, OpenJDK is developed for users and not for the OpenJDK
developers sake to use Java, isn't it? So, I think the project should always
keep users and downstream interests in mind.
Adrian
