5 ms·

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).
    - kaba0 4y ago
      Not sure whether it is an ORM, but some people like JOOQ quite a bit.
      - krzyk 4y ago
        Yes I heard that, but it has other issues - code generation :( And AFAIR it needs a license for usage with Oracle, and getting approvals for something like that in a corp is PITA.
        kaba0 4y ago
        Code generation is not necessary, just makes it more typesafe and comfortable to use AFAIK. And yeah, its licensing is basically it is free for open-source dbs, paid otherwise.
        62951413 4y ago
        I believe there's a pretty common approach implied here that assumes that SQL DDL is what you start from. It's nicely aligned with how RDBMS schema changes are usually applied too (i.e. a DDL script to make changes and possibly another to roll them back): * define you DB schema in a SQL script under version control * apply the script to your local DB instance, re-generate JOOQ classes (under version control too) * update the service logic * commit all the changes * in prod, apply the script and then re-deploy the code

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).
  - kaba0 4y ago
    Not sure whether it is an ORM, but some people like JOOQ quite a bit.
    - krzyk 4y ago
      Yes I heard that, but it has other issues - code generation :( And AFAIR it needs a license for usage with Oracle, and getting approvals for something like that in a corp is PITA.
      - kaba0 4y ago
        Code generation is not necessary, just makes it more typesafe and comfortable to use AFAIK. And yeah, its licensing is basically it is free for open-source dbs, paid otherwise.
      - 62951413 4y ago
        I believe there's a pretty common approach implied here that assumes that SQL DDL is what you start from. It's nicely aligned with how RDBMS schema changes are usually applied too (i.e. a DDL script to make changes and possibly another to roll them back): * define you DB schema in a SQL script under version control * apply the script to your local DB instance, re-generate JOOQ classes (under version control too) * update the service logic * commit all the changes * in prod, apply the script and then re-deploy the code