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

61–70 of 146 posts

Re: Revisiting Java in 2021 – Part II

#61

Post by vbezhenar »

smallerfish wrote: post #47
vbezhenar wrote: post #3

Thanks for article. Today I learned about Project Leyden, whose primary goal will be to address the long-term pain points of Java’s slow startup time, slow time to peak performance, and large footprint. I just recently started to explore Quarkus, GraalVM to optimize Java microservices for cloud architecture. It's good to know that Java moves into that direction. https://mail.openjdk.java.net/pipermail/discuss/2020-Ap…

> to optimize Java microservices for cloud architecture I'm kind of curious about this. What kind of lifetimes are you looking at for JVMs? Are you trying to use Java in lambdas on demand to user requests? What kind of warmup time are you seeing right now?

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 instances of every service.

Fast startup time is just a good bonus.

That's for my use-case. Lambdas, obviously, demand fast start-up.

Re: Revisiting Java in 2021 – Part II

#62

Post by javajosh »

boulos wrote: post #55
StevePerkins wrote: post #40

Earlier quoted context omitted.

I just don't buy this at all. Unless you're talking about a seed-round startup, where the C-levels are all 20-something year old frat bros straight out of college. No remotely competent CTO or CIO in any halfway respectable enterprise is still going to be confused about Java licensing in 2021. The only people I EVER encounter with any confusion around Java licensing are students, entry-level devs, and people from oth…

Hmm. Without Corretto, which is "recent", I don't see how your argument holds. "No" seed stage company is going to use something from Azul, and probably not from "regular" IBM either (that is, exempting RedHat). Without Corretto, I think Oracle really has poisoned the well. [1] https://aws.amazon.com/corretto/

It's particularly confusing because "OpenJDK" used to be an independent group who's purpose was to build a fully open-source Java - and it was Apache licensed. Now, it seems that "OpenJDK" refers to a specification and/or working group which NO LONGER provides a build, instead relying on vendors to do so, and indeed the vendors have wide latitude about how they license it.

This is genuinely complicated, I'm not a lawyer or a software license expert, and I don't understand it. And honestly, based on some of the haughty and arrogant, but factually wrong, comments I've been seeing, I suspect that a lot of people think they understand it, but don't.

Re: Revisiting Java in 2021 – Part II

#63

Post by Zababa »

nerdponx wrote: post #29
dboreham wrote: post #14

The comments about Scala resonated. I've been working in a a large Scala codebase for the past few months. I've become a partial fan of the language, however: there have been multiple conversations like : (in screen share with colleague) "See that double right arrow there? What's that mean? (after attempts to find answer in books, SO, etc, and trying to guess based on the three/four other uses the language makes of d…

If you can't use an IDE to jump to the definition (or list all possible definitions) of a function, then aren't you missing one of the main benefits of a statically-typed language? If you can't use the static types for static analysis, what's the point?

Jump to definition is only one part of static analysis. Typechecking is another, performance is a third one.

Re: Revisiting Java in 2021 – Part II

#64

Post by hugi »

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…

Kotlin's dependency and relationship with IntelliJ is one of the largest reasons why I don't use it. I really dislike IntelliJ and Kotlin is mostly unusable without it.

I don't see why I should force my company into vendor lock-in (IntelliJ/Kotlin) on what is otherwise an open platform (Java/OpenJDK).

Re: Revisiting Java in 2021 – Part II

#65

Post by Koshkin »

pjmlp wrote: post #52
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.

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.

Re: Revisiting Java in 2021 – Part II

#66

Post by javajosh »

papercrane wrote: post #56
javajosh wrote: post #48

Earlier quoted context omitted.

Ignoring the ad hominem attacks, I appreciate your attempt to clarify the situation. However, you are factually wrong about Oracle's position, because they actually offer two different builds of Java - one that is GPL'd (with classpath exception) and one that is commercial[1]. I take the first claim seriously because it's downloadable as a tar.gz file without any license acceptance. However "GPL" is another thing tha…

> 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 "commercial build", which is also, confusingly, an implementation of "OpenJDK".

Meanwhile other vendors have "OpenJDK" builds: Amazon (corretto), Red Hat, etc. This means that they offer binaries that implement the OpenJDK specs.

My mental model is currecntly: So there's a spec and an implementation, OpenJDK can refer to both, and a vendor can have multiple implementations of OpenJDK (spec), and some of impls can be closed/commercial, as in the case of Oracle (and maybe Red Hat?).

Re: Revisiting Java in 2021 – Part II

#67

Post by smallerfish »

vbezhenar wrote: post #61
smallerfish wrote: post #47

Earlier quoted context omitted.

> to optimize Java microservices for cloud architecture I'm kind of curious about this. What kind of lifetimes are you looking at for JVMs? Are you trying to use Java in lambdas on demand to user requests? What kind of warmup time are you seeing right now?

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.

Re: Revisiting Java in 2021 – Part II

#68

Post by sorokod »

sk5t wrote: post #38
dboreham wrote: post #14

The comments about Scala resonated. I've been working in a a large Scala codebase for the past few months. I've become a partial fan of the language, however: there have been multiple conversations like : (in screen share with colleague) "See that double right arrow there? What's that mean? (after attempts to find answer in books, SO, etc, and trying to guess based on the three/four other uses the language makes of d…

> 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 "!^".

Re: Revisiting Java in 2021 – Part II

#69

Post by twic »

javajosh wrote: post #7

I use Java every day, but we're stuck with Java 8 because of the confusing and frankly scary licensing around later JDKs. I would love to move to 17 but I need something to show to the C-levels that gives them warm and fuzzies around the license. Does such a thing exist? EDIT: I find it quite depressing that so many want to attack people for being confused around Java licensing. I submit that it is confusing on its f…

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.

Re: Revisiting Java in 2021 – Part II

#70

Post by boulos »

javajosh wrote: post #62
boulos wrote: post #55

Earlier quoted context omitted.

Hmm. Without Corretto, which is "recent", I don't see how your argument holds. "No" seed stage company is going to use something from Azul, and probably not from "regular" IBM either (that is, exempting RedHat). Without Corretto, I think Oracle really has poisoned the well. [1] https://aws.amazon.com/corretto/

It's particularly confusing because "OpenJDK" used to be an independent group who's purpose was to build a fully open-source Java - and it was Apache licensed. Now, it seems that "OpenJDK" refers to a specification and/or working group which NO LONGER provides a build, instead relying on vendors to do so, and indeed the vendors have wide latitude about how they license it. This is genuinely complicated, I'm not a law…

Which is exactly your point! The uncertainty/confusion is now super high due to Oracle's actions. It's literally fear, uncertainty, and doubt.

It's a bit like GPL and other open source licensing in the early days ("better not touch GPL code at all") rather than the now commonplace "Ahh, yes. No to AGPL, but GPL is fine since we won't distribute it. We'd prefer APL" practices.

I absolutely believe that experts in licensing understand the OpenJDK / Corretto / Microsoft's OpenJDK distro and so on. But it really did go from "yeah, openjdk is no problem" to "hmm, do we understand this?".

Post reply on HN