[HN Gopher] Spring 6.1 now compatible with virtual threads and J...
___________________________________________________________________
Spring 6.1 now compatible with virtual threads and JDK 21
Author : philonoist
Score : 143 points
Date : 2023-08-16 14:52 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| greatpostman wrote:
| I keep reading negativity about spring. I got curious, am
| building the backend for a new startup with spring boot 3. It's
| been a breeze. Everything works, great tooling, very mature
| software. Am I missing something? Will I regret this in six
| months?
| eweef3334 wrote:
| I thought the same thing 20 years ago. Still using spring. It's
| not a panacea, but compared to other technologies which came
| and went, it's been a great investment. The same could be said
| for Java, linux, python, bash, vi.
| chasd00 wrote:
| one nit pick, Spring is more than Spring Boot although when
| people say "Spring" they're likely talking about Spring Boot.
|
| You won't regret using it in 6 months except maybe for the fact
| that your backend will be just working and doing its thing and
| there's not really much else to do except watch it work.
| cogman10 wrote:
| You will not, it's a fine choice for a software stack. There
| have been startup time problems, which Spring has been doing an
| excellent job of addressing. There's also been some silly
| performance problems which afaik have been addressed.
|
| We personally use Quarkus and it's also pretty good. I think
| the Quarkus story has driven spring towards having a better
| story and both are pretty excellent stacks to go with.
| nick__m wrote:
| Spring before spring-boot was an unreadable sea of unique xml.
| Spring-boot is a guardrail that steers you into the correct
| usage of the spring framework.
|
| spring => configuration over conventions
|
| spring-boot => conventions over configuration
| sorokod wrote:
| Spring Boot takes care of bundling libraries comprising the
| Spring universe into version compatible units. That is pretty
| much it.
| ojhughes wrote:
| Starters and dependency management are key features of boot
| but it's a big understatement to say "that's pretty much
| it".
|
| It includes actuators, the auto configuration system,
| embedded web server and configuration properties
| sorokod wrote:
| An interested reader can decide for themselves:
|
| https://github.com/spring-projects/spring-
| boot/tree/main/spr...
| gabereiser wrote:
| Mostly agree with this, the issue was that Spring Framework 3
| introduced a new way of doing configuration with the
| @Configuration annotation. Up until then it was all xml
| driven (some minor packages like spring-integration still
| required it) bean soup. The advent of the annotation driven
| configuration paved way for spring-boot to provide sane
| defaults to the framework (previously reserved for certified
| spring framework engineers like myself to define in xml that
| we copied time and time again).
|
| You nailed it though with Spring being configuration over
| convention and Spring Boot being the opposite. At the time,
| there was a competing web framework that was really simple to
| build with called Rails that made the mindset shift to ease-
| of-use from a dev standpoint away from ease-of-use from an
| ops standpoint.
| jonhohle wrote:
| I disagree but know I'm in the minority.
|
| I would take Spring config XML over the tightly coupled mess
| of Spring config annotations and code. Circa 2006, Spring
| config was about binding decoupled POJOs together and code
| didn't require any build time dependency on Spring. Now
| Spring is required at build time and objects expect to be
| instantiated as beans, and unit tests either require a
| minimal spring context or some other method of injecting
| dependencies that would have otherwise existed as a
| constructor arg or mutator anyway. Now "config" is fully
| Turing complete as opposed to declarative. Yuck! I'm no fan
| of XML, but config as code is no longer config, imho.
| vbezhenar wrote:
| I liked original Spring idea of being actually non-invasive
| framework as well and I never had any issues with Spring
| XML config. It worked for me and Idea has decent
| autocomplete for it.
|
| There was time when Spring was considered lightweight. Oh,
| well.
|
| Spring Boot is when it all went downhill.
| sverhagen wrote:
| I'm sure you can find terrible implementations using
| Spring/Spring Boot. But the only annotation you have to
| use all the time is @Component (or @Service) and you
| could still externalize that, even without XML
| configuration, by using @Bean in an @Configuration class.
| Even if you're not so worried about compartmentalizing
| your bean wiring, the number of annotations is often very
| minimal, and you can focus a lot on actually writing your
| best business code.
|
| At the end of the day, complex applications need to deal
| with complexity somehow. The debate becomes: do you want
| to adopt and trust Spring's "under the hood" complexity,
| or is your team going to roll a lot of that themselves.
| ivan_gammel wrote:
| Spring annotations have runtime scope (one annotation per
| class is usually sufficient for injection if Spring can
| resolve all constructor arguments). You can disregard them
| and wire your POJOs manually via constructors in unit
| tests. Spring context thus is really required only in
| integration tests, in unit tests it is optional and may be
| a code smell (testing too big scope).
| gloryjulio wrote:
| Spring is old. The negativity comes from the the time where ppl
| would jump to Rails or Django instead of dealing with the
| config explosion/unnecessary complexities for
| startups/verbosity of the java at the time.
|
| Now, we have modern java + simpflified saner default named
| spring boot, that's a different story
| cogman10 wrote:
| Spring boot has driven spring to be a lot simpler as well.
| Further other frameworks like Micronaut and Quarkus have
| driven spring boot to be better.
|
| There's been some real symbiosis among the backend frameworks
| that has caused them all to lift in quality.
| Alupis wrote:
| Kotlin + Spring/Boot is an amazing combination for backend
| work. The Spring/Boot Team have poured a lot of energy into
| making it very graceful to use.
| misja111 wrote:
| It's like you say, Spring Boot can get you from nothing to a
| production ready application in no time, it is reliable and the
| community support and documentation is great. It is also pretty
| flexible, up to a certain limit.
|
| If your product happens to be something serving a zillion
| requests per second, using some exotic protocol, or doing some
| wildly complex calculations, then Spring might not be be the
| best choice. And it just so happens that the HN community's
| primary interest goes out to these rare exceptions and not to
| the 99% other projects in the real world.
| matwood wrote:
| No. Lots of spring hate is from a decade+ ago. Spring boot plus
| jOOQ is a very productive backend.
| thegaulofthem wrote:
| Spring of a decade plus ago was fine, it just required a day
| or two of upstart to configure the whole deal if you weren't
| already familiar and had a good project to reference as a
| basis for bootstrapping.
|
| The tradeoff of today with Spring Boot is you might get
| bitten down the line with a little configuration mystery,
| although it's such a well-blazed path you're probably in good
| company and will find your error solved and documented.
|
| In addition, it's Java so virtually any serious task is done
| in a well-blazed fashion with numerous open-source options
| available. In contrast my Node library I used to generate and
| validate an XML document at work last month cannot read in
| its own XML output. It's a boon for efficiency.
|
| The only downside Java really has is that it's a bit harder
| to "hack on" a dynamic, evolving JSON structure so it may be
| a bad fit for organizational reasons if your company lacks a
| cohesive, mature Engineering staff.
| chasd00 wrote:
| my biggest gripe with old Spring was how far you had to go
| to get "hello world" on the browser when starting from
| zero. I never would have thought embedding the whole
| application server would be a good idea but SpringBoot
| proved me wrong. That plus the annotation based config vs
| xml files is what made fast development with Spring
| possible (in my mind).
|
| Also, Spring would be a miserable experience if it were not
| for Maven/Gradle. Have you ever counted the jar files
| included in a typical SpringBoot+Spring-Security+Spring-
| Data app?
| lmm wrote:
| > my biggest gripe with old Spring was how far you had to
| go to get "hello world" on the browser when starting from
| zero. I never would have thought embedding the whole
| application server would be a good idea but SpringBoot
| proved me wrong. That plus the annotation based config vs
| xml files is what made fast development with Spring
| possible (in my mind).
|
| All of this is long before Spring Boot. Embedding the web
| server so that your system is just a plain Java
| application is a great idea; annotation based config is a
| great idea; both of those are things you could do (and I
| did do) back in 2010 on Spring 3.3.
|
| The stuff that Spring Boot adds - the spooky-action-at-a-
| distance classpath scanning, the we-can-use-them-but-you-
| can't annotations, the way you can't override part of an
| autoconfig but have to either accept what the library
| gives you or write a full config from scratch - is a big
| mistake. Those who forget Java EE are doomed to repeat it
| I guess.
|
| > Also, Spring would be a miserable experience if it were
| not for Maven/Gradle.
|
| Sure. "Have dependency management that doesn't suck" is
| good advice for any software ecosystem.
| topspin wrote:
| > Will I regret this in six months?
|
| Only if you plan to collect kudos with it on HN. Otherwise
| you'll be fine.
| willsmith72 wrote:
| For a new full stack project I'd use a full stack JavaScript
| framework, but spring boot is still awesome. Especially so when
| slow starts and higher resource consumption aren't as important
| as developer productivity, testability, reliability (which is
| pretty often).
| nprateem wrote:
| But which one? Next.js, sveltekit, etc. are tied to frontend
| frameworks. Nest.js seems good, but basically Spring Boot in
| JS. A lot of JS devs seem to want more FRP based patterns
| (unless they like Angular), and the rest are just small
| frameworks that'll be difficult to hire for. Have I missed
| any? I want something fullstack and so more structured than
| just Express.
| oweiler wrote:
| You won't regret it. Huge community, great docs, good enough
| performance, great testability. Integrations for everything.
|
| It's boring tech, which is a good thing IMHO.
| m_0x wrote:
| The negativism towards has two main points:
|
| First, that Spring it's bloated. Spring now has a wide
| extension of modules that you may or may not need. Most of
| those modules won't even be added in your classpath unless
| specified in your pom.xml or build.gradle file. Very simple
| projects won't need the vast majority of the full Spring power.
|
| Second, that a Spring project takes too much time to launch the
| web app (Compared against other frameworks doing the same
| task). Part of the reason it takes too much time to start comes
| from how the engine inflates the beans and injects it. On that
| same topic, other frameworks such as Micronaut are more
| lightweight because they don't bloat the framework as much as
| spring, thus the launch time is shorter. Also take into account
| that Java developers adore complexity in code structure so that
| also affects launch time.
|
| Are you going to regret going with Spring? No, there is a lot
| of support from the community, if you have any issue you will
| find help in reddit and stackoverflow. It's a really mature
| framework.
|
| However it's not the only option. There are other frameworks
| that could be a better choice for your use cases.
| yallpendantools wrote:
| Let me throw-in my 2c worth. I started my career in consulting
| with an in-house but Spring-inspired framework. I hated it,
| turned to other jobs that used other tech stacks; nowadays I
| largely consider myself a Pythonista. Lately, after about a
| decade from that first gig, I've finally decided to learn
| Spring properly and I've made good progress with it. Mind you,
| I decided to do so only because it seems like a good career
| move to know Spring in this economy.
|
| So, my honest evaluation: learning Spring is frustrating and
| not an enjoyable experience at all. Just the sheer verbosity of
| things hurts my Pythonista soul. It's not just that Java is
| inherently more verbose than Python, it's just that "the Spring
| way" forces you to create three classes with little to no
| shortcuts around it; even the most opinionated Python/Node
| frameworks I've encountered wouldn't be that draconian. Coming
| from Python/Node/PHP/serverless, the framework's philosophy
| seems incomprehensibly monolithic.
|
| All the layers of abstraction (and their resulting stack
| traces) make for an extremely confusing debugging experience
| _especially_ for noobs.
|
| *BUT*, I admit, judging a technology for its learning curve is
| not fair. I just had to vent my honest opinion on the
| experience.
|
| I'm now at that point where I think I've grokked "the Spring
| way". That is, my Google searches on how to do X in
| Spring/troubleshoot a problem are smarter now. I've actually
| grown to appreciate it. (I'm pretty sure the Spring Gods would
| make me pay for the sheer hubris of this statement and will
| make me eat my words in the next feature I come up with in my
| side project.)
|
| JpaRepositories _are_ powerful magic. If Spring has any
| advantage over the frameworks I 've come to love, it's this.
| JpaRepositories compensate for what Spring/Java lacks in
| brevity. Oh, also, not a Spring-specific advice but Lambdas and
| method references have made Java easier to write and has
| definitely deflated the number of classes I've had to create
| otherwise. Some would say that's just lipstick on a pig but I
| prefer to see it as an oasis in a desert.
|
| Lastly, don't take this as advice for the backend you are
| building for a new start-up but I really see Spring's strength
| in that consulting CRUD-software market. If I can define specs
| in a legally-binding contract before writing a single line of
| code, if I can bang out a schema at the start of development
| and not worry about migrations, I would actually choose Spring.
| All the "corporate-rep" of Java won't hurt for these types of
| projects either.
|
| But on the other hand, for environments where I need a lot of
| flexibility and lack the leisure of time almost always, I feel
| like Spring would be a development death march.
|
| Misc notes:
|
| 1. I'm not actually learning vanilla Spring. I'm using Spring
| Boot alongside Vaadin. Overtime I've come to distinguish better
| between the two but maybe some percent of my frustrations in
| the learning phase is on Vaadin, not really Spring.
|
| 2. I made extensive use of ChatGPT in learning Spring. Even for
| such a boring/common tech, it's hilarious what ChatGPT gets
| wrong. But it also gets things right, giving advice in a level
| of clarity that blog posts and SO posts couldn't have provided.
| I would recommend anyone trying to learn Spring (or maybe any
| other framework/technology) to give ChatGPT a shot too. Even
| when it gets things wrong, the feedback loop that resembles
| actually talking to someone helps with the rubber ducking.
|
| Again, all 2c worth of opinions from someone not even a year in
| this framework. Caveat lector!
| lockhouse wrote:
| I think that's the source of negativity for the HN crowd. It's
| boring, predictable, mature enterprise grade software that
| quietly gets the job done. It's too similar to what they are
| forced to work with in $DAYJOB, instead of the exotic, fun
| frameworks they'd rather be playing with that you always read
| about here.
| hdjjhhvvhga wrote:
| Well, not exactly. HTMX, for example, is plain, simple,
| boring - everything but exciting. But people here love it.
| Why? Because they don't have to deal with overcomplicated
| crap for no reason.
| lfmunoz4 wrote:
| In six months no but in 1-2 years yes. Spring has large
| tentacles so that when you start using it all code is coupled
| to Spring Boot and it's dependencies. I.e, the code you write
| is useless without Spring Boot, it is difficult to separate
| your code from Spring Boot. Now when technology changes you
| will have major refactor work i.e, like when Spring Boot moved
| from Dropwizard to Micrometer. It is possible to mitigate but
| takes advanced skills.
| ojhughes wrote:
| Spring Boot is very productive but things can get very hairy
| when debugging auto configuration or understanding why a bean
| is missing from the context.
|
| Running Boot in a container is also not great due to the memory
| requirements needed for bootstrap (min 0.5 Gi). I know GraalVm
| makes this better but compile times are still too painful.
|
| I also think the push to make Reactor the default choice was a
| mistake (deprecating RestTemplate). The reactive model in Java
| feels unnatural and it can be very hard to debug.
|
| I am working with Go now and don't miss Spring Boot that much
| but it still has a place in my heart for the amazing community
| and docs.
| gabereiser wrote:
| Spring and the JVM (even modularized) is a huge sore for
| cloud ops due to container size. Great that you pointed that
| out. Go's chi router or Fiber along with gorm gets us not so
| far away if you're doing crud. I also love go's ability to
| bundle assets into the binary and serve them (front-end
| code). It's so good that if I want to run the entire web
| application on another machine, I just copy the binary and
| run. Docker memory requirements are in the 64m range and even
| that is probably a bit of overkill. I can run thousands of
| these on a raspberry pi 4. I can only run like 4 spring boot
| apps on it.
| lmm wrote:
| > Am I missing something? Will I regret this in six months?
|
| Yes. One day you'll add another dependency to your classpath
| and your application will magically be doing something you
| didn't want or need. And the way to turn it off will be an
| undocumented annotation that only exists in the next version of
| spring boot, so you'll upgrade to that, and then a whole bunch
| of other stuff will break.
| AtlasBarfed wrote:
| Spring is very good software, and basically and object oriented
| language will need to use stuff like it after enterprises throw
| their stack of requirements at it for 20+ years and following
| 20 years of technology evolution.
|
| Yes its been tied to many java architectural fashion
| boondoggles of the past (XML config madness, XML namespace
| magic, overly heavyweight serverside HTML rendering, JSP tag
| madness, software patterns) but I still turn to it for basic
| code structuring in any JVM app.
|
| Boot is pretty good ... until its not. If you are doing garden
| variety web services it gets you up and running fairly well. If
| you need to do anything fancy with routing or raw data in the
| html request/response, then it is not. And Spring is now so
| synonymous with Spring Boot that it kind of isn't a good thing.
|
| Spring also isn't a pure open source project, it has a company
| trying to constantly steer it to revenue production, but as
| those types of entities go, stewardship has been decent.
| Normally things like that have about four or five years of
| trying to use open source for market expansion before
| impatience/greed/frustration sits in and they go for the closed
| source grab (see: Hashicorp recently). 20 years is a remarkable
| run for something like that.
| mongol wrote:
| A stacktrace in a Spring app can be painful to see. Tons of
| Spring code inbetween layers of your own app. Sometimes it has
| made me wonder, what happened with just plain old method
| invocations?
|
| Granted, it can probable be helpful in many ways, but it comes
| at a price. But I think improvements in developer tooling will
| make annotation-driven programming unmodern. I see a
| renaissance coming for plain old programming.
| yCombLinks wrote:
| Spring does generate some giant stacktraces, but if you have
| all of your code in a unique package structure (like
| com.mongol) just jump through your own code by searching that
| name.
| DonHopkins wrote:
| "Java is a DSL for taking large XML files and converting them
| to stack traces." -Andrew Back
|
| https://twitter.com/9600/status/90729345307521024
| mongol wrote:
| Yeah, I think that is actually pretty insightful. But
| although that is what it has been it may not neccessarily
| be what comes next. I imagine developer copilots to take
| care of the mundande coding you would need to do without
| frameworks like Spring and basically make them unneccessary
| to a large extent. Instead you will have leaner apps, but
| with a larger proportion custom code, and less use of
| dependencies.
| vbezhenar wrote:
| Spring is too automagical, often breaks with new releases, eats
| incredible amounts of memory, requires too much time to deal
| with its problems, produces stacktraces longer than my program.
| It's terrible, honestly.
| ninjazee124 wrote:
| I have been building with Spring for over a decade. You won't
| regret it. It's just stable, and works and something you use to
| build things that last.
| mdaniel wrote:
| To add to the sibling comments, you'll also enjoy the monster
| amount of introspection made available in the combination of
| the JVM and JMX exposed via the Spring actuator endpoints. We
| regularly adjust logging levels of _running_ pods in order to
| sniff out errant behavior versus bouncing them to fiddle with
| some log level. I have yet to play with a software stack that
| is designed for as much in-flight tuning as Spring on the JVM
|
| Don't overlook @ConfigurationProperties
| <https://docs.spring.io/spring-
| boot/docs/3.1.1/reference/html...> as a way of strongly typing
| any configuration knobs that your application may require. That
| not only allows static typing to avoid the hazardous
| @Value("some.vaule.oops") but it also means that IJ will tab
| complete (with typechecks) in your
| application.{properties,json,yaml,whatever}
| ecshafer wrote:
| You probably won't regret it, Spring is a solid framework. But
| the issue with Spring in my experience is that it has constant
| breaking upgrades with various dependencies But this is more of
| an enterprise issue. Upgrade breaks a dependency, fixing that
| dependency will break another dependency, etc. While some
| people say Spring Boot is convention over configuration, I
| don't really buy that, the configuration is done via
| annotations which is still configuration. My other gripe with
| Spring is that despite it all being annotations, when it breaks
| it can be opaque about why it broke, or why it didn't bind
| something.
| derefr wrote:
| > Upgrade breaks a dependency, fixing that dependency will
| break another dependency, etc.
|
| If you just upgrade all your spring-related dependencies to
| latest-of-same-major-version every time you upgrade, on
| average how much does _your own_ code end up breaking?
| ecshafer wrote:
| In that light pretty rarely. Which I suppose is a point in
| favor of Spring. When spring's dependencies break you
| usually can't even run the server.
| gabereiser wrote:
| No, you won't. People who gripe about spring didn't bother to
| do things the spring way. If you wrote your own DAL, you did it
| wrong. JpaRepositories and the like are the way. If you wrote
| your own JSON serializer/deserializer you did it wrong, Spring
| includes Jackson and will do it for you (YMMV). If you rolled
| your own authentication, you did it wrong. Spring Security can
| magically lock down your app with as little as a single
| configuration method, providing jwt/oauth/openid-connect
| enterprise security out of the box.
|
| The issue with spring boot is not it's feature-set or it's
| robustness. It's with it's heavy handedness to force you down
| the "spring way". Annotation driven. Extending provided
| interfaces. Making it "sticky" and impossible to remove. Want
| to introduce gRPC? yeah, you're going to have to find a way to
| weave that into Netty or use a different port. It's robust
| enough just up unto a point where you hit a roadblock and have
| to dig deep deep into Spring land to understand whats going on.
|
| It's still the best framework for standard crud web api's and
| such with Java. Though micronauts is quickly approaching. You
| can't go wrong choosing spring boot in 2023 if your intention
| is to ship in 2024. Whether or not that codebase is solid in
| 2027 is another matter.
| no_wizard wrote:
| What about something like ktor[0]? This looks promising to
| me, at least.
|
| [0]: https://ktor.io/docs/welcome.html
| Alupis wrote:
| ktor is best fit for Kotlin applications. But, much like
| Play Framework - you can use it with just about any (or
| any?) JVM language.
|
| With that said, Spring Boot will be vastly more mature,
| have a lot more resources available, bigger community, etc.
| There's also tons of 3rd party libraries that have support
| for spring and/or spring boot out of the box - such as
| resiliance4j, openapi-generators, etc.
|
| With that said, Spring/Boot's Kotlin support is really
| good. The team has clearly put a lot of effort into making
| Kotlin a first-class language within the Spring ecosystem.
|
| For backend work, Kotlin + Spring Boot is amazing.
| zapnuk wrote:
| Sometimes the spring way is also just ugly, or confusing if
| you just want to do thing X. This code here is used for
| making HTTP requests using OAuth2. There are probably other
| ways to do it but I've seen this code in more than one place.
| I speculate that most people didn't knew they had to use a
| "AuthorizedClientServiceOAuth2AuthorizedClientManager", but
| rather found an implementation online and copied it.
|
| But as you pointed out, since there are established spring
| ways to do something, it doen't matter if it's ugly since it
| actually "just works".
|
| ```
|
| @Bean
|
| public AuthorizedClientServiceOAuth2AuthorizedClientManager
| authorizedClientServiceAndManager (
| ClientRegistrationRepository
| clientRegistrationRepository,
| OAuth2AuthorizedClientService authorizedClientService) {
| OAuth2AuthorizedClientProvider authorizedClientProvider =
| OAuth2AuthorizedClientProviderBuilder.builder()
| .clientCredentials() .build();
| AuthorizedClientServiceOAuth2AuthorizedClientManager
| authorizedClientManager = new
| AuthorizedClientServiceOAuth2AuthorizedClientManager(
| clientRegistrationRepository, authorizedClientService);
| authorizedClientManager.setAuthorizedClientProvider(authorize
| dClientProvider); return
| authorizedClientManager;
|
| }
|
| ```
| vbezhenar wrote:
| Now make it with user-configurable credentials (like
| extracted from database) with proper token caching.
|
| With similar code I almost made a vulnerability in my app
| because Spring cached tokens which belong to different
| users.
|
| Spring security is terrible piece of code. Spring - I can
| stand it. Spring Security - I can not. It was different
| project back in the day (Acegi Security if I remember
| correctly). It should have stayed that way.
| sverhagen wrote:
| And yet, it is probably still much more secure than what
| 90% of us can whip together. I mean, maybe there's
| something better out there. I'm just pushing back on any
| suggestions that you should rather roll your own.
| Because, unless you're the other 10%, in an organization
| where continuity of that skill-set is taken care of, you
| definitely should not.
| zapnuk wrote:
| This already uses user-configurable credentials. It uses
| an autowired "ClientRegistrationRepository" that provides
| the credentials.
|
| We load the credentials once from AWS SecretsManager but
| I'm sure you could also load them from some DB.
|
| But yes, I'd probably prefern a modern rewrite of Spring
| Security.
| switch007 wrote:
| I usually begin to rant about the verbosity and unintuitive
| ways of overriding things in Spring when I have to do it,
| but then stop and realise I'm grateful that it's actually
| possible and I don't have to throw out the framework or do
| some extremely ugly hacks.
| FlyingSnake wrote:
| Tangential but I really wish HN supported monospaced code
| blocks using 3 backticks. Reading code blocks on a phone is
| terrible here on HN
| gabereiser wrote:
| You can do it with 3 spaces in front. Not the same as
| backticks but works just as good...
| public class See { public See() { }
| }
|
| You just have to use a scratch
| sorokod wrote:
| Annotations are great until something breaks.
|
| Fundamentally they are an abstraction over a rats nest of
| code (of a specific version), library dependencies and
| configuration. Gods help you when something breaks, the
| abstraction leaks and you are presented with a glimpse of the
| underlying complexity that is now yours to tinker with.
| gabereiser wrote:
| Oh don't get me started when competing data source beans
| are defined. Which one will @Repository pick up? Which one
| will it use at runtime? Why is my stack trace 245 deep?
| heisenbit wrote:
| I would agree with most except Spring Security is not so
| simple due to its power and a number of changes over the
| releases. Trivial cases are simple to do but anything beyond
| that requires understanding the beast and that takes real
| effort. More complex cases are then again relatively easy.
| gabereiser wrote:
| We experts have to pay our bills somehow... I joke but
| you're right. Spring Security works up until a point and
| when you want to make it do exactly what you want it to,
| you have to crack it open-override or extend-implement your
| own class ( _cough_ UserDetailService _cough_ ). Still, if
| you're doing microservices with spring, spring security is
| enough to ensure your jwt in the request is valid. I like
| to pair it with more robust auth like Keycloak though if
| I'm going "platform" instead of monolith.
| yAak wrote:
| Sorta random, but I really appreciate this kind of post on
| HN. People have tons of domain expertise and hard-earned
| lessons that get shared like this, and it broadens my
| awareness without requiring any time investment on my part.
|
| Thank you, thank you (and others like you) for taking the
| time to type this up!
| gabereiser wrote:
| I'm shocked actually that you don't get this kind of
| mentorship where you work. What's your Director doing? Not
| that we'll be building spring apps but knowing where we, as
| an industry, have came from and tried things, we'll avoid
| them in the future. My heart sinks when a good idea on
| paper, but bad IRL, get reimplemented 10 years later
| because someone didn't bother to read history. That said,
| sometimes _time_ is all you need for tech to catch up.
| Rarely that's the case though.
|
| So yeah, you're welcome, thanks for coming to my grey beard
| tech talk. Ask your managers for more brown bag/lunch &
| learns from the older folks at your company - they have
| stories.
| seadan83 wrote:
| Spring DAL is really debatable. My view of it is that it is
| one of those 'fast early development' at the expense of
| maintenance. It's easy to write code, modifying it later is
| difficult. Thus I feel this is an optimization to make
| writing easy code even easier. Therefore the pain of the
| Spring DAL is unexpectedly slow queries that are doing N+1
| selects, having to translate SQL to JPA queries and back [+],
| dealing with the ORM issue that Spring models database rows
| and not database results, selects that retrieve far more data
| than they need, and the unnecessary situation of having to
| build a full object model to represent database (which is
| often unnecessary! If my only query aggregates 4 tables and
| returns two string values, there should be no need to model
| those 4 tables as full blown Java objects - I'm clearly a fan
| of things like MyBatis or JDBI for replacing the Spring DAL
| access. I've been embarking on that very effort at my job, so
| far replacing Spring JPA to JDBI has reduced a ton of code,
| was able to recently remove net 40 classes by replacing JPA
| with JDBI).
|
| For example, some queries are naturally best done as analytic
| queries (or window queries). I have no idea how to do that in
| JQL (JPA's query language). Moving those queries to the
| database side can come to the rescure, but it's still an
| issue.. Which makes me think that JPA makes the easy queries
| even easier, but the difficult queries nearly impossible (if
| not outright impossible).
|
| > Though micronauts is quickly approaching.
|
| I've been looking at micronaut quite a bit as well. Another
| big downside to springboot is that by default it wants around
| 100MB of RAM per instance. With 6~7 applications on one host,
| the expenditure for the memory is sizable. Micronaut has a
| significant leg up here.
|
| [+] DB Queries are often developed first by figuring out what
| the right query is. After that is done, it needs to be
| translated to JPA. If JPA eventually starts doing the wrong
| thing, or something slow - it then needs to be converted to
| SQL so you can do an explain plan. The latter is not that
| hard as you can enable a debug output to see what it is, but
| overall there are quite a few more steps here compared to:
| "develop your SQL query, next plop that into a string
| variable in your java code", vs "develop your SQL query,
| model the table relationships as java objects, build a JPA
| repository to run some queries against those tables" (in the
| happy case the latter is all that you need and is not bad,
| but when a query starts going slow, or starts fetching MB of
| data which you won't notice on local development but in
| production causes a p0...)
| eweise wrote:
| Spring DAL is geared towards operational data stores where
| typically you are not joining four different tables. Its
| been a while but pretty sure you can just write the native
| SQL and map the results to a collection, bypassing mapping
| to objects. The best strategy I've found is to make the
| domain objects one-to-one with the tables so their is no
| joining or inheritance. Do any combining within the
| repository or application layers. This makes the DAL super
| simple.
| gabereiser wrote:
| If you really really really have to, you can use @Query
| to define your own query for the repository interface
| method. This allows you to map, join, select, whatever
| you wish. The gripe is that if you don't follow a
| specific wording convention, you _must_ use @Query. JPA
| follows a specific convention - findByUsername or findBy
| (id) or findByPostAuthor(String name). There's a whole
| section on how it derives sql statements from these
| methods.
| whartung wrote:
| I can't speak to Spring, and I've never worked with it
| directly.
|
| I'm from the Java/Jakarta EE parallel universe. Where
| everything is the same, but different. Both universes have
| impacted each other is various ways.
|
| JEE has a lot of baggage and notoriety, but, to be fair, so
| does Spring as they both came up in the same domain at the
| same time. The XML Hell that JEE was notorious for afflicted
| Spring as well back in the day. Spring has been more nimble
| and brought many things to light before they hit the JEE
| standard, but JEE marches to a different drummer.
|
| Modern JEE is pretty darn good. JAX-RS for web services is
| really nice, and there's a lot of different deployment
| options. A lot of the things you can love in Spring you can
| find in JEE, a lot of the things you can hate in JEE you can
| find in Spring.
|
| Again, not able to speak to Spring, but JEE has been really
| stable over time. In that old code continues to work even in
| new containers. There's a good chance that could even deploy
| an old, creaky "J2EE" application from 20 years ago in a
| modern container.
|
| The most disruptive thing to happen to JEE was the
| Jakartatization of it when it moved from Java EE to Jakarata
| EE, and all of the namespace changes that happened between
| Java EE 8 and Jakarta EE 9 with the move from Oracle to
| Eclipse. But even then, you can still deploy old code in new
| containers. This was far less disruptive than it could have
| been, frankly.
|
| I'm certainly not going to suggest to not use Spring, but at
| the same time, I wouldn't discard JEE out of hand either.
| It's also an exciting space (for assorted values of
| "exciting" and "enterprise") for back end work.
| TedDoesntTalk wrote:
| > There's a good chance that could even deploy an old,
| creaky "J2EE" application from 20 years ago in a modern
| container.
|
| Just no. No. All the different types of EJBs... won't work.
| Neither will SOAP endpoints. And a shit ton of other stuff
| that JEE dropped. What are you talking about? Even XML
| parsing moved packages.
| gabereiser wrote:
| He must still be stuck on JBoss at work...
| coderoffortune wrote:
| Don't worry, all negativity comes from those miserable Go devs.
| paulddraper wrote:
| > Am I missing something?
|
| There's a huge difference between "Spring pre-Boot" and "Spring
| post-Boot."
|
| Not _quite_ as significant as Angular 1 vs Angular 2, but
| close.
| pjmlp wrote:
| Usually HN culture with their Python and Ruby stuff.
|
| I wouldn't change Jakarta EE, Spring, ASP.NET for framework of
| the day, with a subset of functionality and molass performance,
| unless told otherwise by customer architect.
| time4tea wrote:
| If you drink the kool-aid, you'll love it.
|
| It's a tricky question to get a real answer, due to all the
| vested interests, lack of real research, and differing views of
| "what is good"
|
| Which is better, Amiga or ST (Amiga!)
| switchbak wrote:
| Despite the all-in opinion in this particular thread, my take
| is a little more nuanced. The modern versions of Spring are a
| breath of fresh air (no pun) compared to the older ones. It
| still does have a bit of a kitchen sink feel when you build
| something non-trivial, and some of the magic of the boot
| approach can become hard to reason about. You may prefer a
| simpler worldview of an alternative runtime, and you can also
| benefit from shorter compiles/quicker startup, etc.
|
| That said, the downsides aren't really that bad. It's got a
| strong community, will obviously still be around in 5 years,
| and the JVM is seeing strong investment and modernization. All
| in all, it'd be a strong contender if I was putting my money on
| the line. I'm still a fan of the simplest-thing-that-can-work
| approach (in the old days it was Jetty + Guice + whatever else
| you wanted), but modern Spring isn't all that far off from the
| experience anymore.
| xyst wrote:
| All of these nice features of the JDK yet most Fortune 500
| companies probably still using JDK8 or 9.
| w10-1 wrote:
| Isn't it a success when you can build something that lasts 10+
| years?
|
| Enterprise has been relying on Java's compatibility promises
| for decades. It means the business decides when to invest, not
| the technology. The cost of re-validating and re-integrating a
| new system far, far outweighs that of re-writing the software,
| so you only upgrade the software when you're already having to
| upgrade the system.
|
| Mark Reinhold managed to move Java to open-source, to frequent
| releases, and to supporting alternative languages (Kotlin for
| Google) and deployments (graalvm for containers) -- all while
| maintaining compatibility. He entirely effaced the notion that
| change means breakage.
|
| Compare the breakage story in Python and C++ in the same time
| period.
| pjmlp wrote:
| Thankfully Java 11 LTS is now the bare minimum in our projects,
| and I even managed to push for Java 17 LTS on the latest one.
|
| Even Android team has acknowledged that despite Kotlin, they
| needed to improve their support due to third party libraries,
| with Java 11 LTS last year, and Java 17 LTS coming this year.
| Both down to Android 12, naturally the usual subset without the
| graphics/UI related packages.
| ebiester wrote:
| Who's using JDK 9? I understand the JDK 8 bit - the breaking
| changes in large code bases are a big lift, especially in
| projects with no significant changes for years. However, if
| you're on 9, the lift is much lower and primarily on QE. Why
| stay on 9?
| sverhagen wrote:
| For large organizations it's also an organizational lift,
| plus their attraction to have all the latest goodies from the
| latest JVM versions is probably a little less, so a lot of
| the same inertia that existing in moving from 7 to 8 and from
| 8 to 9 is going to resurface for any migration, even if the
| actual breakages during the compilation step are less.
| pron wrote:
| Some significant number of projects still use 8, but all
| indications are that they're not the majority anymore (I don't
| have information about Fortune 500 companies specifically).
| carimura wrote:
| Most companies I talk to have a mixture of 8 for many stable
| unchanging applications and [11, 17, latest] for newer stuff.
| invalidname wrote:
| That's because most of them haven't "really" migrated to
| containers. Once this is done the process of using a newer
| version of Java will become seamless.
| jjtheblunt wrote:
| Jar files are containers, in some fundamental way, I'd say.
|
| Perhaps since they come from Sun and Solaris had zones, et
| cetera?
| switchbak wrote:
| And not, in a more fundamental way. Sharing a JVM just
| isn't the same thing as a sandboxed process.
|
| OSGI was probably the closest thing that tried to embrace
| that model, and it didn't turn out very well (putting it
| mildly). If the JVM actually did provide the same
| guarantees and restrictions as a real container, that would
| have been very useful.
| sverhagen wrote:
| In my experience it's more because their compliance team
| hasn't blessed the newer version for general use. These large
| organizations don't put the autonomy with individual teams to
| make such decisions to upgrade technology. So everyone is
| looking at a centralized authority who then feel the pressure
| to make a perfect decision, which turns into a hesitation
| because they also don't have a great process to evaluate a
| complex piece of technology like the JVM and declare it
| "perfectly safe and secure". So then the status quo wins.
| They will even pay companies like Azul to maintain support
| for Java 7 or 8, rather than making the leap. (And yes,
| there's probably a small contribution to this problem from
| source code that's hard to migrate, but as good as Java's
| been about backward compatibility, I don't think that's a big
| contributor in earnest.)
| closeparen wrote:
| That's pretty incredible hubris, to worry that something as
| central and widespread as Java could suddenly stop being
| safe and secure in a way that only your org can detect or
| care about.
| lmm wrote:
| It's more that their policy doesn't have enough detail to
| distinguish between Java and one dude's GitHub project.
| They'll have one policy for "software", or if you're
| lucky then two policies, one for "software we have a
| support contract for" and one for "software we don't have
| a support contract for".
| volkadav wrote:
| With extended support available for JDK 8 until this end of
| this decade or so, it's going to be a while before the real
| laggards upgrade, heh. Maybe that'll be my generation's method
| of funding the retirement RV purchase like the COBOL grognards
| circa y2k, haha.
| AtlasBarfed wrote:
| To be fair, JDK8 represents a stable version of Java features
| and API that is most of what is needed for enterprise Java
| development. It is basically the stable inflection point of
| Java's evolution in terms of why Java took over enterprise
| development.
|
| There was a core development intelligence level that JDK8
| represented a sweet spot for (ahem, offshoring development).
| Which is really the core of the hate for Java these days
| although ... isn't Go the same trap?
|
| Most of the post-JDK8 features are moving the language to what
| Groovy is, but closures, magic string templates, etc, but the
| IQ level of the programmers for that is a different market
| availability. Combined with the inherent deployment churn
| needed for modern JVM version turnover, which most enterprises
| simply don't have the organizational ability to do, means that
| JDK8 is going to stick around a LONG time.
| oblio wrote:
| Somewhat off-topic, somewhat related:
|
| Is Hibernate moving towards Java generics, about 2 decades after
| the fact?
|
| Spring seems much bigger and seems to moving much more quickly,
| but it's weird that Hibernate seems to still be stuck somewhere
| around Java-in-the-00s.
| invalidname wrote:
| There are things they can't do due to erasure but they use
| generics quite a bit in the API. Spring Boot uses generics for
| the CRUD interfaces etc.
| krzyk wrote:
| Hibernate is probably held back by JPA, which evolves slower
| than Java itself.
| nprateem wrote:
| I just wish there was an admin generator like django's
| [deleted]
| nobleach wrote:
| So far the responses have been lukewarm to negative. I'm all for
| a framework as big as Spring, blazing the trail to use Virtual
| Threads! I haven't used Spring Boot in a few years, and Webflux
| was a paradigm shift that didn't interest me. It'd be nice to see
| what this does for the framework.
| hashmash wrote:
| Where can we read about the responses?
| kitanata wrote:
| [flagged]
| wiseowise wrote:
| How's performance? Is it better? Any benchmarks?
| fnord77 wrote:
| Spring has gotten so bloated. It seems like there's no feature
| request they can say "no" to. Plus there's multiple ways of doing
| the same thing. e.g. JPA, spring-data.
|
| their call stacks between injected components are sometimes a
| couple dozen layers deep and it makes no sense.
|
| they don't provide easy upgrade paths between majors versions and
| they stop updating vulnerabilities on older major versions. I
| inherited some code that was using version x but had to be
| upgraded due to critical vulnerabilities. The vulns weren't fixed
| in x or y but only z. I tried moving over and their cryptic unit
| test fixtures stopped working. No docs on migration. Spring is
| sort of like cancer.
| okeuro49 wrote:
| It would be pretty unusual for Spring not to take advantage of
| virtual threads, given the potential for dramatic performance
| improvements under many workloads.
| nforgerit wrote:
| > It seems like there's no feature request they can say "no"
| to.
|
| Well the opposite of this is the antiquated world of "old
| Java". My subjective assessment is that Spring is somewhere in
| the middle: reasonable conservatism of principles but eager
| adoption of beneficial new things. Jumping on virtual threads
| is a reasonable action.
|
| > their call stacks between injected components are sometimes a
| couple dozen layers deep and it makes no sense.
|
| We're talking big enterprise-y software, right? Things get huge
| over time, no way out of complexity. The major red-flag would
| be accidental complexity which Spring, compared to the rest of
| the Java world, generally manages well, I'd say.
|
| > they don't provide easy upgrade paths between majors versions
| and they stop updating vulnerabilities on older major versions.
| I inherited some code that was using version x but had to be
| upgraded due to critical vulnerabilities. The vulns weren't
| fixed in x or y but only z. I tried moving over and their
| cryptic unit test fixtures stopped working. No docs on
| migration. Spring is sort of like cancer.
|
| Well non-trivial upgrade paths is the essence of a "major
| version upgrade". The alternative is to let old ideas never die
| and either stop introducing new concepts at all (old Java) or
| introduce them and make the framework bloated (something you
| criticized in the beginning of your comment). It's a trade-off
| which I think generally is well managed in Spring. It's boring,
| but in a good way.
| geodel wrote:
| > Spring is sort of like cancer.
|
| That itself is kind of polite way of putting it. This thing is
| freaking pandemic virus. Spreading in all sort of projects
| including code with single CRUD operation.
| microflash wrote:
| > Spring has gotten so bloated.
|
| I'd call Spring feature-rich than bloated. You can always shed
| weight that you don't want to carry.
|
| > Plus there's multiple ways of doing the same thing. e.g. JPA,
| spring-data.
|
| That's because there are different ways to solve a problem.
| Someone may want an ORM-based approach to connect to the
| database; they can choose spring-data-jpa. Someone may want to
| use JDBC with a light abstraction on top of it; they can choose
| spring-data-jdbc. It's all about choices and right tradeoffs
| and Spring offers plenty of them.
|
| > they don't provide easy upgrade paths between majors versions
|
| That's not my experience. I've been happily upgrading 2.x.x
| versions and plan to upgrade to 3.2.x when it is ready. But
| depending on the codebase, I admit it can be painful. Projects
| like OpenRewrite[1] might help here.
|
| > and they stop updating vulnerabilities on older major
| versions.
|
| This is not news. They want you to pay for extended support if
| you need it.
|
| > No docs on migration.
|
| They do maintain migration docs on GitHub wiki which are a lot
| more detailed than their blog posts on migration. Here's the
| latest one to upgrade from Spring Boot 2 to 3:
| https://github.com/spring-projects/spring-boot/wiki/Spring-B...
|
| [1]: https://github.com/openrewrite/rewrite
| Salgat wrote:
| My biggest issue with "feature rich" is that unless you have
| strict control over your developers' usage (which won't
| happen in most large companies), you'll inevitably have all
| sorts of bloat used by various teams in your organization,
| which just adds to the cognitive overhead for anyone who
| needs to work on those services. You know the old adage: once
| you provide something in the API, you'll have to support it
| forever.
___________________________________________________________________
(page generated 2023-08-16 23:01 UTC)