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

131–140 of 146 posts

Re: Revisiting Java in 2021 – Part II

#131

Post by anotherevan »

hugi wrote: post #64
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).

Yes, this was the main reason I chose Java instead of Kotlin when starting our last big project. Would have loved to use Kotlin, but the vendor lock-in was the deal breaker.

Re: Revisiting Java in 2021 – Part II

#132

Post by vbezhenar »

chakkepolja wrote: post #127
vbezhenar wrote: post #109

Earlier quoted context omitted.

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

What's your opinion on vert.x vs quarkus? For more general purpose web stuff, it seemed to me vert.x had more libraries. Also, as for database, I really got fed up with hibernate (all configuration and stuff), do you know any simpler asynchronous / reactive alternative that handles object mapping? (automatically serializing from / into SQL objects).

Quarkus uses vert.x for web. What it does is provides a standard way with instructions to build a native image (along with some added functionality). I don't know if it's easy to build a native image from just vert.x app.

About database, sorry, I have no idea. Check out JDBI, JOOQ, those are most popular ones, AFAIK.

Also Quarkus adds reactive API to hibernate and some API to simplify some mundane Hibernate API, so maybe you'll like it.

Re: Revisiting Java in 2021 – Part II

#133

Post by selfhoster11 »

lamontcg wrote: post #113
selfhoster11 wrote: post #104

Earlier quoted context omitted.

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

The sad thing is that DI doesn't need to be heavy. I looked into this for some projects I was planning, and there are some lightweight (if technically off-putting, IMO - see Dagger 2 syntax) ways to achieve this. But everyone just reaches for the big frameworks in the first instance.

Re: Revisiting Java in 2021 – Part II

#134

Post by CraigJPerry »

da39a3ee wrote: post #117
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…

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)

It is awful.

However it’s not all accidental complexity. To pick a random example, there’s a reason typo squatting is a thing in npm or pypi but not in maven/gradle. The mitigation’s that prevent this are not free, they add complexity (e.g. signing before publication, dns records, immutable packages etc).

But there’s definitely some areas of accidental complexity remain. While gradle CAN be used well (e.g. 45 min builds.

Re: Revisiting Java in 2021 – Part II

#135

Post by chakkepolja »

vbezhenar wrote: post #132
chakkepolja wrote: post #127

Earlier quoted context omitted.

What's your opinion on vert.x vs quarkus? For more general purpose web stuff, it seemed to me vert.x had more libraries. Also, as for database, I really got fed up with hibernate (all configuration and stuff), do you know any simpler asynchronous / reactive alternative that handles object mapping? (automatically serializing from / into SQL objects).

Quarkus uses vert.x for web. What it does is provides a standard way with instructions to build a native image (along with some added functionality). I don't know if it's easy to build a native image from just vert.x app. About database, sorry, I have no idea. Check out JDBI, JOOQ, those are most popular ones, AFAIK. Also Quarkus adds reactive API to hibernate and some API to simplify some mundane Hibernate API, so m…

> Quarkus uses vert.x for web.

Thanks. I was thinking it's different because it used Mutiny APIs or something.

> Also Quarkus adds reactive API to hibernate and some API to simplify some mundane Hibernate API, so maybe you'll like it.

Thank you. I will check it out.

Re: Revisiting Java in 2021 – Part II

#136

Post by Zababa »

lenkite wrote: post #128
Zababa wrote: post #85

Earlier quoted context omitted.

Java seems to be heading for ML-like features while Kotlin is a "better Java". I think Kotlin lack a vision for the future, and might lose market share as Java itself gets better.

Since Java is now a neglected, second-class, incompatible elder citizen on Android, this is unlikely to happen.

I don't follow Android development at all, so thank you for the correction.

Re: Revisiting Java in 2021 – Part II

#137

Post by native_samples »

javajosh wrote: post #92
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.

No, but if your threads are basically 'free' then you can just model an actor as a thread+LinkedBlockingQueue or whatever channel abstraction you want to use.

Re: Revisiting Java in 2021 – Part II

#138

Post by native_samples »

invalidname wrote: post #118
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.

It might be easier these days with GraalVM/Truffle. You wouldn't run C# directly, you'd implement CIL in a Truffle interpreter, so you bypass JVM bytecode and its semantics entirely.

Re: Revisiting Java in 2021 – Part II

#139

Post by native_samples »

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…

Well, dynamic languages like Clojure and static analysis like ProGuard will never mix that well. The module system helps though. You can get rid of the parts of the JDK you don't need.

I very much doubt reflection is going anywhere. For one, GraalVM native images support reflection, you just have to state ahead of time what you plan to reflect over.

WASM+JVM works. You can run WASM on top of the JVM. There's a Truffle interpreter for it, which means WASM code gets JITCd by the JVM itself and you can interop in and out. Check out GraalWASM.

Re: Revisiting Java in 2021 – Part II

#140

Post by geokon »

native_samples wrote: post #139
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…

Well, dynamic languages like Clojure and static analysis like ProGuard will never mix that well. The module system helps though. You can get rid of the parts of the JDK you don't need. I very much doubt reflection is going anywhere. For one, GraalVM native images support reflection, you just have to state ahead of time what you plan to reflect over. WASM+JVM works. You can run WASM on top of the JVM. There's a Truffl…

Right, you can trim the JDK - that's true but I think the "problem" is a bit more general. I'll give you a more concrete example. I have some small application and it needed to do some basic image manipulation. So I bring in BoofCV and do the manipulation. However I then see that BoofCV drags in all sorts of crazy stuff to do with machine learning and whatnot - along with a sea of irrelevant dependencies

- I can keep around the bloat

- I can try to find an 3rd tier library with less eyeballs that's smaller and does less (If I later want to do more image manipulation I might find myself in a bind)

- I can try to manually go in and trim out the stuff I think I'm not using (not that I really understand the BoofCV internals..)

So the ecosystem is actively discourages me from using large mature libraries :( (I ended up using option 3 with trial and error)

Graal maybe sidesteps the issue. Yeah it has reflections, but as you say you need to be explicit about them. So the rest can be trimmed.

I guess my original loaded question was implying that maybe this will make library developers more keen on dropping reflections internally (it's honestly almost never a good design choice anyway)

That all being said.. I think 90% of people are writing some server-side web stuff and none of this matters to them :)

> GraalWASM

I'm kinda curious about the other way around. Running JVM byte code on WASM. Not in any serious way.. but it'd be cool you could run an uberjar in the browser. A quick search brings up a few ongoing projects :)

Post reply on HN