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

91–100 of 146 posts

Re: Revisiting Java in 2021 – Part II

#91

Post by gozzoo »

smallerfish wrote: post #67
vbezhenar wrote: post #61

Earlier quoted context omitted.

I'm personally interested in reducing RAM consumption. Right now Spring Boot application with very little functionality (like few REST endpoints, talking to database) easily eats few hundreds of megabytes RAM. Similar node.js application eats few dozens of megabytes RAM. Cost of using Java is high, when there are plenty of those services, especially when we're talking about resilient services and launching 2-3 instan…

To be fair, that's spring boot. It's a bloated ecosystem. If you write using lean libraries (which you'd want to do for lambda anyway) then you're looking at 0.1-0.3s jvm startup times. If that's supposed to be serving a user then it may be taking too long, but in that case use an EC2 instance rather than trying to be serverless.

what woud be a lean alternative for microservices to spring boot?

Re: Revisiting Java in 2021 – Part II

#92

Post by javajosh »

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…

The biggest real-world benefit of Kotlin is nullity prevention and immutables (of which Optional is a corollary).

It's not clear whether Loom will be a big hit. Personally, I think the Actor model is the best application level concurrency "primitive", and Loom is just about fibers & continuations, both of which are parts of Actors but aren't really Actors themselves.

Re: Revisiting Java in 2021 – Part II

#94

Post by StevePerkins »

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…

> How about this: what is "OpenJDK"? It used to be an independent open-source clone

Please educate yourself before spreading misinformation on this forum.

OpenJDK is not a "clone", a "fork", or some other re-implementation of the Oracle JDK. It's the other way around. OpenJDK IS the source code for the Java Virtual Machine and standard library. All binary distributions are based on this source.

Some binary distributions are freely available. Others include additional proprietary tools, or commercial support or whatever, and require paid licensing. But these all derive from the some common upstream.

You are painting a picture that is equivalent to saying that the Linux source code is a "clone" of RedHat Enterprise Linux. That is not accurate whatsoever.

Re: Revisiting Java in 2021 – Part II

#95

Post by javajosh »

twic wrote: post #84
javajosh wrote: post #66

Earlier quoted context omitted.

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…

Yes, that all seems so trivial a small child could understand it. So what's my problem?! /s

But seriously, you don't see how this might be confusing? And what you've described is really only the tip of the iceberg. Who defines the specs? Who writes the compliance tests with the specs? Who runs those and certifies that implementations are compatible? What limits are there on entities that make builds, either on the patches they can apply (and still call it "Java") or the licenses they can adopt? What does "GPL with classpath exception" mean in the real world, that JDK-itself changes must be upstreamed, but linked applications need not be? What are the limits there?

The point is, getting an open source JDK binary is not easy, especially if you want to understand what you're getting. "OpenJDK" may exist as an OSS project, but I wouldn't call it typical. Not because it doesn't release binaries (although I just discovered it does, provided by Oracle for Windows/Linux only), but because of the license, the owner, and the owner's relationship to binary builders. The binaries you can get in practice have unknown additions from the vendor, and possible adjustments to the license (or is only Oracle allowed to make alternative licenses for an OpenJDK build?)

Compare java distribution to, say, node or python. Is it really fair to accuse someone who is confused of being an idiot?

Re: Revisiting Java in 2021 – Part II

#96

Post by karussell »

geokon wrote: post #90

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) ap…

Android is not a JVM platform. Android uses Dalvik as VM.

Re: Revisiting Java in 2021 – Part II

#97

Post by javajosh »

twic wrote: post #88
javajosh wrote: post #73

Earlier quoted context omitted.

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 hav…

Thanks. During this discussion I found the OpenJDK source code, cloned the repo, and build a fully-functional JDK [1]. Presumably the license forces me to share modifications to the JDK code itself, but not to any application I run on the JDK.

If I wanted to distribute my JDK (I don't, BTW) what limits are there? Do I need to get certified? Run compatibility tests? Pay a fee to Oracle? Or do I just need to plop a binary on Github or S3 and call it a day?

1 - https://openjdk.java.net/groups/build/doc/building.html

Re: Revisiting Java in 2021 – Part II

#98

Post by AmpsterMan »

geokon wrote: post #90

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) ap…

Afaik, android has its own VM. It compiles Java the language into bytecode for that VM. Android didn't even include the standard Java library, instead providing its own.

Re: Revisiting Java in 2021 – Part II

#99

Post by javajosh »

CraigJPerry wrote: post #25
da39a3ee wrote: post #5

> There are ... many well-written books on how to program it effectively Would anyone be able to recommend a good resource for quickly learning modern Java for experienced programmers that already know, let's say, one of {Python,Javascript} AND one of {Go,Rust,C,C++}, but have zero JVM experience? (Ideally the resource would also teach some relevant things about the JVM itself rather than the Java language specifical…

I'd be surprised if you found any dramas with the language. What will keep you in the office to all hours is the ecosystem. Now the ecosystem is probably best in class so don't mistake this as a slight, but it's huge and complex. Learning Gradle (or Maven), understanding how to make building java apps fast (because the default is slow package assembly times), learning some of the large frameworks (if you go down that…

I forgot where I read this, but I think it's true: With Gradle to do anything you have to understand everything.

(Not a fan of Gradle)

Re: Revisiting Java in 2021 – Part II

#100

Post by Symbiote »

sorokod wrote: post #68
sk5t wrote: post #38

Earlier quoted context omitted.

> I think if the Scala creators had been a bit less obsessed with symbology This might not be something to pin on the language designers, if you're using certain third-party libraries. Indeed it is possible to name a method pretty much whatever you want, with some constraints[0]. Wanna call it "!^"? Go ahead! But, this is afoul of the naming convention in many cases[1]--acknowledging that the convention may have prev…

A house is leaking from the roof. If the language designers allow methods named "!^", then someone will actually name a method "!^".

Most languages allow a variable called "i", but it is for the programmer to choose when that is appropriate.

!^ might be useful, if the code implements an algorithm which uses this notation in the literature.

Post reply on HN