The Modern Java Platform – 2021 Edition • Hacker News Board

Re: The Modern Java Platform – 2021 Edition

#211

Post by eecc » Wed, Mar 17, 2021, 7:00 PM UTC

soco wrote: post #106

eecc wrote: post #89

Earlier quoted context omitted.

That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by your…

Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.

Well, as someone else on this thread wrote, it does happen all the times you're not preparing for a presentation or a blog.

If you're building something marginally different from the routine the curtain is drawn, and IMHO you're probably better off buying a shrink-wrapped ready-made SAAS.

Re: The Modern Java Platform – 2021 Edition

#212

Post by eecc » Wed, Mar 17, 2021, 7:06 PM UTC

marcosdumay wrote: post #177

eecc wrote: post #85

Earlier quoted context omitted.

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

Enterprise as in "sold to enterprises" or as in "created by enterprises"? Both are complex, but for different reasons. Software that is sold to enterprises is complex because they compete on number of features (in checklists), and there is no pressure for quality since the software users have little saying on what software gets brought. Software that is created by enterprises for internal use is complex because the e…

> Software that is created by enterprises for internal use is complex because the enterprises themselves are complex. They are full of rules, created by different people with very different goals, that add up with time, and the applications must deal with them.

Maybe it's just me and my scarce disposition for forgiveness, but after several years I tend to believe complexity emerges as a consequence of superficial understanding, diffuse aversion to analysis and outright pool analytical skills.

:/

Re: The Modern Java Platform – 2021 Edition

#213

Post by doctor_eval » Wed, Mar 17, 2021, 7:09 PM UTC

foo_barrio wrote: post #196

doctor_eval wrote: post #96

Earlier quoted context omitted.

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

I had this experience with the so-called "app servers" at our company. We also have a daily batch processing system has tons of operational support, db+serivice monitoring, a very useful web UI, logging split out, authorization system etc. It's built around common Nix concepts like files, pids, pipes, etc. Thousands of these batch jobs are little JavaSE programs that launch, do their business, record their progress a…

Yeah your experience absolutely mirrors mine. Don’t even get me started on JPA; I’ve used exactly the same phrasing you did: when you use JPA, now you have to know SQL, JPA and JQL. It makes no sense!

Re: The Modern Java Platform – 2021 Edition

#214

Post by strictfp » Wed, Mar 17, 2021, 7:22 PM UTC

2020aj wrote: post #197

strictfp wrote: post #132

Earlier quoted context omitted.

I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise. I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platform…

Extensive experience writing enterprise apps in many different industries? To me it sounds like you're trying to refute a generality with anecdotal experience. Have you ever worked for a heavily regulated industry like healthcare or insurance? The business logic is heavily tied to the regulations which vary by state/country and can be quite... cumbersome.

That is true. I don't really refute that there are instances of complex rulesets. I've worked in some regulated markets, but not healthcare or insurance.

That said, I stand by the point that most complexity I've seen has come from infrastructure. Because although the rulesets might be complex, the way they are encoded is usually the source of the problem IMO.

For example, if the rules of the business are encoded in such a way that unit testing them is straight-forward, it puts the business at the center.

But when every rule is testable only in a complex deployment, the complexity of the app is no longer tied to the complexity of the business.

And the latter has been more the rule than the exception in my experience.

Re: The Modern Java Platform – 2021 Edition

#215

Post by strictfp » Wed, Mar 17, 2021, 7:23 PM UTC

foo_barrio wrote: post #193

strictfp wrote: post #132

Earlier quoted context omitted.

I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise. I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platform…

Just as a counterpoint, I've done a little bit of game programming and currently work on a tax reporting system (mostly). Both are full of random shit you have to know for no reason. The game random shit I've had to learn was often tied to very specific platforms at very specific times. The game stuff very often I had to delve into actual math + algos. The tax reporting system I get bogged down and mired in the liter…

