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

101–110 of 146 posts

Re: Revisiting Java in 2021 – Part II

#101

Post by javajosh »

StevePerkins wrote: post #94
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…

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

May you get down-voted into oblivion for your rudeness. It's not only unnecessary and uncalled for, but redundant.

If you'd like an example of how to correct someone's misunderstanding in a constructive manner, see sibling comments, which were posted prior to yours by an hour.

Re: Revisiting Java in 2021 – Part II

#102

Post by Zababa »

Symbiote wrote: post #100
sorokod wrote: post #68

Earlier quoted context omitted.

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.

I think variables names and infix operators/method names are very different.

Re: Revisiting Java in 2021 – Part II

#103

Post by selfhoster11 »

pm90 wrote: post #58
CraigJPerry wrote: post #25

Earlier quoted context omitted.

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…

You can’t avoid spring unless you’re in a small shop. It’s basically mandated/standardized at most places since “everyone knows it”.

Sadly, Java and Spring are basically a package deal these days. Enterprise shops are likely to run on Spring.

Re: Revisiting Java in 2021 – Part II

#104

Post by selfhoster11 »

erokar wrote: post #35
vbezhenar wrote: post #19

Earlier quoted context omitted.

I don't have an answer to your question, but I would suggest the following: skim over Java 5 syntax. It should be very easy to understand for anyone with programming experience. Explore Java 8, 11, 17 features, but try to map all the syntax to Java 5, because those features usually are just a syntax sugar and I think that it's easier to understand those features this way. Do not dive into standard library too much. I…

> After that you have to choose a framework, because Java applications are very framework-heavy ones. And that's where most of complexity comes from. People usually use Spring these days, so that's probably would be the most reasonable choice. There's no easy path, you'll struggle a lot and that's unavoidable. Modern Java Frameworks are full of hard to grasp concepts, tricky magic code and 20-year old roots buried in…

Spring is largely "Java: the missing parts", implemented in a very poor way. It's semi-standard, even though it's not part of the core language.

Re: Revisiting Java in 2021 – Part II

#105

Post by selfhoster11 »

tomohawk wrote: post #75

> Build tools such as Maven and Gradle are fast, stable and effective Exactly the opposite of what comes to mind when I think of these.

Gradle is not fast. I want to pull my teeth out every time IntelliJ decides to launch my application through Gradle rather than via the IDE directly because of the added boot time.

Re: Revisiting Java in 2021 – Part II

#106

Post by sorokod »

Symbiote wrote: post #100
sorokod wrote: post #68

Earlier quoted context omitted.

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.

A hoarder never throws anything away because it "might be useful". That is not a useful criteria for choosing language features.

Re: Revisiting Java in 2021 – Part II

#107

Post by papercrane »

javajosh wrote: post #95
twic wrote: post #84

Earlier quoted context omitted.

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

> 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 exception is very broad and fairly simple.

Azul has a good breakdown of it https://www.azul.com/blog/why-the-classpath-exception-is-so-...

The short answer though is if you link to a GPL+Classpath exception library you may distribute the results under any license you choose.

Re: Revisiting Java in 2021 – Part II

#108

Post by diroussel »

gozzoo wrote: post #91
smallerfish wrote: post #67

Earlier quoted context omitted.

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?

Micronaut is worth a look

Re: Revisiting Java in 2021 – Part II

#109

Post by vbezhenar »

gozzoo wrote: post #91
smallerfish wrote: post #67

Earlier quoted context omitted.

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?

The most lean and interesting alternative IMO is Helidon SE. It's backed by Oracle and uses very sane approach.

The most pragmatic alternative IMO is Quarkus. I don't really like it, but it seems to be the most popular alternative to Spring and probably will become standard de facto, unless Spring will jump ahead with some revolutionary changes. It's backed by Red Hat and seems to have the most momentum.

The best approach IMO is not here yet. Frameworks, mentioned above, rely heavily on reactive architecture. It's just not needed with Project Loom, so there's plenty of unnecessary complications. They even rewriting JDBC drivers.

I'm going with Quarkus for now, but I'm waiting for ideal framework to appear.

Re: Revisiting Java in 2021 – Part II

#110

Post by SubjectToChange »

karussell wrote: post #96
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.

Dalvik was replaced by ART nearly seven years ago.
Post reply on HN