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

111–120 of 146 posts

Re: Revisiting Java in 2021 – Part II

#111

Post by papercrane »

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…

> "OpenJDK" used to be an independent group who's purpose was to build a fully open-source Java - and it was Apache licensed.

You've confused OpenJDK with Apache Harmony. The Harmony project dissolved in 2011, essentially being killed by IBM's decision to join the OpenJDK project instead.

Re: Revisiting Java in 2021 – Part II

#112

Post by karussell »

SubjectToChange wrote: post #110
karussell wrote: post #96

Earlier quoted context omitted.

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

Dalvik was replaced by ART nearly seven years ago.

Sorry, just wanted to make the point that it is not JVM. Wasn't in Android dev since some years it seems ;)

Re: Revisiting Java in 2021 – Part II

#113

Post by lamontcg »

selfhoster11 wrote: post #104
erokar wrote: post #35

Earlier quoted context omitted.

> 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.

What's weird is that every app in Java uses a DI container, while just about no apps that I've encountered in the rest of the world worry about anything that heavy. Most apps just cheat and use a bit of global state or maybe roll their own service locator pattern and don't worry about it. From the outside it seems like Java's sweet spot is really massive applications where you can't just cheat in one or two well-known spots in the code and call it good.

Re: Revisiting Java in 2021 – Part II

#114

Post by nradov »

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

Not a scala programmer, but I searched for "scala cheatsheet" and got the answer: https://docs.scala-lang.org/cheatsheets/ Double arrow seems to have multiple uses - for anonymous functions (like in js) and for pass-by-reference arguments (I guess scala is pass-by-value by default). (Surprised at how Erlang-y it feels, especially WRT pattern matching)

Sure but the issue is that when a single symbol has multiple meanings that presents an obstacle to learning the language and understanding a code base.

Re: Revisiting Java in 2021 – Part II

#115

Post by ozzythecat »

javajosh wrote: post #27
jatins wrote: post #20

Earlier quoted context omitted.

what does enterprise support mean in context of a programming language?

It means having a service that you can contact with questions about the platform. For example, if you're having a weird GC problem you can pay Red Hat $300/hr to have a presumed expert (ideally a committer to OpenJDK) look at it with you and help you solve it. There may also be variants of this where you "subscribe" and get a certain number of support hours.

I'm curious if there is really a strong need for this service. What kinds of problems is a company solving and at what scale, that they need to have dedicated support with the language?

Re: Revisiting Java in 2021 – Part II

#116

Post by sk5t »

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

> A house is leaking from the roof.

Should one prefer the case where an adult cannot order a steak, because a baby can't chew it? Like, there is a grammar for acceptable identifiers, and it is a little broader than most. To me it seems like a good thing that unicode/multibyte identifiers are allowed, and that not more than the necessary portion of the top keyboard row symbols is reserved.

Re: Revisiting Java in 2021 – Part II

#117

Post by da39a3ee »

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…

Thanks. I have to say, this sounds awful -- it sounds like it will be a huge time sink and an impediment to learning about areas of software engineering that transcend specific languages (say, service orchestration, distributed systems, system architecture patterns, workflows, etc)

Re: Revisiting Java in 2021 – Part II

#118

Post by invalidname »

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# was designed in a way that makes it very hard to run on the JVM in a performant way. It has slightly different scope behaviors, slightly different asthmatics etc. Source: worked on a JVM running on C# which was hard, I think the reverse is even harder.

Re: Revisiting Java in 2021 – Part II

#119

Post by javajosh »

nradov wrote: post #114
javajosh wrote: post #23

Earlier quoted context omitted.

Not a scala programmer, but I searched for "scala cheatsheet" and got the answer: https://docs.scala-lang.org/cheatsheets/ Double arrow seems to have multiple uses - for anonymous functions (like in js) and for pass-by-reference arguments (I guess scala is pass-by-value by default). (Surprised at how Erlang-y it feels, especially WRT pattern matching)

Sure but the issue is that when a single symbol has multiple meanings that presents an obstacle to learning the language and understanding a code base.

How do you feel about = (assignment and equality check)? Or > which can be used for markup or less than or part of a function arrow? Or {} which can be used as a block or as an object? Or : which can be used for...so many things! Even the humble . can be used to dereference or as a decimal point. My point is that if "a symbol having multiple meanings" is a problem, then basically all languages have a problem.

Re: Revisiting Java in 2021 – Part II

#120

Post by nsonha »

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 it's more library authors that are to blame than the language author. He merely opens the gate for that kind of overloading, maybe too liberally.
Post reply on HN