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

41–50 of 146 posts

Re: Revisiting Java in 2021 – Part II

#41

Post by aaomidi »

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 don't think symbols necessarily need to be SEO friendly. I think Google just doesn't treat them as well as they could?

Re: Revisiting Java in 2021 – Part II

#42

Post by pjmlp »

hyperpallium2 wrote: post #22
Gerardo1 wrote: post #9

Earlier quoted context omitted.

OpenJDK: "Oracle’s free, GPL-licensed, production-ready OpenJDK" I don't know what could be more convincing than an explicit open license.

Suing Google for a billion dollars makes people irrationally nervous. Just sign the license and agree to all the terms and conditions. Nothing will go wrong.

So when will Android Java be proper Java?

Re: Revisiting Java in 2021 – Part II

#43

Post by smallerfish »

Overall, good, but I quibble in favor of Kotlin with a couple of points:

> Building large teams (think hundreds or thousands of developers) requires talent, and talent is easier to find if more people know the language (although, if you want the absolute best people, you might be better off choosing a more niche language).

It's very easy to hire good Java devs and crosstrain them to Kotlin.

> Java also arguably has the best tooling in the business. I'd argue that IntelliJ IDEA (and family) is the best IDE out there, more so if you are coding Java. Even if you prefer VS Code, Java is well supported.

Jetbrains of course make Kotlin also, and theoretically their Kotlin IDE support will be better than Java's once they complete the mainlining of the Kotlin plugin into the IDE code base. (Right now the Kotlin plugin has recurrent stability issues.)

Re: Revisiting Java in 2021 – Part II

#44

Post by vbezhenar »

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…

One of the strongest points of using a framework is that it's easy to find other people who already know that framework. And that depends on framework popularity. It's like old motto "nobody was fired for choosing IBM".

Spring is not well suited for modern microservices running in the cloud. Its startup time is slow and its memory usage is high. There are other frameworks emerging, optimized for GraalVM native image, most notable ones are Quarkus, Micronaut, Helidon. But their popularity is nowhere near Spring. May be in 5 years things will change.

Re: Revisiting Java in 2021 – Part II

#45

Post by pjmlp »

javajosh wrote: post #18
dvdkon wrote: post #11

Earlier quoted context omitted.

Perhaps point out how many non-Oracle commercial JVM vendors exist? They might not trust Oracle to be sane, but Red Hat, Microsoft, SAP and Amazon are all very big names in the industry who offer their own JDK distributions, some of them also offer commercial support.

Do you know what the legal relationship is between Red Hat and Oracle is? I think Oracle v Google has sent shivers of fear through anyone wanting to rely on Java, including through an intermediate, because the strength of the relationship is only as strong as the weakest link in the chain. In other words, what is the risk that Red Hat will be sued by Oracle someday over their use and support of Java?

Sun and Oracle have only sued those that went out of their way to create their own Java flavours, namely J++ and Android Java.

The Java ecosystem is just like C and C++, full of alternative, compliant implementations.

Microsoft learnt their lesson and is now an OpenJDK contributor.

So when will Google stop cherry picking OpenJDK features and actually support proper Java on Android?

Re: Revisiting Java in 2021 – Part II

#46

Post by ulrikrasmussen »

javajosh wrote: post #10
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…

Hmm. Great question. I've always liked Josh Bloch's "Effective Java" because it's targeted toward experienced programmers, and he expressed (correct) opinions about things like immutability. But the book is very old (2001). One way to get into it is to build something real, first on bare bones (e.g. 'javac Main.java; java Main'), then bare bones Maven, then finally pick a great starting project which itself curates s…

I would still recommend Effective Java, many of its items are still relevant. If you want to avoid being bitten by Java's gotchas, this is the book. Also Java Concurrency in Practice is a must in my opinion.

Re: Revisiting Java in 2021 – Part II

#47

Post by smallerfish »

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?

Re: Revisiting Java in 2021 – Part II

#48

Post by javajosh »

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

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…

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 that causes worry among the C-levels (and myself). A superficial reading might be that Oracle's JDK does not come with the GPL encumbrance. But this also raises the question: what differs between the various JDK builds? And again, what is the legal status of "OpenJDK" particularly WRT Oracle?

I personally don't think these are stupid or trivial questions. Nor do I think the answers are obvious. Nor are they nonsense FUD. I am certainly NOT an Oracle partisan - I saw first hand what they did with Sun.

1 - https://jdk.java.net/17/

Re: Revisiting Java in 2021 – Part II

#49

Post by pjmlp »

vbezhenar wrote: post #24
javajosh wrote: post #18

Earlier quoted context omitted.

Do you know what the legal relationship is between Red Hat and Oracle is? I think Oracle v Google has sent shivers of fear through anyone wanting to rely on Java, including through an intermediate, because the strength of the relationship is only as strong as the weakest link in the chain. In other words, what is the risk that Red Hat will be sued by Oracle someday over their use and support of Java?

Google perverted Java. That's what Oracle sued Google for. And that's what Sun sued Microsoft for decades ago. Red Hat is not trying to turn Java into something different, it just builds and supports existing OpenJDK codebase. It's absolutely different thing.

Yeah, where did all those from anti-J++ cheering crowd went?

Re: Revisiting Java in 2021 – Part II

#50

Post by setr »

aaomidi wrote: post #41
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 don't think symbols necessarily need to be SEO friendly. I think Google just doesn't treat them as well as they could?

They need to be google-friendly, or they need to exist in a world where code-friendly search tools exist.
Post reply on HN