3 ms·

Java EE and Spring Boot are two different things, so I'm a little confused about what you're getting at. Historically Java EE (eg, Enterprise Java Beans and all

Java EE and Spring Boot are two different things, so I'm a little confused about what you're getting at. Historically Java EE (eg, Enterprise Java Beans and all of their accoutrements) was considered very complex, and Spring was the "simpler, easier" alternative. There's no question that as the scope of Spring grew things got somewhat more complex, but honestly, I still find Spring Boot and Spring based Java web apps fairly simple. You write Controllers and use a few annotations to define the context path, urls to individual endpoints, inputs/outputs of the various endpoints, etc. All those things have to be defined somewhere no matter what platform you use, no? The only part I find maybe just a touch annoying is the Spring Data JPA stuff. It's not conceptually difficult, and truth be told the CrudRepository stuff makes it dead simple to make basic repository instances. But the configuration is just fiddly/tedious enough to be ever so slightly off-putting. But even on that, you can create a project once with all of that setup, save it off to the side as a template, and just copy that anytime you need it in the future (this is, in fact, exactly what I do). I dunno... all in all, Spring Boot seems mostly fine to me. Grails is arguably a little bit simpler but that's still just Spring Boot with some syntactic sugar layered on top to handle the common cases.

sriram_malhar 5y ago
(Sorry, I meant to say enterprise, but wrote EE by mistake). It was frustrating to see the weight of the whole edifice. Running gradlew on the sample one-controller Spring boot tutorial app took 12 minutes to download and compile. The stack trace shows 50 function calls(!) all the way down to Thread.run. The startup of this simple app takes 3 seconds on my mac. The equivalent code in golang frameworks seems so much more direct.
- mindcrime 5y ago
  Sure, it's going to take a while the first time, because your gradle cache hasn't be populated yet. You should find subsequent builds to be much, much faster. If not, something is wrong with your setup. Startup time? I personally don't care about startup time for a long-running server process; at least not if we're just talking a few seconds. The JVM is better at optimizing long-running processes than things that are starting and stopping frequently (although to be fair, JVM cold startup time has improved dramatically in later JVM releases). Anyway... if you'd rather write Go, then write Go. Presumably nobody has a gun to your head making you work with Spring / Java. shrug
  - sriram_malhar 5y ago
    Thanks for your response. Alas, Go is not an option for me ... I only have access to Java programmers. They know Spring Boot better than I do, but their systems reek of complexity, and I suspect that is because there is a huge weight of enterprise practices that they feel they should conform to. For example, in a latency critical path, I identified 4 microservices in a chain; it seemed to me that all one needs in that situation -- they all have similar scaling needs -- is a simple modular structure where one module enqueues an in-memory request for the next task in the chain. No json, no network etc. Their response? "Monolith bad, microservice good". If you want microservice, spring boot it is. And they must be packaged with docker, and managed by a cluster manager. I blame the complexity of these enterprise models because they lead these engineers to believe that simple solutions are not possible.
    - mindcrime 5y ago
      Fair enough.

sriram_malhar 5y ago

(Sorry, I meant to say enterprise, but wrote EE by mistake). It was frustrating to see the weight of the whole edifice. Running gradlew on the sample one-controller Spring boot tutorial app took 12 minutes to download and compile. The stack trace shows 50 function calls(!) all the way down to Thread.run. The startup of this simple app takes 3 seconds on my mac. The equivalent code in golang frameworks seems so much more direct.

mindcrime 5y ago
Sure, it's going to take a while the first time, because your gradle cache hasn't be populated yet. You should find subsequent builds to be much, much faster. If not, something is wrong with your setup. Startup time? I personally don't care about startup time for a long-running server process; at least not if we're just talking a few seconds. The JVM is better at optimizing long-running processes than things that are starting and stopping frequently (although to be fair, JVM cold startup time has improved dramatically in later JVM releases). Anyway... if you'd rather write Go, then write Go. Presumably nobody has a gun to your head making you work with Spring / Java. shrug
- sriram_malhar 5y ago
  Thanks for your response. Alas, Go is not an option for me ... I only have access to Java programmers. They know Spring Boot better than I do, but their systems reek of complexity, and I suspect that is because there is a huge weight of enterprise practices that they feel they should conform to. For example, in a latency critical path, I identified 4 microservices in a chain; it seemed to me that all one needs in that situation -- they all have similar scaling needs -- is a simple modular structure where one module enqueues an in-memory request for the next task in the chain. No json, no network etc. Their response? "Monolith bad, microservice good". If you want microservice, spring boot it is. And they must be packaged with docker, and managed by a cluster manager. I blame the complexity of these enterprise models because they lead these engineers to believe that simple solutions are not possible.
  - mindcrime 5y ago
    Fair enough.