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

141–150 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#141

Post by ralmidani »

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…

As someone who loves Python/Django, dabbled in Ruby/Rails, learned a multitude of front-end JS frameworks (Backbone, React, AngularJS, and Ember), and currently works with Java in an enterprise environment, I just want to add two points:

- If you're going to have config/setup files, make sure they utilize a language that is Turing Complete. YAML looks pretty, but for all practical purposes, is it really better than XML?

- I've said this before, and I will say it again: I doubt writing an import statement ever killed anyone.

Edit: the two points are related. Having a Turing Complete config/setup file makes it easier to add a level of indirection between your code and library/framework code, so you can e.g. utilize different implementations for different ENVs.

Re: The Modern Java Platform – 2021 Edition

#142

Post by selfhoster11 »

oweiler wrote: post #59
stevoski wrote: post #56

Earlier quoted context omitted.

> In a team with 100 devs, simplifying and unifying decisions is extremely important. I agree with this. Unfortunately, Spring is often chosen for projects with much smaller teams too. Just 1 to 5 devs on what is fundamentally just a CRUD app. Wrong tool for the job.

I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.

You know what should be taking care of all of these things? Java! For a language that bills itself as the "enterprise language #1", it's abysmal in supporting actual enterprise features like you listed above in a lightweight fashion. Instead, a whole third-party framework has to be tacked on just so you don't have to reinvent the wheel. Java doesn't even support dependency injection, something that I would consider an absolute minimum for even a small project.

Re: The Modern Java Platform – 2021 Edition

#143

Post by simmerup »

lmm wrote: post #67
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…

Spring proper is (relatively) fine; you can make applications with it that are more-or-less maintainable. Spring Boot is very different. It's a write-only framework, and while businesses may have enthusiastically adopted it, it's new enough that they haven't (yet) had to pay the maintenance costs and realise how bad they are.

What do you mean by write-only framework?

Re: The Modern Java Platform – 2021 Edition

#144

Post by sreque »

lmm wrote: post #76
_ivvf wrote: post #49

Earlier quoted context omitted.

I felt strongly enough about this topic to write a full blog post: http://sreque.blogspot.com/2019/08/the-autumn-manifesto-why-... . TLDR: so-called DI frameworks are really just frameworks for creating and consuming global variables and have very little to do with the actual principle in of DI. That said, I think the jvm and java the language are in a great spot. It's the frameworks and community that need a shift i…

I disagree with that blog post. It may be technically possible to hijack the classloader mechanism to make instantiating classes do dependency injection, but it's not easy or idiomatic, and it's not good for maintainability either; a reader can't tell the difference between a global service and a value object if both are just "new Foo()". DI, in the sense of separating the instantiation of long-lived service objects…

In response to:

"DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability."

You don't need a DI framework to do any of what you described. Also, I believe that what you are saying doesn't fundamentally describe DI, though it is related. In this post I go over what DI really means: https://sreque.blogspot.com/2019/09/dependency-injection-101...

I have never seen a case where using autowiring forms a legitimate tradeoff; it has always resulted in worse, harder-to-maintain code with little benefit in return.

I conflate Spring with Spring Boot because Spring Boot is built on Spring and most of my problems with Spring Boot apply equally to Spring.

Re: The Modern Java Platform – 2021 Edition

#145

Post by matwood »

oweiler wrote: post #59
stevoski wrote: post #56

Earlier quoted context omitted.

> In a team with 100 devs, simplifying and unifying decisions is extremely important. I agree with this. Unfortunately, Spring is often chosen for projects with much smaller teams too. Just 1 to 5 devs on what is fundamentally just a CRUD app. Wrong tool for the job.

I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.

Same. Spring boot + jooq is a quick, simple way to spin up backend services. Like any tool though, one needs to know Spring boot.

Re: The Modern Java Platform – 2021 Edition

#146

Post by selfhoster11 »

sz4kerto wrote: post #54
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…

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…

The "different tooling" you mention should be the Java language itself. Let's not kid ourselves, literally no one writes enterprise applications in Java without some kind of a framework, and lives to tell the tale/doesn't go crazy. Since Spring is a de-facto "official" framework to write Java apps in, we might as well clean it up for inclusion into the core Java language, with attention paid to transparency to tooling in IDEs.

Re: The Modern Java Platform – 2021 Edition

#147

Post by tonyedgecombe »

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.

Enterprise app developers (etc.) are not stupid.

Enterprise developers aren't stupid but enterprise software is some of the worst software I have encountered in my career. When a development team has one captive customer you get the results you would expect.

Re: The Modern Java Platform – 2021 Edition

#148

Post by throwawaywindev »

elric wrote: post #107
matsemann wrote: post #70

Pair programming with colleagues I often get frustrated by them wasting time doing things a hard way. Like using print statements instead of the debugger, or setting a breakpoint but then have to skip it twenty times to get to the correct case (instead of a conditional bp), or restarting the whole server instead of hot reloading the changed class in a second. So I think many don't know how smooth java can be if used…

Conditional break points are definitely a great secret weapon. But don't underestimate the value of the humble print statement. It's convenient and can often lead to surprising insights "hmm, why is this getting printed so damned much?" in a way that is sometimes more accessible than a debugger.

You can make breakpoints that just print stuff (at least in Visual Studio)

Re: The Modern Java Platform – 2021 Edition

#149

Post by geodel »

lmm wrote: post #64
avodonosov wrote: post #44

Earlier quoted context omitted.

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…

I'm no fan of regular Spring, but it offers some legitimate value and has relatively comprehensible behaviour. It doesn't break grep: when a class is instantiated by Spring you can find a reference to that class, and most IDEs can also follow those references. Adding a new dependency doesn't change its behaviour. Spring Boot is real a step change in comprehensibility, in the wrong direction. It's on a similar level t…

Good to see another big fan of Spring Boot as me.

> Spring Boot is real a step change in comprehensibility, in the wrong direction.

With VMWare's Tanzu crap for containers and Spring native initiatives, the idea is complete lock-in in VMWare ecosystem from developer desktop to running service. The goal seems that no one should have any visibility on their own systems except VMWare consultants.

Re: The Modern Java Platform – 2021 Edition

#150

Post by selfhoster11 »

zaphar wrote: post #136
throwaway4good wrote: post #130

People are critical of Spring because they have seen it in production and in practical projects. And fall in the naive trap that somehow the tools and the libraries are the reasons why a real-life software project is messy. However Spring is something that has stood the test of time and is used in thousands of actual projects. And Spring itself emerge out of practical software development with plenty of competing alt…

I'm not critical of spring because real life software projects are messy. I'm critical because I rarely if ever do greenfield development and when I'm debugging a production exception caused by something that Java's type system was perfectly capable of treating as a compile time error that is suddenly a runtime error I'm a little bit sad. And the sheer frequency that I encounter them indicates that just getting more…

The real solution is to bite the bullet and build Spring's features into Java. Make as many failures as possible detectable during compilation, and go back to hard typing.
Post reply on HN