A categorized list of all Java and JVM features since JDK 8 to 16 • Hacker News Board

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#71

Post by jerven » Thu, Apr 01, 2021, 6:44 PM UTC

perrylaj wrote: post #24

tasogare wrote: post #12

Earlier quoted context omitted.

A lot of things are coming straight from C#, so it’s battle-tested there before inclusion I guess.

As someone unfamiliar with C# but interested in how languages impact each-other, could you provide some examples? I know C# was heavily inspired (perhaps not a strong enough word) by Java, but not as familiar with the opposite. Java does seem to absorb from tried and tested ideas. There are a few major features I can think of that have largely come from or been inspired by popular and mature 3rd party libraries (time…

C# and Java are kind of in the same space, they tend to pick up the same kind of features. But not always in the same way e.g. Records are different between the two languages. As is the path to Async.

Java benefits from more experimentation in the JVM and bigger variety in implementers.

I need to find the funny slide deck by Brian Goetz (java language architect at Oracle) where in slide one (what industry thinks he does) he shows his job is to copy from C# and in slide two he shows what academia thinks he does, copy from scala ;)

It is not this presentation, https://www.infoq.com/presentations/java-futures-2019/ but it is close in content.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#72

Post by nitrogen » Thu, Apr 01, 2021, 6:45 PM UTC

bobthepanda wrote: post #69

avmich wrote: post #41

Earlier quoted context omitted.

> I'm honestly never quite sure what people mean by "verbosity" in Java. Java improved with "var" keyword (use with caution!) and introduction of records. These are not the only code-shortening features (there are e.g. interface methods, diamond operator, lambdas, convenience "of(...)" methods, even "fluid style"), but they, used well, can really reduce verbosity.

Also, a lot of verbosity in Java came from people going off the rails with design patterns to hide crap multiple levels deep in a file with 5+ words in the class name. If you have a hammer everything’s a nail.

Frameworks like Spring/Spring Boot kind of force that as well with their runtime creation of proxy classes.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#73

Post by nitrogen » Thu, Apr 01, 2021, 6:46 PM UTC

mamon wrote: post #57

avmich wrote: post #43

Earlier quoted context omitted.

Well said :) . Spring looks so much as to show how useful ideas can be misapplied with catastrophic results. For example, liberate encouraging of dependency injections leads to multitude of interfaces which are only ever implemented once by a production code class, and maybe one more time by a test class, even though Java has all methods virtual and testing could be done without requiring the interface.

>> Java has all methods virtual and testing could be done without requiring the interface. Not sure what you mean by that. I thought that interface/implementation divide is the way to implement virtual calls. Unless you want testing frameworks to do bytecode instrumentation.

Modern testing frameworks can indeed mock concrete classes, which beats the bytecode generation that Spring would be doing anyway.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#74

Post by nitrogen » Thu, Apr 01, 2021, 6:50 PM UTC

wtetzner wrote: post #34

nlitened wrote: post #18

Earlier quoted context omitted.

I am not sure I understand, why would you want Optional type to never be null? Isn't it being null sometimes — the whole point?

Say you have: public void doSomething(Optional foo) { ... } You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.

Kotlin's approach of making null act kind of like Optional is pretty nice, but I wish there was a strict option for interacting with Java types -- by default, all Java-native types (type names ending with !) can be null and are not null checked at compile time.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#75

Post by avmich » Thu, Apr 01, 2021, 6:50 PM UTC

mamon wrote: post #57

avmich wrote: post #43

Earlier quoted context omitted.

Well said :) . Spring looks so much as to show how useful ideas can be misapplied with catastrophic results. For example, liberate encouraging of dependency injections leads to multitude of interfaces which are only ever implemented once by a production code class, and maybe one more time by a test class, even though Java has all methods virtual and testing could be done without requiring the interface.

>> Java has all methods virtual and testing could be done without requiring the interface. Not sure what you mean by that. I thought that interface/implementation divide is the way to implement virtual calls. Unless you want testing frameworks to do bytecode instrumentation.

If your interface is going to be implemented by just one class, I'd offer to skip interface - it reduces amount of code. If you still need to pass, as a parameter, a class A in order to test a class B, you can instead pass class C inherited from A, with all necessary methods overloaded.

If you just create a class A in java, no interfaces involved, class A will have its methods virtual. I'm not sure what do you mean by interface/implementation divide.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#76

Post by brabel » Thu, Apr 01, 2021, 6:51 PM UTC

dlbucci wrote: post #29

