45 ms·

I feel you haven't taken a look at Java in the enterprise in a long time. Spring is considered to be an overloaded bloated mess and Java EE has become lean and

I feel you haven't taken a look at Java in the enterprise in a long time. Spring is considered to be an overloaded bloated mess and Java EE has become lean and mean with plenty of very capable specifications and implementations (JPA, CDI, etc...). And FYI, the Design Patterns book came out before Java (1994 vs/ 1995) so I think you have your timelines confused. The early editions of Design Patterns didn't contain a single line of Java, they were mostly C++ (and some Smalltalk). Java is twenty years old, and for such an old geezer, it's adapted remarkably well (and between Java 8 and Kotlin picking momentum, its legacy seems to be well assured).

niftich 10y ago
I was trying to express a lot of ideas in a small space, and I have edited it since, but it's still not as clear as I'd like. You and I agree, but I have struggled to get this point across. Spring is a bloated mess, but when it first came out it was lean new framework and a relief from EJBv1 and EJBv2. In response, EJBv3 was much better, but in the meantime Spring became the new normal, and grew into some strange swiss army chainsaw glue with now-deprecated awful xml configuration replaced by the horror of not-quite-code-but-compiled-into-the-classfile @Annotations! The 'new Spring' is Spring Boot, which was a response to this then-obscure framework called Dropwizard which showed that all you had to do was pick a handful of very good libraries get work done. Guava, Jersey, Jackson, Jetty; some decent ORM, and you're good to go. Some of these are backed by new Java specs like JAX-RS and JPA that are legitimately pretty good. I think the biggest problem Java still has in the hearts and minds of people outside the 'enterprise' is not because of Java, but because of the complexities that only manifest in environments where your code isn't 100% greenfield every time. Dependency Injection isn't something you realize you need until you realize you need it -- and then you realize you need it Really Badly. Externalized XML config files declaring reusable beans isn't something you think you need until your client is asking how they can reconfigure something in the shipped software when they can't just recompile it to what they need.
- hota_mazi 10y ago
  Agreed, I think you and I have very similar views on the JVM/JaveEE/Spring situation.
- EtienneK 10y ago
  Spring Boot is very good. I can't imagine writing enterprise Java code without it anymore.
  - atomashpolskiy 10y ago
    You might want to try out http://bootique.io http://bootique.io, it's even better in many aspects
- reitanqild 10y ago
  > the horror of not-quite-code-but-compiled-into-the-classfile @Annotations! I really don't get the hate to annotations. They have saved me lots of hours since 2009 and at close to zero cost. What's not to like?
  - niftich 10y ago
    Since they're compiled into the code, it means you can't change them without recompiling, so they're not actually configuration. But they're not actually code either, so they can't be subclassed or inherited, don't support generics, and have other quirks [1]. Furthermore, they are a sort of explicit notation to make you feel like you're getting 'convention' over 'configuration', but if it were truly convention you wouldn't need them in the first place. For example, to teach my class how to serialize itself into JSON, I can compile com.fasterxml.jackson annotations into it, but by doing so I've made a particular JSON library a dependency of myproject-datatypes. I'd rather my myproject-controller or some other layer of my application take care of how the data looks over JSON. Luckily Jackson supports an entirely different way [2] of teaching it how to map a class, but not all libraries are so nice. That is not to say annotations don't have their place. They're good declarative structures, but in my opinion they are used in places where they shouldn't be. This blog post [3] from 2009 accurately describes how I feel about annotations. [1] http://www.cowtowncoder.com/blog/archives/2009/02/entry_216.html http://www.cowtowncoder.com/blog/archives/2009/02/entry_216.... [2] https://github.com/FasterXML/jackson-docs/wiki/JacksonMixInAnnotations https://github.com/FasterXML/jackson-docs/wiki/JacksonMixInA... [2] http://naildrivin5.com/blog/2009/03/11/java-annotations-javas-love-of-configuration-over-convention.html http://naildrivin5.com/blog/2009/03/11/java-annotations-java...
    - hota_mazi 10y ago
      Annotations are data about the code. The fact that you can't change them without recompiling the code is a feature, not a bug. If you want that kind of flexibility, use external files (e.g. XML) but now the two can get out of sync, which is what is commonly referred to as XML hell. The rule of thumb is simple: whenever you need to add information about something in your source (class, method, field, package), use an annotation. If you need to add information about something that is not source code (port, host, various sizes, etc...) then use an external file. In particular, if you specify a reference to Java code in your XML, you should use an annotation instead.
