171–180 of 259 posts
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?
However Quarkus and Micronaut are also quite appealing for small projects.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
If your development productivity is entirely reliant on how quickly you can reload your changes, then you're doing something wrong. Though I guess you'd have to write mounds of unit tests and constantly rerun them to prevent common issues that Java's type system solves for free.
Actually, Java, its syntax, the explicit types and how its often taught only obscure the solutions that could be much more obvious. Since I have seen Clojure, I was swearing why nobody has shown it to us right in the beginning when I was in the university. Back then, Clojure was already an established, stable language and that has been a decade. I could just skip the C, Java and other classes and would be a much bett…
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…
This is true in most languages really. It starts with people just wanting to speed up their development by turning common tasks into some macro, or annotation, or even library. But where does it end? It ends in a convoluted mess of dependencies, weird syntax, and hopeless stack traces. So much work can be done with plain old Java. Or plain old JavaScript. Or plain old C + stdlib.
Earlier quoted context omitted.
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.
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…
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…
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 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.
Earlier quoted context omitted.
It is interesting Java was supposed to be write once run anywhere already some 20 years ago.
You do realize the paradigm shift that enable language polyglotism? It is nothing like WORA
It didn't quite pan out that way, but back then OOP was "the future" and everyone sort of assumed that only the classic style of OOP will ever be needed in the future.
Earlier quoted context omitted.
> 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 What does "decoupled" even mean anymore? That sounds like the opposite of "decoupled" to me. (/not a Java programmer).
Everything is wired up using Dependency Injection. So you just state your claims and are given appropriate objects that may be created by some third party factory factory. It's really neat until it isnt.
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…
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…