Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

advancedweb.hu

Post reply on HN
Print view View original

181–190 of 243 posts

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

#181

Post by DaiPlusPlus »

ragnese wrote: post #163
The_rationalist wrote: post #158

Earlier quoted context omitted.

Kotlin is the application language you're looking for (and Scala 3 to a lesser extent). Contrary to what you say it is the best language I've ever used for concurrency. It has it all, structured concurrency, cancelation, Flow, transparency (no await), etc. Regarding your second point the JVM is increasingly using the stack and with the soon complete generics you'll be able to avoid the boxed versions of the primitive…

> Contrary to what you say it is the best language I've ever used for concurrency. It has it all, structured concurrency, cancelation, Flow, transparency (no await), etc. I disagree. Have you ever tried to actually implement something non-trivial that takes advantage of structured concurrency with cancellation? It's pretty hard to do correctly. Can you really tell me off the top of your head what the difference is be…

> I'll admit that I have a glaring experience gap with .NET languages, so I can't honestly say anything about C# and F#.

C#/.NET comes with language-level mutexes (`lock`) and the .NET library has thread-safe generic collections (ConcurrentDictionary, ConcurrentBag) and true immutable collections (ImmutableArray, ImmutableList, ImmutableDictionary) with optimized copy operations (e.g. ImmutableList.Add is O(1), but ImmutableArray.Add is O(n)). It's a nice addition to the library with only a few warts.

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

#182

Post by DaiPlusPlus »

int_19h wrote: post #151
DaiPlusPlus wrote: post #113

Earlier quoted context omitted.

