Hacker News Reader

Comment by markdoubleyou | Hacker News Reader

Yeah, they're back to owing Spring again. I wonder about the future of developer-centric Pivotal products. VMWare already acquired Spring, RabbitMQ, and GemFire back in 2009/2010 and then spun them off into Pivotal. So now that they've gone and acquired them again, will they divest again and just hold on to the K8s bits? VMWare is totally geared toward selling into IT orgs and has never seemed interested in dealing with developers.

View on HN

I maybe wrong and many will vehemently disagree here. But I feel this whole Spring Boot thing and other dozens of Spring products are going to collapse like Java EE business for many other vendors.

From what I am seeing at my workplace this whole meta framework/API things that they promote is leading to atrocious application development.

Can you elaborate? I work on a Spring Boot application and so far we're all pretty happy with it. Obviously I'm one data point, so I'd like to hear more about what you're seeing.

Kinda tricky to explain. It like 1 line expression becomes a method what could be method becomes a whole class. What could reasonably be a class is a whole package. So this whole application I am looking at is about 10 KLOC in 100 Java source files arranged in 15 or so packages along with 100s of jars buried somewhere in maven repo.

To compare other application which I wrote in straightforward manner is about 20 Java files in 2-3 packages in total 4 KLOC and 15 external jar files. And my application 4-5 functions from business POV as compared to 2 functions in Spring boot application.

So to me it is more about some cobbled app as opposed to engineered solution which I hope to deliver. Mind you this is all my opinion as management is doubling down on Spring boot and mandate from very top is to convert all Java app in Spring boot based services.

I don't want to sound like a Spring booster, since there are plenty of criticisms of enterprise Java development that I agree with, but there's nothing intrinsic to Spring that dictates whether your business logic is spread amongst 100 files or 20.

Dependency bloat can be a concern, but part of the reason for those dependencies is to reduce bloat in source code via auto-configuration.

Its possible to write bad code with or without any framework.

Yeah and you can drive dangerously with or without traffic lights. That doesn't mean traffic lights turning green in both directions at once isn't a disaster.

No idea why that is. I've been actually amazed at how much code I DON'T have to write using Spring Boot. I can focus purely on features/business logic. its great.

Having built an app recently with Spring Boot, I admire them for trying to make Spring as simple to get up and going as, say, Rails. And it's certainly better than Spring was on its own.

But in my experience it's still an enterprise-grade Frankenstein's Monster, and the developer experience is pretty bad compared with other frameworks I've used. If I was doing something on the happy path, it mostly worked. But the moment I tried to do something slightly different than they expected, I was 20 frames deep into Spring stack traces trying to puzzle out poorly written Spring code. I've done a lot of Java, so I could eventually emerge triumphant. But it was a giant time suck. Looking back on the project, we estimated we could have done it in half the time using something like Rails or Flask.

Could not agree more. I think , spring boot + spring cloud is extremely popular in the services (should i say microservices world).

Not to say , there is a changing world. Frameworks like Quarkus , Micronaut , Javalin are changing these status quos (Reactive + Cloud native + First class Kubernetes / FaaS support + Being lean). What remains to be seen though is how is Spring able to adapt and change to these. I dont know how Webflux stands up to these , but sure is interesting times ahead!

Rails, from what I remember, has a strong my-way-or-the-highway attitude. It has many strengths, but deviating from the happy path isn't it's strength. It's creator claimed it was Omakase. [1]

[1] https://dhh.dk/2012/rails-is-omakase.html

I guess I mean the phrase a little differently here. Rails does have a particular envelope that they support, but it is also pretty open to extensions. More importantly, if you do something slightly different, you do not end up having to debug reams of dubious, poorly tested code just to figure out how to get your nominally reasonable change to work. I spent a huge amount of time trying to figure out whether the change I really needed to make was in some XML file, some class annotation, or some custom code.

Been a happy user of dropwizard, what spring boot was "inspired" by, hookup guice and no spring magic classpath scanning to be seen

https://www.dropwizard.io/1.3.14/docs/getting-started.html#g...

I've heard two stories about the origins of Spring Boot, one of which included Ruby on Rails. I don't remember the other being Dropwizard, so I guess now I've heard three stories, only two of them from Spring contributors.

"Magic classpath scanning", also known as "classpath scanning", comes with leveled POMs, which is a massive sanity-preserver.

The Java ecosystem is in an interesting place at the moment because it seems to me the penny has finally dropped and they are starting to prioritize footprint and startup time - probably becuase it's clear that you can't run a huge honking app server in a lambda service or even a VM that isn't horrifically expensive to rent, but the whole industry is moving towards that.

So now you have things like Micronaut that start up in milliseconds and GraalVM suddenly getting taken seriously etc. And (for example) with Micronaut you pretty much have all the advantages of Spring Boot but about 6 lines of Groovy gets you a perfectly configured REST style API end point that starts up in hundreds of milliseconds.

So it's going to be very interesting whether this "pivot" of the Java ecosystem works, and where that lands all the traditional Java vendors ....

Spring-based software launches in hundreds or even tens of milliseconds if you've precompiled on Graal. The Spring team have been working closely with Graal folks to remove roadblocks.

Disclosure: I work for Pivotal, though not on Spring.

Spring boot + jOOQ + modern java is probably one of the easiest ways to build java services right now. Spring has done a good job at mostly just getting out of the way. Nothing I've seen with spring boot would have lead someone to write bad code any more than using guice.

Reply on news.ycombinator.com