I'm not refuting that businesses can be complex, but I am saying that most of the complexity I've seen hasn't been inherent to the business.

Re: The Modern Java Platform – 2021 Edition

#216

Post by krooj » Wed, Mar 17, 2021, 7:25 PM UTC

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…

Looks like I came up the same path as you: XML in Spring 2, with Spring 3 adding lots of support for annotations. Once Spring 4 came around, I was... okay with abandoning _most_ XML, but some things just made way more sense in XML, such as Spring Security configuration.

I first saw Spring Boot demoed by Josh Long at a Pivotal office in Toronto, and my first reaction was to wretch at autoconfiguration, since it was extremely apparent where it would lead. The team I was working with at the time were a hard NO on annotation-driven config, which I thought was extreme at the time; however, several jobs later, I saw the proliferation of Boot and the autoconfiguration cancer it caused. Some projects were explicitly re-written with a hard technical requirement to not use Spring Boot, and those code bases ended up cleaner and more readable as a result.

The current gig is steeped in Boot and I've just given up and instead tried to use TypeScript for anything new, simply to avoid the Spring ecosystem.

What's more terrifying is watching new grads and green developers use this magic trash and have zero concept of what's actually happening under the covers. When I say zero concept, I really do mean that they have no idea what the servlet spec is, let alone containers or reverse-proxies.

Re: The Modern Java Platform – 2021 Edition

#217

Post by krooj » Wed, Mar 17, 2021, 7:35 PM UTC

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.

I agree with this, having recently gone through the exercise of creating some "onboarding" apps for new grads using Spring 5 and XML, then again with annotations. All the underpinnings for a non-Boot application are still there and mainly sane.

Spring Boot absolutely yields write-once throw away, and you _must_ consider the source: Pivotal is a contracting shop, so it's in their interests to hook people into an ecosystem that they happen to be experts in. I'm surprised this fact is lost on most.

Re: The Modern Java Platform – 2021 Edition

#218

Post by bcrosby95 » Wed, Mar 17, 2021, 7:42 PM UTC

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…

I guess it depends upon what you mean.

For many projects, DI frameworks are a giant cargo cult. Whether you use annotations or XML. More broadly, Java's obsession with "flexibility" (really, false flexibility) is a giant cargo cult.

If you're talking about webapps specifically... using XML in Java was not a cargo cult. It was the only option in 2007. Even if you didn't use Spring.

Re: The Modern Java Platform – 2021 Edition

#219

Post by cutler » Wed, Mar 17, 2021, 8:03 PM UTC

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…

I don't know about that. Dmitri Sotnikov, joint author of "Web Development With Clojure", worked on a similar app and didn't even need types or OOP let alone a monster like Spring.

Re: The Modern Java Platform – 2021 Edition

#220

Post by rsj_hn » Wed, Mar 17, 2021, 8:48 PM UTC

algo_trader wrote: post #109

misja111 wrote: post #83

Earlier quoted context omitted.

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…

Errr, so today would you for Spring or Spring Boot ? For a large ebay-sort-of backend with lots of REST apis to both front end and back end itegrations?

I would choose it.

Bottom line, organizing and maintaining large codebases on which lots of developers are collaborating is going to be painful no matter what your stack is. There is no technical fix for overcoming all the dependency and coordination problems created by large, complex software.

As nothing is going to remove that cost from you, the best you can do it transform one of set painpoints into a different set of painpoints. The most dangerous choice is then the one where the painpoints are not well understood, even to the point where you think they aren't there. Trust me - they are there, lurking - waiting for you to start tripping over them.

At least with Spring there is a well understood approach with a large pool of developers and some accumulated wisdom. That's better than most alternatives for real world use.

OTOH, if you are building a small project with a small team, it doesn't matter too much which framework you use, just use whatever your team members are most comfortable with. If your intention is to grow into a massive project, then finding devs who have experience in your stack will matter more down the road.