Looks like no type aliases still? Does anyone know if type aliases are anywhere on the road map for Java? Is there some philosophical objection to them?
Java 16
81–90 of 327 posts
Re: Java 16
#82Very cool to see that Scala continues to have a huge impact on Java’s roadmap. Records and Sealed Classes are borrowed from Scala. Could be not the best news for new Scala adoption, but good news for developers having better abstractions in Java Edit: Kotlin, and other languages should also mentioned since they also include similar features. I still think Scala has had the most influence over the years.
> Records (...) are borrowed from Scala. I think records already existed in FORTRAN and other languages like ALGOL-60. C has structs, too.
[deleted]
Re: Java 16
#83Earlier quoted context omitted.
Java 8 → Java 11 → Java 17. Those are the LTS releases. If you want to follow a release cadence similar to Java 5 → Java 6 → Java 7 → Java 8, that's what you'll track. The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do e…
If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.
Spring supported each and every java release between 9 and 16.
With one release being supported a month later (don't remember which).
I know because I use Spring (and hibernate) and everything just works.
(If you are on the most recent Spring version)
Re: Java 16
#84What's the state of tail call optimization on JVM nowadays?
Re: Java 16
#85Still on Java 8 at work :-/
Amazon's version or the for a while now EOL Oracle version? Maybe push to upgrade to something supported :)
Re: Java 16
#86Earlier quoted context omitted.
I think the reaction has been more to Kotlin than Scala.
I’m more a Scala dev than Kotlin Think it’s safe to say both influenced Java’s Record, shoulda mentioned Kotlin too.
Kotlins data class is functionally basically the same as a lombok @Data class used in Java. Why Java didn't keep the name "Data class" I don't know.
Re: Java 16
#87Looks like no type aliases still? Does anyone know if type aliases are anywhere on the road map for Java? Is there some philosophical objection to them?
I do not believe they are on the roadmap at all.
Re: Java 16
#88Re: Java 16
#89Earlier quoted context omitted.
yeah I'm confused too, so its because Java 9 officially came out September 2017 and they've been releasing very fast but have completely ditched semantic versioning chart here https://en.wikipedia.org/wiki/Java_version_history
Java 8 → Java 11 → Java 17. Those are the LTS releases. If you want to follow a release cadence similar to Java 5 → Java 6 → Java 7 → Java 8, that's what you'll track. The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do e…
Not quite.
LTS doesn't mean anything if you mention just the Java versions.
This is not e.g. Ubuntu LTS.
In java you have different vendors that provide LTS and you need to pay for it.
Oracle, Redhat, etc. provide LTS versions (and those happen to be 8, 11, but don't have to be).
And there is one more sortof LTS: latest java version, because it always gets all the security and other bugfixes. Right now it is Java 16.
Re: Java 16
#90Curious how many folks here experimented with the now depreciated Ahead-of-Time Compilation feature?
I did, the main issue is that jaotc doesn't do any pruning of the unused methods, so it generates too much assembly code. If i remember correctly, compiling just guava was to close to 1 gig. GraalVM native image is far better, it "compiles" more slowly but the resulting executable is not too big.
I think that is by design due to reflection needs. Hard to prune unused code when it might be called reflectively at any time.