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

The Road to Valhalla

cr.openjdk.java.net

Post reply on HN
Print view View original

61–70 of 82 posts

Re: The Road to Valhalla

#61

Post by phillipcarter »

pron wrote: post #42
BoorishBears wrote: post #30

Earlier quoted context omitted.

>Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes. That's exactly what's wrong with Java. That's why we got "functional interfaces" instead of proper l…

Whether that's "wrong" or "right" is a matter of opinion. But it's hard to argue with the fact that many more people seem to prefer Java's approach to Microsoft's. As to .NET's "insane under the hood" innovation, the platform is similar to what Java was about 10-15 years ago in terms of GC, JIT compilation and monitoring. .NET prefers changing the language, while Java prefers changing the platform. The two just have…

I’d recommend spending some more time with .NET Core and comparing its performance characteristics (as of .NET Core 3.1). I think you’ll find it compares quite favorably, with recent advances like Span making a big difference. While it’s accurate to say the CLR has been behind on the desktop for a long while, the rekindled effort around advancing the runtime in .NET Core has paid off in spades and has only really just begun. It sounds like your impression is rooted in the desktop CLR, which is effectively frozen for compatibility reasons.

Re: The Road to Valhalla

#62

Post by BoorishBears »

pron wrote: post #60
BoorishBears wrote: post #58

Earlier quoted context omitted.

Ugh, I started reading this before I realized it's the same person who thinks C#'s under the hood improvements in the last decade can be handwaved away. Yeah, 10% of Java's market share is not larger than C# https://stackify.com/popular-programming-languages-2018/ If it was, those languages would be showing up on Github's survey above C# as well, they all consider Java independently not as a combination of all JVM la…

Because Java is both the name of a platform and the name of a language for that platform, and from its original design, the platform has been the main focus. Clojure, Kotlin and the Java language are all Java platform languages. And you'll just have to come to terms with the objective fact that other developers might disagree with your subjective language preferences. In fact, statistics would suggest that most of th…

Ugh, no Java is not the same the Java Virtual Machine, no one calls them by the same name, no one is confusing those but you.

When Github says your project has Java they don't mean your project has Clojure or JRuby.

When Tiobe says Java has X market share they don't mean JVM does.

They are not Java platform languages, they are JVM platform languages.

If you can't even talk about this using simple base definitions of the two languages that I've literally never seen argued against until today, it only compounds why I said having this conversation with you is not worth my time.

Re: The Road to Valhalla

#63

Post by pron »

phillipcarter wrote: post #61
pron wrote: post #42

Earlier quoted context omitted.

Whether that's "wrong" or "right" is a matter of opinion. But it's hard to argue with the fact that many more people seem to prefer Java's approach to Microsoft's. As to .NET's "insane under the hood" innovation, the platform is similar to what Java was about 10-15 years ago in terms of GC, JIT compilation and monitoring. .NET prefers changing the language, while Java prefers changing the platform. The two just have…

I’d recommend spending some more time with .NET Core and comparing its performance characteristics (as of .NET Core 3.1). I think you’ll find it compares quite favorably, with recent advances like Span making a big difference. While it’s accurate to say the CLR has been behind on the desktop for a long while, the rekindled effort around advancing the runtime in .NET Core has paid off in spades and has only really jus…

