5 ms·

I agree so much with this article. Java EE practices bloat programs, waste memory, and make debugging harder. Let alone all the language constructs. > Java all

I agree so much with this article. Java EE practices bloat programs, waste memory, and make debugging harder. Let alone all the language constructs. > Java allows null objects… that ship has sailed Not necessarily, with project Valhalla, it should be possible to have generic Value Types in the language that would allow things like Optional to be defined on the stack where it would be non-null and then all it’s methods for checking if the Object it references would make sense, and actually work. This would be in contrast to today where the Optional type isn’t as useful as it seems since it can also be null. Anyone know the status of this? https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_language) https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_langu...

democracy 4y ago
Java EE is not really a thing in the wild for long long time...
- bluejekyll 4y ago
  Spring and (and Quarkus apparently which I haven’t used) brought along a lot of the Java EE concepts. It lives on if not in name, in spirit. Thus the cultural problem this article discusses.
  - democracy 4y ago
    Well technically they are built on JEE APIs, but JEE is not a 10 page spec, so combining all of JEE into a pool of "horrible designs" would be somewhat naive.
- pjmlp 4y ago
  Not only it is still around, Spring actually depends on many of the same standards.
  - StevePerkins 4y ago
    This take is so exhausting. It really is, "Tell me that you know little about Java beyond forum comments that you've read, without telling me that you know little about Java beyond forum comments that you've read". The most important Java EE specifications (now "Jakarta EE", as "Java EE" hasn't existed for years), are: CDI, EJB, JPA, JTA, JMS, JAX-WS, JAX-RS, JSTL, JSP, and JavaMail. Of that list, a typical Spring Boot application in the wild miiiiiiight use JPA. And that is totally optional, with a handful of newer ORM frameworks seriously eating into its market share. Even JPA itself didn't come out of the "Java EE" world. Hibernate won the ORM wars back in the day, and so the Hibernate folks were allowed to write the JPA spec, making it near-identical to the existing Hibernate API. Spring has extensions that allow it to interface with nearly anything in the Java ecosystem (and its DI container makes it easy to write an integration to anything new). However, while it CAN interact with all of those Java EE API's, it doesn't NOT "depend" on them! The story of Spring's relationship to Java EE is the classic "embrace, extend, extinguish". Reddit and HN are able to grasp that pattern just fine when they are slamming Microsoft. However, they can't grasp get it in this context. I honestly believe that the vast majority of people's Java knowledge on Reddit and HN comes from ignorant comments that have been in a self-reinforcing recursive loop for years.
    - pjmlp 4y ago
      Most Spring deployments I have seen in the wild aren't using Spring Boot as such, rather Spring MVC, and yes they do depend on them on most enterprise shops. But what do I know, I only took part in the Nokia NetAct from CORBA Perl/C++ into Java EE migration, have done my share of Java projects since then, and nowadays all our projects tend to have a mix of Java and .NET, so guess I hardly see any Java code. /s
    - krzyk 4y ago
      > Of that list, a typical Spring Boot application in the wild miiiiiiight use JPA. And that is totally optional, with a handful of newer ORM frameworks seriously eating into its market share Could you cite some? Specifically any that encourages immutable objects (like records in entities).
      - 4y ago
willsmith72 4y ago
I've seen many other developers trash java because of the same reasons, often citing Go as a great alternative. The problem is, for every org I've seen, saving memory is not the goal of the program. "Making debugging harder" is subjective, and most people I've heard use this argument are taking about "magic auto configuration". Maybe this isn't intuitive at first, but the knowledge comes quickly, and from my experience the java app with unit and integration tests is far easier to debug than the Go app with less testing and less readable syntax. The memory argument is also way less applicable when using the author's framework, because your app is built into a native image. I know you didn't mention Go, but that's where I always see this argument headed, and it always makes me wonder whether the writers have ever had to maintain or take over an app written in Go, or if they can happily write-and-forget.
- bluejekyll 4y ago
  I don’t think we even need to discuss Go though. Just compare the ease of using vanilla Java to the complexity and magic that have become popular (mostly to work around limitations in the language). Being able to follow code easily is an important aspect of debugging a program, Spring and etc, obfuscate implementations. Are they still worth it to use? At this point for many orgs unwinding that would take years. That’s at least what I got out of the article, Java doesn’t necessarily need magic frameworks to have a good development environment, that resonates with my own experience.
  - willsmith72 4y ago
    Modern spring boot apps I've seen are actually really easy to debug. More often than not there isn't even an interface used, the dependency injection is just for having easily mockable unit tests. In my opinion it doesn't feel obfuscated or hard to debug, especially because the tests can be easy to read and write. In saying all this I normally use js or python for personal projects, it's just that I still see JVM projects specifically using these frameworks (spring, quarkus) working fantastically for long lived, enterprise apps
  - kaba0 4y ago
    I don’t know, I personally prefer a standard solution for common business requirements like validation, conversions that will be the same regardless of which project I choose over some custom-made ones. Another way to think of Spring’s magic is just declarative programming to a degree. You write what to validate based on rules, not the how.
Supermancho 4y ago
Forget the interface vs data structure (for which they provide little support), the final keyword is the horrific standout. Conspiring with the compiler to remove programmer agency, in the misguided effort to protect programmers from themselves, is ridiculous.

democracy 4y ago

Java EE is not really a thing in the wild for long long time...

bluejekyll 4y ago
Spring and (and Quarkus apparently which I haven’t used) brought along a lot of the Java EE concepts. It lives on if not in name, in spirit. Thus the cultural problem this article discusses.
- democracy 4y ago
  Well technically they are built on JEE APIs, but JEE is not a 10 page spec, so combining all of JEE into a pool of "horrible designs" would be somewhat naive.
pjmlp 4y ago
Not only it is still around, Spring actually depends on many of the same standards.
- StevePerkins 4y ago
  This take is so exhausting. It really is, "Tell me that you know little about Java beyond forum comments that you've read, without telling me that you know little about Java beyond forum comments that you've read". The most important Java EE specifications (now "Jakarta EE", as "Java EE" hasn't existed for years), are: CDI, EJB, JPA, JTA, JMS, JAX-WS, JAX-RS, JSTL, JSP, and JavaMail. Of that list, a typical Spring Boot application in the wild miiiiiiight use JPA. And that is totally optional, with a handful of newer ORM frameworks seriously eating into its market share. Even JPA itself didn't come out of the "Java EE" world. Hibernate won the ORM wars back in the day, and so the Hibernate folks were allowed to write the JPA spec, making it near-identical to the existing Hibernate API. Spring has extensions that allow it to interface with nearly anything in the Java ecosystem (and its DI container makes it easy to write an integration to anything new). However, while it CAN interact with all of those Java EE API's, it doesn't NOT "depend" on them! The story of Spring's relationship to Java EE is the classic "embrace, extend, extinguish". Reddit and HN are able to grasp that pattern just fine when they are slamming Microsoft. However, they can't grasp get it in this context. I honestly believe that the vast majority of people's Java knowledge on Reddit and HN comes from ignorant comments that have been in a self-reinforcing recursive loop for years.
  - pjmlp 4y ago
    Most Spring deployments I have seen in the wild aren't using Spring Boot as such, rather Spring MVC, and yes they do depend on them on most enterprise shops. But what do I know, I only took part in the Nokia NetAct from CORBA Perl/C++ into Java EE migration, have done my share of Java projects since then, and nowadays all our projects tend to have a mix of Java and .NET, so guess I hardly see any Java code. /s
  - krzyk 4y ago
    > Of that list, a typical Spring Boot application in the wild miiiiiiight use JPA. And that is totally optional, with a handful of newer ORM frameworks seriously eating into its market share Could you cite some? Specifically any that encourages immutable objects (like records in entities).
    - 4y ago

willsmith72 4y ago

I've seen many other developers trash java because of the same reasons, often citing Go as a great alternative. The problem is, for every org I've seen, saving memory is not the goal of the program. "Making debugging harder" is subjective, and most people I've heard use this argument are taking about "magic auto configuration". Maybe this isn't intuitive at first, but the knowledge comes quickly, and from my experience the java app with unit and integration tests is far easier to debug than the Go app with less testing and less readable syntax. The memory argument is also way less applicable when using the author's framework, because your app is built into a native image. I know you didn't mention Go, but that's where I always see this argument headed, and it always makes me wonder whether the writers have ever had to maintain or take over an app written in Go, or if they can happily write-and-forget.

bluejekyll 4y ago
I don’t think we even need to discuss Go though. Just compare the ease of using vanilla Java to the complexity and magic that have become popular (mostly to work around limitations in the language). Being able to follow code easily is an important aspect of debugging a program, Spring and etc, obfuscate implementations. Are they still worth it to use? At this point for many orgs unwinding that would take years. That’s at least what I got out of the article, Java doesn’t necessarily need magic frameworks to have a good development environment, that resonates with my own experience.
- willsmith72 4y ago
  Modern spring boot apps I've seen are actually really easy to debug. More often than not there isn't even an interface used, the dependency injection is just for having easily mockable unit tests. In my opinion it doesn't feel obfuscated or hard to debug, especially because the tests can be easy to read and write. In saying all this I normally use js or python for personal projects, it's just that I still see JVM projects specifically using these frameworks (spring, quarkus) working fantastically for long lived, enterprise apps
- kaba0 4y ago
  I don’t know, I personally prefer a standard solution for common business requirements like validation, conversions that will be the same regardless of which project I choose over some custom-made ones. Another way to think of Spring’s magic is just declarative programming to a degree. You write what to validate based on rules, not the how.

Supermancho 4y ago

Forget the interface vs data structure (for which they provide little support), the final keyword is the horrific standout. Conspiring with the compiler to remove programmer agency, in the misguided effort to protect programmers from themselves, is ridiculous.