- LoSboccacc 10y ago
  Each tech it's use. Annotations are great for class metadata - JPA or beans binding or servlets and filter paths. Externalizing binding was the kind of nice thing that almost never quite worked right. XML (or YAML because sysads are people too) for configurable parts is ok, but if you need to mix and match services it was never ever needed. The binding API allowed that years before spring style of depencency injection brought madness into the enterprise world and in a extremely better and clean way, using the facilities of the language instead of creating ugly reflective glue that kind of worked
- jacques_chester 10y ago
  > which was a response to this then-obscure framework called Dropwizard I sat in with an AMA in NYC with Dave Syer. He said it was inspired by a project he was co-opted to which used Rails. Not the actual architecture of Rails, mind you, but the "just works", out-of-the-box, no-configuration experience. Disclosure: I work for Pivotal. So do many of Spring's core committers. There's a lot of feedback from Labs and Cloud R&D into Spring, but they're still a largely self-directed team.
  - niftich 10y ago
    Trying to upvote this because it's good info! But, but, I have one better :) Spring Boot 1.0 GA Released [1] blog post, says, and links to a Spring Issue SPR-9888: "It's been 18 months since the original request [2] to "improve containerless web application architectures", that gave birth to Spring Boot, was raised." The body of the original issue [2] says, midway down: "I think that Spring's web application architecture can be significantly simplified if it were to provided tools and a reference architecture that leveraged the Spring component and configuration model from top to bottom. Embedding and unifying the configuration of those common web container services within a Spring Container bootstrapped from a simple main() method. Though there are many frameworks and platforms today that no longer require a container I think inspiration can be drawn most from DropWizard (http://dropwizard.codahale.com/ http://dropwizard.codahale.com/). Another project I've seen inspired by DropWizard but leveraging Spring is HalfPipe (https://github.com/32degrees/halfpipe https://github.com/32degrees/halfpipe). Though I don't think HalfPipe goes far enough. I think to truly provide simplification the entire architecture, wherever reasonable, must be embedded within the Spring container rather than without. Though it does have several other interesting ideas." [1] https://spring.io/blog/2014/04/01/spring-boot-1-0-ga-released https://spring.io/blog/2014/04/01/spring-boot-1-0-ga-release... [2] https://jira.spring.io/browse/SPR-9888 https://jira.spring.io/browse/SPR-9888
    - jacques_chester 10y ago
      It could absolutely be both. Dave Syer is not the only person who drove Spring Boot. Phil Webb is the main day-to-day driver, from what I can tell. He's definitely been active in soliciting feedback from Labs Pivots.
- slantedview 10y ago
  > The 'new Spring' is Spring Boot, which was a response to this then-obscure framework called Dropwizard This is correct, but what pisses me off is that the Spring folks clearly copied Dropwizard, then failed to even mention Dropwizard in their various docs, blogs, talks, etc, which you're thinking is fine. But they DO mention other (less useful) projects as supposed alternatives for Spring Boot, essentially, pretending as if Dropwizard doens't even exist when clearly it's the reason that Spring Boot exists! Shameful. Spring hails Boot as the new way of doing things, but it's still by no means a clean break for the rest of the Spring ecosystem where programming by XML (or annotations) is still king and the APIs are still a horrible, overcomplicated mess. There's no undoing that.
twic 10y ago
> I feel you haven't taken a look at Java in the enterprise in a long time. > > Spring is considered to be an overloaded bloated mess and Java EE has become lean and mean I agree with those descriptions, but we have very different experiences of Java in the enterpris. In the companies i work with, EE still means older specifications, and Spring, for all its flaws, comes in as a breath of fresh air.

niftich 10y ago

I was trying to express a lot of ideas in a small space, and I have edited it since, but it's still not as clear as I'd like. You and I agree, but I have struggled to get this point across. Spring is a bloated mess, but when it first came out it was lean new framework and a relief from EJBv1 and EJBv2. In response, EJBv3 was much better, but in the meantime Spring became the new normal, and grew into some strange swiss army chainsaw glue with now-deprecated awful xml configuration replaced by the horror of not-quite-code-but-compiled-into-the-classfile @Annotations! The 'new Spring' is Spring Boot, which was a response to this then-obscure framework called Dropwizard which showed that all you had to do was pick a handful of very good libraries get work done. Guava, Jersey, Jackson, Jetty; some decent ORM, and you're good to go. Some of these are backed by new Java specs like JAX-RS and JPA that are legitimately pretty good. I think the biggest problem Java still has in the hearts and minds of people outside the 'enterprise' is not because of Java, but because of the complexities that only manifest in environments where your code isn't 100% greenfield every time. Dependency Injection isn't something you realize you need until you realize you need it -- and then you realize you need it Really Badly. Externalized XML config files declaring reusable beans isn't something you think you need until your client is asking how they can reconfigure something in the shipped software when they can't just recompile it to what they need.

hota_mazi 10y ago
Agreed, I think you and I have very similar views on the JVM/JaveEE/Spring situation.
EtienneK 10y ago
Spring Boot is very good. I can't imagine writing enterprise Java code without it anymore.
- atomashpolskiy 10y ago
  You might want to try out http://bootique.io http://bootique.io, it's even better in many aspects
reitanqild 10y ago
> the horror of not-quite-code-but-compiled-into-the-classfile @Annotations! I really don't get the hate to annotations. They have saved me lots of hours since 2009 and at close to zero cost. What's not to like?
- niftich 10y ago
  Since they're compiled into the code, it means you can't change them without recompiling, so they're not actually configuration. But they're not actually code either, so they can't be subclassed or inherited, don't support generics, and have other quirks [1]. Furthermore, they are a sort of explicit notation to make you feel like you're getting 'convention' over 'configuration', but if it were truly convention you wouldn't need them in the first place. For example, to teach my class how to serialize itself into JSON, I can compile com.fasterxml.jackson annotations into it, but by doing so I've made a particular JSON library a dependency of myproject-datatypes. I'd rather my myproject-controller or some other layer of my application take care of how the data looks over JSON. Luckily Jackson supports an entirely different way [2] of teaching it how to map a class, but not all libraries are so nice. That is not to say annotations don't have their place. They're good declarative structures, but in my opinion they are used in places where they shouldn't be. This blog post [3] from 2009 accurately describes how I feel about annotations. [1] http://www.cowtowncoder.com/blog/archives/2009/02/entry_216.html http://www.cowtowncoder.com/blog/archives/2009/02/entry_216.... [2] https://github.com/FasterXML/jackson-docs/wiki/JacksonMixInAnnotations https://github.com/FasterXML/jackson-docs/wiki/JacksonMixInA... [2] http://naildrivin5.com/blog/2009/03/11/java-annotations-javas-love-of-configuration-over-convention.html http://naildrivin5.com/blog/2009/03/11/java-annotations-java...
  - hota_mazi 10y ago
    Annotations are data about the code. The fact that you can't change them without recompiling the code is a feature, not a bug. If you want that kind of flexibility, use external files (e.g. XML) but now the two can get out of sync, which is what is commonly referred to as XML hell. The rule of thumb is simple: whenever you need to add information about something in your source (class, method, field, package), use an annotation. If you need to add information about something that is not source code (port, host, various sizes, etc...) then use an external file. In particular, if you specify a reference to Java code in your XML, you should use an annotation instead.
LoSboccacc 10y ago
Each tech it's use. Annotations are great for class metadata - JPA or beans binding or servlets and filter paths. Externalizing binding was the kind of nice thing that almost never quite worked right. XML (or YAML because sysads are people too) for configurable parts is ok, but if you need to mix and match services it was never ever needed. The binding API allowed that years before spring style of depencency injection brought madness into the enterprise world and in a extremely better and clean way, using the facilities of the language instead of creating ugly reflective glue that kind of worked
jacques_chester 10y ago
> which was a response to this then-obscure framework called Dropwizard I sat in with an AMA in NYC with Dave Syer. He said it was inspired by a project he was co-opted to which used Rails. Not the actual architecture of Rails, mind you, but the "just works", out-of-the-box, no-configuration experience. Disclosure: I work for Pivotal. So do many of Spring's core committers. There's a lot of feedback from Labs and Cloud R&D into Spring, but they're still a largely self-directed team.
- niftich 10y ago
  Trying to upvote this because it's good info! But, but, I have one better :) Spring Boot 1.0 GA Released [1] blog post, says, and links to a Spring Issue SPR-9888: "It's been 18 months since the original request [2] to "improve containerless web application architectures", that gave birth to Spring Boot, was raised." The body of the original issue [2] says, midway down: "I think that Spring's web application architecture can be significantly simplified if it were to provided tools and a reference architecture that leveraged the Spring component and configuration model from top to bottom. Embedding and unifying the configuration of those common web container services within a Spring Container bootstrapped from a simple main() method. Though there are many frameworks and platforms today that no longer require a container I think inspiration can be drawn most from DropWizard (http://dropwizard.codahale.com/ http://dropwizard.codahale.com/). Another project I've seen inspired by DropWizard but leveraging Spring is HalfPipe (https://github.com/32degrees/halfpipe https://github.com/32degrees/halfpipe). Though I don't think HalfPipe goes far enough. I think to truly provide simplification the entire architecture, wherever reasonable, must be embedded within the Spring container rather than without. Though it does have several other interesting ideas." [1] https://spring.io/blog/2014/04/01/spring-boot-1-0-ga-released https://spring.io/blog/2014/04/01/spring-boot-1-0-ga-release... [2] https://jira.spring.io/browse/SPR-9888 https://jira.spring.io/browse/SPR-9888
  - jacques_chester 10y ago
    It could absolutely be both. Dave Syer is not the only person who drove Spring Boot. Phil Webb is the main day-to-day driver, from what I can tell. He's definitely been active in soliciting feedback from Labs Pivots.
slantedview 10y ago
> The 'new Spring' is Spring Boot, which was a response to this then-obscure framework called Dropwizard This is correct, but what pisses me off is that the Spring folks clearly copied Dropwizard, then failed to even mention Dropwizard in their various docs, blogs, talks, etc, which you're thinking is fine. But they DO mention other (less useful) projects as supposed alternatives for Spring Boot, essentially, pretending as if Dropwizard doens't even exist when clearly it's the reason that Spring Boot exists! Shameful. Spring hails Boot as the new way of doing things, but it's still by no means a clean break for the rest of the Spring ecosystem where programming by XML (or annotations) is still king and the APIs are still a horrible, overcomplicated mess. There's no undoing that.

twic 10y ago

> I feel you haven't taken a look at Java in the enterprise in a long time. > > Spring is considered to be an overloaded bloated mess and Java EE has become lean and mean I agree with those descriptions, but we have very different experiences of Java in the enterpris. In the companies i work with, EE still means older specifications, and Spring, for all its flaws, comes in as a breath of fresh air.