All the backend projects I work on were originally written in Java. I'll admit that Streams and Lombok make it a somewhat pleasant experience to work with, at least compared to when I used it in college (I think Java 8 was newest?). But that said, I once tried writing a new feature in Kotlin, and now all our code is Kotlin. I don't really see how Java can compete with the non-nullable types, data classes, and type-in…

I write a lot of Kotlin code but still tend to use Java a lot. All of the features you mention are not really an advantage for Kotlin anymore.

Java has had tools to deal with nulls for a long time, we tend to assume everything is non-null unless annotated with `@Nullable` and let tools check correct usage at compile time... data classes are very similar to Java 16's records. Type-inference since Java introduced `var` is pretty much on-par with Kotlin.

Some people have already started talking seriously about Kotlin now just adding friction, as you need to keep updating its version and the Gradle plugin (which is not compatible with some versions of Gradle if you're stuck with some old Gradle plugins). Java 17 should probably stabilize sealed classes, which is one of the biggest advantages of Kotlin at the moment... to be honest, even though I've always been a proponent of Kotlin, I am not nearly as enthusiastic now as I used to be about it.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#77

Post by savanu » Thu, Apr 01, 2021, 6:52 PM UTC

wtetzner wrote: post #34

nlitened wrote: post #18

Earlier quoted context omitted.

I am not sure I understand, why would you want Optional type to never be null? Isn't it being null sometimes — the whole point?

Say you have: public void doSomething(Optional foo) { ... } You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.

How does making Optionals allocated on the stack (value types) prevent this?

Or rather why do you need value types to accomplish this?

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#78

Post by twh270 » Thu, Apr 01, 2021, 6:56 PM UTC

voidfunc wrote: post #28

laurent92 wrote: post #17

Earlier quoted context omitted.

“Java is a big DSL to transform XML into stacktraces” — so was the joke at the time when domain-specific languages were the hype. This, and the FizzBuzz, Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... More seriously, what are you missing in Go that is well-done in Java? I assume verbosity of the code is still the defining characteristic of Java?

> More seriously, what are you missing in Go that is well-done in Java? 1. Generics. And yea, I know Go is getting generics "Real Soon Now" (tm), but it is incredibly annoying to write the same collection code over and over and there's some third-party libs that would really benefit from generics (looking at you Azure Go SDK). 2. Error handling... with the big caveat that I actually like Go's error handling mechanism…

Much of the verbosity came from the false presumption that every field in every class needs a public getter and setter. (I cannot express in words how terrible this is.) Some can come from the framework, mostly poorly-designed ones.

I think Java 11 and higher are reasonably terse/expressive without being overly dense.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#79

Post by meddlepal » Thu, Apr 01, 2021, 6:56 PM UTC

avmich wrote: post #44

bcrosby95 wrote: post #42

Earlier quoted context omitted.

I guess it depends upon what you mean by ecosystem. Java the language is ok. The culture (which is part of the ecosystem) and how you're pushed to write code is the biggest problem with Java. The wide array of tooling, frameworks, and libraries within the ecosystem is nice. But the way you have to use them tends to be shit due to the culture surrounding the language. At least it seems to be shifting to something more…

Good language ought to discourage (enough) the bad practices. Culture forms slowly, and it's Java fault that the culture managed to produce such excessities as proverbial FactoryFactoryFactory. Edit: I still think Java is a good language, especially later versions, and both original goals and recent advances are quite noble.

I somewhat agree, but Java grew up in a different era when communication about these things wasn't as easy. It's hard to change the direction of something as large and widely deployed as Java. It's happening but it will take time and its always going to dealing with its legacy as there just so much of it out there.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#80

Post by Yeroc » Thu, Apr 01, 2021, 6:57 PM UTC

craigacp wrote: post #53

bluejekyll wrote: post #38

Earlier quoted context omitted.

Is there an update somewhere that I've missed? I keep looking for updates and haven't seen them. (And yes, I know it's a huge effort, I was definitely not trying to say that it should be an easy change to get into the language)

There are JEPs out for parts of it now - Primitive Objects (which is the new name for value types) https://openjdk.java.net/jeps/401 and Unify the basic primitives with objects https://openjdk.java.net/jeps/402

I haven't read up on the details of these but this is a huge step in the right direction if pulled off properly. The dichotomy between primitive and non-primitive types in Java is a real rough spot. I'd have to see how they deal with null values though because the introduction of auto-boxing certainly introduced a new area for NullPointerExceptions to catch the unwary off-guard.