It surprises me that we don’t yet have an applications language with an ultra-modern type-system. It’s so strange that the current leaders are a scripting-transpiler (TypeScript) and a systems language (Rust) - but not an apps language in-between. ...then again it’s understandable when you see how the traditional apps languages (C#, Java, etc) are severely hobbled by their VM/runtime, because that’s usually the sourc…

The situation is changing in the CLR land, now that they can just say that legacy codebases can stay on .NET 4.x, and .NET Core is where all the fancy development is happening. There are already some C# language features that are Core-only because they require the corresponding runtime changes. The other thing is - people always forget that, unlike JVM, CLR has more than just the object layer. By design, it has enoug…

> By design, it has enough low-level constructs to compile a language like C++, complete with multiple inheritance, unions, varargs etc

But the CLR doesn't support that. If you compile C++ code to IL then you'll get a compiler error if you use any types that use multiple-inheritance. The CLR's underlying type system is a huge limitation when it comes to using even simple modern ADTs.

For example, in F# you can define a union type, and the union subtypes can contain normal library types, but you cannot define a library type as a union subtype, whereas you can in TypeScript (and Rust too, I think?).

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

#183

Post by oftenwrong »

srparish wrote: post #149
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?

Verbosity of code is more of a go thing these days: hasThing := false for _, v := range stuff { if checkForThing(v) { hasThing = true break } } if !hasThing { return false } Java: if !stuff.stream().anyMatch(v -> checkForThing(v)) { return false; } In the 2020s, loops are the new "goto", too much boiler-plate and ways to subtly be incorrect, much safer to use higher-level collection methods.

    return stuff.stream().anyMatch(this::checkForThing)

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

#184

Post by BenoitP »

gher-shyu3i wrote: post #139
jacques_chester wrote: post #14

Earlier quoted context omitted.

I am unreasonably excited by Loom, for two reasons: 1. I cannot wrap my head around library-based reactive systems. I have tried and tried and continue to try. But they're like some of the original Go4 design patterns: they exist to solve the language , not the problem . Loom's promise to make steam-powered linear code behave mostly like a fully-dressed reactive library system is extremely welcome. 2. Structured conc…

What do you mean by structured concurrency? Do you mean hierarchy management?

Sort of. Here is the original proposal often referred to by Loom's architects:

https://250bpm.com/blog:71/

Here is what the wiki has to say:

https://wiki.openjdk.java.net/display/loom/Structured+Concur...

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

#185

Post by kaba0 »

harshalizee wrote: post #124
pimlottc wrote: post #91

I’ve always admired Java for managing to slowly but surely move the language forward while maintaining backwards compatibility and keeping the community together. When you look at how many other languages have faltered and lost momentum due to transition issues (Perl 6, Python 2/3), it really shows have difficult of a task it is. Progress can seem glacially slow at times - it’s always disappointing to see your favori…

I would add C# to the list of languages with good backward compatibility and progression with every new version. Very similar to Java, and has a lot more feature set with somewhat decent documentation.

I’m not sure how true it is, but haven’t been some quite great breaking changes with .NET core, .NET, I don’t even now where they are now.

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

#186

Post by kaba0 »

titzer wrote: post #167

I was programming in Java before generics came out. While generics were a very big upgrade, it was such a disastrous mistake to go for type erasure, because Java has a bifurcated type system. As we all well know, you can't be generic over a primitive type, for exactly this reason. I knew then and have minefield-of-rakes stumbled my way through every single consequence of that decision and still think it was wrong. Th…

I believe the current generics was a first step, because making it a language feature was really important at the time. The second, harder step is this one: https://old.reddit.com/r/java/comments/m2dfb5/parametric_jvm...

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

#187

Post by thu2111 »

kaba0 wrote: post #185
harshalizee wrote: post #124

Earlier quoted context omitted.

I would add C# to the list of languages with good backward compatibility and progression with every new version. Very similar to Java, and has a lot more feature set with somewhat decent documentation.

I’m not sure how true it is, but haven’t been some quite great breaking changes with .NET core, .NET, I don’t even now where they are now.

Yeah, .NET is an odd choice to praise for backwards compatibility.

.NET 1 -> .NET 2 was iirc a total break due to the integration of generics, amongst other things. Source code had to be rewritten.

.NET Framework -> .NET Core was another total break. Lots of .NET code that worked on Framework didn't run on Core at all and had to be ported to different library or required other changes.

The fact is, the .NET world has made moves that obsoleted lots of prior code several times. Java never has, unless you count the various boulders rolled down the hill at people using JVM internal APIs.

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

#188

Post by thu2111 »

carimura wrote: post #125
pimlottc wrote: post #91

I’ve always admired Java for managing to slowly but surely move the language forward while maintaining backwards compatibility and keeping the community together. When you look at how many other languages have faltered and lost momentum due to transition issues (Perl 6, Python 2/3), it really shows have difficult of a task it is. Progress can seem glacially slow at times - it’s always disappointing to see your favori…

A big benefit of the 6-month release cadence (since Java 10) is that if your favorite feature gets pushed, the next release is just around the corner.

Well, kind of. In practice despite the faster release schedule quite a few features have been in incubation for years. Most features that people could identify as favorite have been talked about for nearly 5 years now and are still not targeted to get a stable API yet.

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

#189

Post by thu2111 »

bluejekyll wrote: post #3

One of the primary features I'm holding out hope for eventually making it into the language is ValueTypes: http://cr.openjdk.java.net/~jrose/values/values-0.html and the current Valhalla Project: https://wiki.openjdk.java.net/display/valhalla/Main The simplest example of why this would be valuable (edit: this was not an intentional pun), the Optional type could become stack based, such that you could ensure that the…

I'm looking forward to Valhalla too, but I think it won't be as impactful as people think. In particular that use case is a poor fit for Valhalla and I don't think Optional will be widely adopted even post-value types. The intent here is to mark which parameters and return types can be null. A laudable goal. However:

1. You will still be using many, many libraries that pre-date cheap Optional. For those, the lack of Optional will NOT indicate the value is always present, it will mean "no optionality information available". Therefore by looking at an API you can't actually tell what the lack of Optional means: it could be deliberate, or it could be legacy. This will make the signal useless.

2. Optional is a very verbose, heavyweight syntax for handling optionality. Therefore some developers will not use it on the grounds that Java is already a very verbose language and it really doesn't need more. This will cause further divergence.

3. Many developers will want to preserve compatibility with old JVMs. Even though Optional is around a long time now, guaranteed cheap/fast Optional will take a long time to roll out and may never make it to Android at all. This will cause some library developers writing high performance code to shun it because null is as cheap as you can possibly get, and universally supported. Again, the lack of Optional will be meaningless.

4. The killer blow: adding Optional changes your function signatures and therefore breaks both binary and source compatibility. Many library developers want to keep a backwards compatible API, or are required to, and that includes for example the Java standard libraries. Therefore lack of Optional will NEVER mean "guaranteed to be present" in most Java code because the standard library won't use it that way.

There is a far, far better way to handle this and it's what Kotlin did:

1. Integrate optionality into the language using lightweight syntax and type inference.

2. Use non-denotable flex-types at the edges, so missing optionality information is added transparently in the source code the first time a developer specifies a type explicitly.

3. Allow annotations to provide nullability information, preserving source and binary compatibility. Integrate it with IDE and compiler data flow analysis. IntelliJ already does this and you can make nullability violations hard errors today by adjusting your project preferences.

4. Finally, allow third party libraries that aren't being changed to be annotated using external annotation files.

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

#190

Post by thu2111 »

jacques_chester wrote: post #33
KptMarchewa wrote: post #26

Earlier quoted context omitted.

What's the difference in programming model (not implementation) between Loom and goroutines?

Briefly, that a thread cannot escape a scope. All threads must be joined before leaving the scope. Some resources: https://wiki.openjdk.java.net/display/loom/Structured+Concur... https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.... https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

Not exactly. That's the programming rule for structured concurrency which is a very simple bit of logic added on to the ExecutorService class. Loom itself is just about making threads super cheap/fast. You can use new cheap threads in exactly the same way as normal and nothing will complain. You can also use structured concurrency with old threads, and again, nothing will complain. And you don't need Java support for structured concurrency. You could implement it today with some wrapper classes.
Post reply on HN