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

Revisiting Java in 2021 – Part II

avanwyk.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: Revisiting Java in 2021 – Part II

#81

Post by ptx »

5e92cb50239222b wrote: post #77
jillesvangurp wrote: post #54

One point that the author fails to mention regarding Jetbrains is that they developed Kotlin and that Intellij at this point is largely implemented in it. Their whole strategy features a lot of Kotlin at this point. So, the best IDE for Java is built by the company that develops a drop in replacement for it. Not a minor point to make. The IDE that Oracle acquired along with Sun (Netbeans) is still there of course but…

IDEA is 56% Java and 15% Kotlin. https://github.com/JetBrains/intellij-community

Rider, their closed-source .NET IDE, is supposedly written in Kotlin though (except for the parts that are written in C#):

https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a...

Re: Revisiting Java in 2021 – Part II

#82

Post by Zababa »

daxfohl wrote: post #26

Changing companies led me from C# to Java. I feel so much less productive in Java, so much extra boilerplate everywhere. C# is just as mainstream as Java, so learning curves and nicheness arguments don't apply, it's just better. I wonder if MSFT will ever make C# run on JVM.

> C# is just as mainstream as Java, so learning curves and nicheness arguments don't apply, it's just better.

Java has way more web framworks from what I've seen (could be a good or bad thing), and more alternative languages that you can pick from.

Re: Revisiting Java in 2021 – Part II

#83

Post by ptx »

rnentjes wrote: post #71

Alternative way to count the vowels in Kotlin: val numVowels = countVowels(getDTO()?.string ?: "")

Or alternatively, closer to the original, doing both null checks the same way the original does the first one:

  val numVowels = getDTO()?.string?.let(::countVowels) ?: 0

Re: Revisiting Java in 2021 – Part II

#84

Post by twic »

javajosh wrote: post #66
papercrane wrote: post #56

Earlier quoted context omitted.

> A superficial reading might be that Oracle's JDK does not come with the GPL encumbrance. This is the whole point of the "classpath exception". You can run, build and distribute Java programs under any license you choose. > But this also raises the question: what differs between the various JDK builds? Very little typically. Some like RedHat or Amazon enable extra options, like the Shenandoah GC. The big difference…

How about this: what is "OpenJDK"? It used to be an independent open-source clone of the Sun-then-Oracle implementation of the JVM/JLS/JSR specs under a liberal license. Now it seems to mean something different - like a working group that manages the specs, but no longer has a build of it's own. By convention, it seems that Oracle's "OpenJDK build" is the "default" OpenJDK build, but Oracle also provides a "commercia…

> what is "OpenJDK"?

It is an open source project, comprising a codebase, a set of contributors, and various mailing lists, processes, and so on, just like any other open source project.

The codebase is a continuation of the original Sun (later Oracle) JDK, now licensed under GPL 2 [1], with a linking exception that makes it fairly similar to the LGPL [2].

The contributors are mostly employees of big companies, with Oracle having by far the largest share.

The OpenJDK project releases source code, but does not itself distribute binary builds. In this respect, it is like numerous other open source projects, such as GNU coreutils.

Binary builds are made and distributed by operating system distributors (Red Hat, Debian, FreeBSD, etc), and also by various independent groups. As usual, each distributor may or may not add its own patches before building, and may or may not contribute these upstream. Eclipse Adoptium (formerly known as AdoptOpenJDK) [1] does not apply significant proprietary patches (just branding stuff), so it's a good place to get a plain vanilla OpenJDK build. Amazon's Corretto [4] in principle could contain whatever patches Amazon thinks are cool, but in practice usually just has a few backported bugfixes [5]. Azul's Core (formerly known as Zulu) has a bunch of patches (i couldn't find a list), and an option of commercial support) [6]. Oracle have a couple of builds, but you can ignore them. There are also builds from SAP, Bellsoft, and maybe others, but i have never really looked into them. Most people i know just use the AdoptOpenJDK / Adoptium builds, or whatever their distro gives them.

EDIT: I got the Adoptium thing slightly wrong. AdoptOpenJDK made builds; those builds are now called Eclipse Temurin. Eclipse Adoptium is some sort of 'marketplace' where different builds are validated and made available. To me, this sounds like one of those Apache grand ideas that won't go anywhere, but we'll see.

