Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Modern Java Platform – 2021 Edition

jamesward.com

Post reply on HN
Print view View original

91–100 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#91

Post by syjer »

eecc wrote: post #85
sz4kerto wrote: post #54

Earlier quoted context omitted.

There's a very good reason why Spring is used so widely. Complex enterprise apps are often complex because the use case and the environment is complex. E.g.: - integration testing and unit testing is required - transparently pluggable backends for message queues so that locally you can use SQLite as your pub/sub storage but in production it's Google P/S - standardized health check endpoints for all your apps ... The…

> Complex enterprise apps are often complex because the use case and the environment is complex. Uh maybe... the real question is where does that complexity come from. Is it intrinsic to the problem or just bureaucratic slob? Given a framework so popular, what are the incentives to go uphill and challenge assumptions - with the likely risk of being fired - or just concede and ad your little contrived contribution to…

From my experience, enterprise apps are generally complex because they are a combination of:

- environment: integration of a large amount of services - and a good amount of them are legacy and idiosyncratic

- use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all. This is IMO the main difference between a "pure" greenfield startup kind of project and the enterprise one.

- add another layer of burocracy and complex environment to navigate

And with that you got the enterprise app world :).

In the end whatever framework is chosen, the most important property is the availability of common language/patterns.

Re: The Modern Java Platform – 2021 Edition

#92

Post by Cthulhu_ »

misja111 wrote: post #83
lmm wrote: post #21

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…

I've been through the whole evolution from Spring with XML configuration to the current 'convention over configuration' approach of Spring Boot. I actually liked the idea behind the XML configuration when I first got to know Spring in 2007. With this you could decouple the composition of your application from the actual code. You could deliver a jar and the user could decide with his own XML which parts to use and wh…

While nowadays I wouldn't touch Spring with a ten foot pole if I had the choice, back then (must have been mid 2000's as well), Spring helped me really develop as a software engineer; everything I know now from (Java-style) interfaces, contracts and unit testing comes from that one six month internship where I was left to my own devices to build an application similar to what Sonar is nowadays (or was a few years ago). I still have the code somewhere, so many comments <_<.

Re: The Modern Java Platform – 2021 Edition

#93

Post by MattPalmer1086 »

avodonosov wrote: post #44
lmm wrote: post #21

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…