I'm sure it has, but in the meantime Java is making great strides as well on multiple important fronts -- low-latency GCs, a next-gen JIT, AOT compilation, native ffi, low-overhead in-production profiling and lightweight concurrency, and the main problem with Microsoft's technologies remains that they break compatibility every five-six years or so. Now it's .NET Core, and it wouldn't be a bad bet to guess that in five years it will be something else. We're at a point where it's so hard to make changes with a big bottom-line impact (arguably there weren't too many such advances in the past twenty years) that very few actually justify breaking compatibility, and companies know that. So while smaller software can afford switching from one technology to the other, big "important" stuff requires a compatibility lifespan of at least ten if not fifteen years, something that Microsoft has never been good at. It's possible that with their focus shifting more to the backend with their cloud offering that would change, but it appears that their cloud strategy is to support all software platforms rather than focus on their own. That's why we see Microsoft now hiring engineers, as well as getting some CLR engineers, to contribute to Oracle's OpenJDK [1].

[1]: https://mail.openjdk.java.net/pipermail/discuss/2019-October...

Re: The Road to Valhalla

#64

Post by pron »

BoorishBears wrote: post #62
pron wrote: post #60

Earlier quoted context omitted.

Because Java is both the name of a platform and the name of a language for that platform, and from its original design, the platform has been the main focus. Clojure, Kotlin and the Java language are all Java platform languages. And you'll just have to come to terms with the objective fact that other developers might disagree with your subjective language preferences. In fact, statistics would suggest that most of th…

Ugh, no Java is not the same the Java Virtual Machine, no one calls them by the same name, no one is confusing those but you . When Github says your project has Java they don't mean your project has Clojure or JRuby. When Tiobe says Java has X market share they don't mean JVM does. They are not Java platform languages, they are JVM platform languages. If you can't even talk about this using simple base definitions of…

As I said, I work on OpenJDK, and the JVM constitutes less than 25% of the Java platform software (JDK). The Java language constitutes about 2% of the codebase, and Kotlin and Clojure make use of over 95% of it. They use the JVM, the Java core libraries (thanks to erased generics), and the selection of Java's debugging, profiling and monitoring tools that make up the JDK (not to mention their extensive use of third-party Java ecosystem libraries that aren't a part of the core platform). They are most definitely Java platform languages (although they're not only Java platform languages; e.g. Kotlin is also an Android language), even if colloquially many refer to the platform as "the JVM" although the JVM is only a small, yet obviously very important, part of it. Java is the name of both a programming language and the platform it is part of, and sometimes, for the sake of brevity, I too would refer to the platform as "the JVM." But as someone working on Java (not so much the language, but the platform), I try to use the more precise, more correct terminology, and I guess I'll just have to try and live with your dismay.

Re: The Road to Valhalla

#65

Post by phillipcarter »

pron wrote: post #63
phillipcarter wrote: post #61

Earlier quoted context omitted.

I’d recommend spending some more time with .NET Core and comparing its performance characteristics (as of .NET Core 3.1). I think you’ll find it compares quite favorably, with recent advances like Span making a big difference. While it’s accurate to say the CLR has been behind on the desktop for a long while, the rekindled effort around advancing the runtime in .NET Core has paid off in spades and has only really jus…

I'm sure it has, but in the meantime Java is making great strides as well on multiple important fronts -- low-latency GCs, a next-gen JIT, AOT compilation, native ffi, low-overhead in-production profiling and lightweight concurrency, and the main problem with Microsoft's technologies remains that they break compatibility every five-six years or so. Now it's .NET Core, and it wouldn't be a bad bet to guess that in fiv…

> something that Microsoft has never been good at

Well, you're certainly entitled to that opinion :)

As I said, I encourage you to explore .NET Core and its recent advances, especially now that the big runtime improvements made in recent years have proliferated throughout the standard library and new language features. While it's fair (and correct) to say that the Java runtime is ahead due to many years of focused improvements, I think you'll find the difference quite a bit smaller than it was back when .NET was focused mainly on Windows desktop software.

Re: The Road to Valhalla

#66

Post by pjmlp »

BoorishBears wrote: post #59
pjmlp wrote: post #56

Earlier quoted context omitted.

So when are we getting F# designers in Visual Studio?

Are you confusing IDE support with language support on a given runtime?

If you want me to talk about language support on a given runtime instead, try to use F# on .NET Native, or VB.NET on Blazor.

Re: The Road to Valhalla

#67

Post by pron »

phillipcarter wrote: post #65
pron wrote: post #63

Earlier quoted context omitted.

I'm sure it has, but in the meantime Java is making great strides as well on multiple important fronts -- low-latency GCs, a next-gen JIT, AOT compilation, native ffi, low-overhead in-production profiling and lightweight concurrency, and the main problem with Microsoft's technologies remains that they break compatibility every five-six years or so. Now it's .NET Core, and it wouldn't be a bad bet to guess that in fiv…

> something that Microsoft has never been good at Well, you're certainly entitled to that opinion :) As I said, I encourage you to explore .NET Core and its recent advances, especially now that the big runtime improvements made in recent years have proliferated throughout the standard library and new language features. While it's fair (and correct) to say that the Java runtime is ahead due to many years of focused im…

I believe you re .NET Core, but I think that Microsoft shifting their focus to a backward-incompatible development platform (not Windows, on which they have a very good compatibility record) every five years or so is more than just opinion. I think that their record on that front speaks for itself. If you were a developer who always uses the current flagship MS development platform to develop a piece of software that you first wrote in 1999, by now you'd be on your fourth significant rewrite. TBF, Java also made one such misstep, with JavaFX Script in 2009, but that was corrected and reverted.

Re: The Road to Valhalla

#68

Post by BoorishBears »

pron wrote: post #64
BoorishBears wrote: post #62

Earlier quoted context omitted.

Ugh, no Java is not the same the Java Virtual Machine, no one calls them by the same name, no one is confusing those but you . When Github says your project has Java they don't mean your project has Clojure or JRuby. When Tiobe says Java has X market share they don't mean JVM does. They are not Java platform languages, they are JVM platform languages. If you can't even talk about this using simple base definitions of…

As I said, I work on OpenJDK, and the JVM constitutes less than 25% of the Java platform software (JDK). The Java language constitutes about 2% of the codebase, and Kotlin and Clojure make use of over 95% of it. They use the JVM, the Java core libraries (thanks to erased generics), and the selection of Java's debugging, profiling and monitoring tools that make up the JDK (not to mention their extensive use of third-p…

I can't believe you work on the OpenJDK and are trying to intentionally confuse the JVM and Java.

tsk tsk.

Re: The Road to Valhalla

#69

Post by ljackman »

billfruit wrote: post #28
ljackman wrote: post #12

While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…

While that is interesting to hear, is there a single book that brings someone who hasn't used Java in the last 5 years upto speed, like the book Bjarne Stroustroup's 'A tour of c++' does for c++.

There might be, but unfortunately I don't know it. I learnt Java initially from the first edition of Just Java, read from various other sources about the 1.5 and 1.6 additions it didn't cover, and then learned new features from OpenJDK proposals from 1.7 onwards as they were released.

The biggest impact of the 5 years for working developers has probably been:

* Streaming API and lambdas allowing usual `map`/`filter`/`reduce` transformation pipelines line many other languages (lazy, unlike JS's `Array` methods, parallelism considered via "spliterators" unlike Python).

* Default methods in interfaces, _not_ making them traits, but arguably more "trait-like". It allowed them to add many useful methods onto existing types without needing bifurcate the common APIs.

* A REPL. Probably not a big deal for a professional developer, who likely uses IntelliJ's "Evaluate Expression" feature already for a similar feature, but pretty useful for education I guess.

* Better at being stuffed inside Docker containers with resource limits. Also, max permgen space no longer a problem really (it's where you had to set an upper memory limit when invoking Java programs, which was annoying). Just generally less annoying at being deployed in modern infrasructures.

* APIs like `File.lines` that mean you don't need to recite War and Peace just to do a buffered operation across lines in a file. Generally more ergonomic APIs that finally make basic operations sane.

* Type inference with `var`. Basically the same as C#'s `var` or Go's `:=`.

* More native executable-producing tooling. jlink, jpackager, etc. The dream of ubiquitous, shared Java runtimes installed everywhere didn't really work out, and they seem to have realised that.

* Ecosystem moving away from XML. Still there, just less common. Runtime annotations are used more heavily, which I'm honestly not sure is a massive improvement. Hopefully more lambda-heavy APIs will reduce use of runtime annotations; see Spring WebFlux's functional handlers for annotation-based controllers for a comparison.

There's a lot more, but I'd argue it won't be as immediately visible for the working developer more than those points. Modules were important for the ecosystem, but most devs probably aren't worrying about that day-to-day. Gradle and Maven still dominate the building/packaging side.

Re: The Road to Valhalla

#70

Post by pron »

BoorishBears wrote: post #68
pron wrote: post #64

Earlier quoted context omitted.

As I said, I work on OpenJDK, and the JVM constitutes less than 25% of the Java platform software (JDK). The Java language constitutes about 2% of the codebase, and Kotlin and Clojure make use of over 95% of it. They use the JVM, the Java core libraries (thanks to erased generics), and the selection of Java's debugging, profiling and monitoring tools that make up the JDK (not to mention their extensive use of third-p…

I can't believe you work on the OpenJDK and are trying to intentionally confuse the JVM and Java. tsk tsk.

Well then, I guess I'm going to have to learn to live with your disbelief as well.

Java is the name of both a software platform as well as a programming language for that platform. Languages that target that platform are often called "JVM languages," but really they make use of almost all of Java (the platform) rather than just the JVM (although that degree varies: Kotlin makes use of the platform almost as much as the Java language; Clojure makes use of somewhat less, yet more than Scala or Ceylon).

http://openjdk.java.net/

https://docs.oracle.com/en/java/javase/13/docs/specs/index.h...

https://en.wikipedia.org/wiki/Java_(software_platform)

Post reply on HN