[1] https://github.com/openjdk/jdk/blob/master/LICENSE

[2] https://opensource.stackexchange.com/questions/1410/what-is-...

[3] https://adoptium.net/releases.html

[4] https://aws.amazon.com/corretto/

[5] https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...

[6] https://www.azul.com/products/core/

Re: Revisiting Java in 2021 – Part II

#85

Post by Zababa »

hn_throwaway_99 wrote: post #16

I think when Project Loom comes out that Kotlin on top of the JVM will be a tough combo to beat. Kotlin is basically the language Java should be after 20 years of lessons learned, e.g. language-supported Optionals. The JVM is a battle tested platform. Once Project Loom comes out, you'll get the "best of both worlds" - the easier (i.e. "no functions 'colors'") programming model of multiple threads like in Java, but th…

Java seems to be heading for ML-like features while Kotlin is a "better Java". I think Kotlin lack a vision for the future, and might lose market share as Java itself gets better.

Re: Revisiting Java in 2021 – Part II

#86

Post by pjmlp »

Koshkin wrote: post #65
pjmlp wrote: post #52

Earlier quoted context omitted.

Only if they want to cripple C#, as the JVM isn't able to support all the C++ like features from C#.

It would still make sense, as long as when coding in the "crippled" C# one can still take advantage of the entire Java ecosystem.

You already have IKVM for that, with various degrees of success depending on the library.

Re: Revisiting Java in 2021 – Part II

#87

Post by lucian1900 »

daxfohl wrote: post #26

Changing companies led me from C# to Java. I feel so much less productive in Java, so much extra boilerplate everywhere. C# is just as mainstream as Java, so learning curves and nicheness arguments don't apply, it's just better. I wonder if MSFT will ever make C# run on JVM.

There’s IKVM for running Java libraries in .NET.

Re: Revisiting Java in 2021 – Part II

#88

Post by twic »

javajosh wrote: post #73
twic wrote: post #69

Earlier quoted context omitted.

The licensing around post-8 JVMs is neither confusing nor scary. If you're confused or scared by it, that is entirely on you, i'm afraid.

Great, then explain it.

It's GPL 2, with an exception which lets you distribute binaries containing your own code linked to the JDK without having to provide the source to your own code (see '"CLASSPATH" EXCEPTION TO THE GPL' at the end):

https://github.com/openjdk/jdk/blob/master/LICENSE

This is substantially the same as the GCC Runtime Library Exception, which lets you distribute GCC-compiled binaries linked to the GCC runtime without having to provide the source.

That's it.

Re: Revisiting Java in 2021 – Part II

#89

Post by 5e92cb50239222b »

ptx wrote: post #81
5e92cb50239222b wrote: post #77

Earlier quoted context omitted.

IDEA is 56% Java and 15% Kotlin. https://github.com/JetBrains/intellij-community

Rider, their closed-source .NET IDE, is supposedly written in Kotlin though (except for the parts that are written in C#): https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a...

Rider is pretty much IDEA customized for dotnet. Code analyzer/autocompletion backend is written in C# running on top of .NET (5 IIRC). I am not affiliated with JetBrains in any way and have no visibility into its internals, but am pretty sure that Rider and IDEA share most of the code (which is obvious to anyone who has spent significant amounts of time in both IDEs).

Re: Revisiting Java in 2021 – Part II

#90

Post by geokon »

1 -

I just do some Clojure programming, and I'm not deep into JVM things - but why does Android not even make a mention? Isn't it the most widely used JVM platform..?

2 -

> This does come with some restrictions and caveats; for example, it's not as straightforward to use Reflection in your Java code.

Is GraalVM going to push Reflections out of Java/JVM?

I guess my angle is I'd like to use the JVM to make (desktop) apps. Last I did, using cljfx/JavaFX reflections were a huge sore point. Ever dependency would drag in the whole kitchen sink - and reflections are an ugly wart that prevent unused classes/namespaces from being pruned.

I know technically there is Proguard.. but it's clunky and ugly I've never gotten it to work with Clojure. Graal native looked like a sort of light at the end of the tunnel.

3-

Whats the story with WASM and the JVM? Both designs seem eerily similar - but I don't know if the gap between the two is too large to bridge

Post reply on HN