That`s not spring boot, that`s whole spring (and google guice, etc), starting from the idiotic XML for bean wiring, to equally idiotic anntations, and finally, after 15 or how many years, they realized that plain java can be used for object creation. What a discovery! Still, they introduced @Configuration bullshit, etc. (There are cases when such features may be useful, e. g. systems that are extended by 3rd party pl…

Fully agree. I've inherited an insane desktop application that uses the spring XML bean configuration. Then there's classes used to configure the configuration. And three separate property class types to pass the properties into the context, only one of which will persist the properties. And factory beans to instantiate a different bean depending on the properties passed in. And different XML configurations for each subproject which somehow join together but sometimes complain about dependencies being defined in the wrong place... Total nightmare.

It's basically impossible to know what will be instantiated, extremely hard to inject and configure things. When I find the time I'm going to just create things directly from Java with constructor injection and ditch the whole sorry mess.

Edit: did I mention how unbelievably slow it is as well?!

Re: The Modern Java Platform – 2021 Edition

#94

Post by jillesvangurp »

akhilcacharya wrote: post #43

What’s the modern standard for a full stack JVM app these days? Something rails-esque, or is it still just a split between Play and Spring Boot?

Spring Boot pretty much dominates. I think Play market share is a bit more in the long tail of alternatives. Also, it's very Scala centric and not widely used without Scala.

Spring is increasingly Kotlin centric and the combination is pretty nice. There's a wide variety of other frameworks such as vert.x, ktor, quarcus, etc. They are popular but compared to Spring quite niche.

With Graal and Kotlin native, the whole space is becoming less JVM centric as well. E.g. Spring Native just went into beta and Ktor has been inching closer to working on the Kotlin Native compiler for a while now (still some missing pieces). Particularly for serverless, this is relevant due to reduced startup time. Overall performance is not significantly better though.

Re: The Modern Java Platform – 2021 Edition

#95

Post by andresp »

Java is a great language. It keeps evolving at good pace, increasing dev productivity and adapting to modern patterns, while keeping a clear syntax, scalable VM, relatively fast compiler, in a mature ecosystem. It might be at the healthiest level it has ever been.

Re: The Modern Java Platform – 2021 Edition

#96

Post by doctor_eval »

sz4kerto wrote: post #68
strictfp wrote: post #58

Earlier quoted context omitted.

Enterprise apps are complex because they don't focus on solving the business problem, they focus on the tools and frameworks. Spring is not the cure, it's the disease.

This is absolutely not the case. Enterprise app developers (etc.) are not stupid. The domain and the business problem are often extremely complex and hard to understand.

My observation from my long career of writing enterprise apps is that frameworks are super complicated with many hidden variables, so when you apply them to a complicated business problem you end up with the square of the complications of both systems.

We ended up in framework hell. In response, we ditched all the frameworks we were using, went to pure JavaSE, and ended up with a (much!) faster, more reliable enterprise application that was far, far easier to maintain.

Re: The Modern Java Platform – 2021 Edition

#97

Post by doctor_eval »

aww_dang wrote: post #82
codr7 wrote: post #23

Earlier quoted context omitted.

This. I spent so much time this week chasing magic buttons in that over engineered piece of stink. I'd rather do raw HTTP servlets at this point.

Plain servlets, jetty, haproxy for TLS, jstl, postgres, apache dbcp. Add in whatever specialty libraries for the project and you can pull away with 1/100th of the dependencies.

Agreed, though I’d also add MyBatis.

Re: The Modern Java Platform – 2021 Edition

#98

Post by oblio »

The_rationalist wrote: post #4

GraalVM truly has the potential to become the universal, interoperable VM. It would be rational for e.g Julia folks to migrate to the graalVM ecosystem and cotntribute to it instead of living on their small code island. They would get an un inimaginable amount of benefits in the process.

I've never seen or heard anyone major use GraalVM in production. I only hear Oracle and a small bunch of other folks hyping it. Tech also lives on hype and a long time until a tech reaches a critical mass is generally a band indicator (i.e. if something doesn't reach the mainstream in less than N years, it never will).

There are some exceptions (Ruby took off after Rails was launched, Python was adopted by Linux distributions and it also had some decent web frameworks such as Django), but there's a reason we call exceptions exceptions. It's because they're exceptional, they're not the norm. Plus in the internet age (I don't count anything pre-2000 as internet age, since dial-up wasn't something most people wanted to live through) it's a lot more likely for something with a great future to be adopted quickly.

Re: The Modern Java Platform – 2021 Edition

#99

Post by oblio »

guggle wrote: post #87
tiew9Vii wrote: post #19

Earlier quoted context omitted.

That's interesting. I'm not the biggest Java fan, I can tolerate it. Recently working on a Python project I find I'm massively unproductive compared to something like Java or more specifically Scala as using Spark. Not having strong types and limited type hinting. I have no idea what things are, is it a int, string, object etc, clicking through in an IDE to see code/docs isn't as great as it's hard for an IDE to insp…

> Not having a compiler means I have to have unit tests doing what a compiler would do or finding out I have syntax errors or other errors at runtime. Nope, it's not the only way. In practice you'd have type hints all over your code and a linter to perform static analysis. Of course this can be integrated in you IDE, so it's easy to do. > Not having strong types and limited type hinting. I have no idea what things ar…

The thing is, type hints are optional. The vast majority of existing projects don't use them. Third party dependencies don't use them.

Python is a toddler in terms of typing system support. Probably a 2 year old.

Re: The Modern Java Platform – 2021 Edition

#100

Post by reactor »

lmm wrote: post #21

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…

This 'magic' is one of the reason why we switched to https://quarkus.io/

Couldn't be more happier.

Post reply on HN