9 ms·

> So Java is not only the safe choice for serious server-side software; it's also the bleeding edge. Sure for core Java (OpenJDK), but what the future of JEE l

> So Java is not only the safe choice for serious server-side software; it's also the bleeding edge. Sure for core Java (OpenJDK), but what the future of JEE licensing and development? Even non-"enterprise" apps typically make use of some JEE stuff like servlets and JDBC. Is it really the "safe" choice when, apparently, the trademark agreements have just fallen apart? https://headcrashing.wordpress.com/2019/05/03/negotiations-failed-how-oracle-killed-java-ee/ https://headcrashing.wordpress.com/2019/05/03/negotiations-f...

ses1984 7y ago
Pardon my ignorance but what does any of that trademark stuff have to do with jdbc?
lenkite 7y ago
JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.
- 0db532a0 7y ago
  How are Java programmers implementing RESTFUL APIs these days?
  - atoko 7y ago
    Spring Boot with Webflux and any rx supporting libraries you can get your hands on
    - 0db532a0 7y ago
      Thanks.
  - lenkite 7y ago
    Many developers don't want to think too much and generally choose Spring boot for a stable, highly-popular and well-documented framework. There is nothing wrong with this choice but I find it too bloated for lean container based micro-services. Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also a good choice. You can also choose not to use a framework and say use code-generation from a swagger/openAPI REST document and implement the remaining bits on your own. If your deployment target is AWS, you can also choose to leverage Netflix's fantastic set of libraries. Java has tonnes of options, so you usually need to spend some time evaluating what goes into your stack.
    - jjjensen90 7y ago
      I'm curious to hear what specifically is too bloated in Spring Boot in your opinion for container based microservices. I've been writing microservices that run in docker in Java for a few years, then moved to Kotlin recently, all using Spring Boot, and I haven't run into anything that made me feel like they were bloated. I've also written Go and Node microservices for contrast.
      - lenkite 7y ago
        Spring boot has a large startup time, heavy dependency trail and a lot of dynamic class-loading based off auto-configuration. This makes it un-suitable for some areas: if you desire fast scaling micro-services that respond quickly to incoming load. Or say you want to transform your micro-service to a server-less function. One can do that with Graal VM to compile your micro-service to a single binary with microscopic start-up time. However, native-image tends to fail more often than not with Spring boot apps. (I haven't tried this recently though so my knowledge could be out of date).
        jacques_chester 7y ago
        Spring Boot does what it's asked to do, which is to load everything it finds. The dynamic class work has basically nil effect on load time. The core performance constraint is that classes are loaded essentially linearly. If you ship with something enormous like Hibernate, that's thousands of files read individually from a zipfile. Spring folks are actively involved with Graal. I see a lot of excitement internally at Pivotal. Watch this space.
  - BoyRobot777 7y ago
    You should checkout new RedHat framework - [Quarkus](https://quarkus.io/ https://quarkus.io/). This is a framework which leverages Graal to create native images. Those images are very small and optimized. For example one of Quarkus developers showcase the size of native image, spoilers - it's [19MB](https://youtu.be/BcPLbhC9KAA?t=103 https://youtu.be/BcPLbhC9KAA?t=103). It takes 0,004s to start. In [this](https://youtu.be/7G_r1iyrn2c?t=3104 https://youtu.be/7G_r1iyrn2c?t=3104) session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).
    - dlandis 7y ago
      Looks very interesting although unfortunate they went with Maven over Gradle.
      - evacchi 7y ago
        they do support gradle https://quarkus.io/guides/gradle-tooling https://quarkus.io/guides/gradle-tooling
      - deleted 7y ago
        [deleted]
      - deleted 7y ago
        [deleted]
  - matwood 7y ago
    Spring boot + jOOQ for RDMS support.
  - CountHackulus 7y ago
    I can't speak for others, but I work in games and we've spun up a bunch of servers and we use Netty/Jersey for REST and sockets. It's been incredibly stable and a joy to program for compared to our previous Node servers. Granted we were using bleeding-edge Node 5 years ago which is not the Node of today.
  - gerbilly 7y ago
    https://www.dropwizard.io/ https://www.dropwizard.io/ Quoting from the site: Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services. It's a nice microframework which comes with built in health-checks, and metrics and it's also ops friendly because it deploys as a single JAR file.
    - guggle 7y ago
      Not really related to Dropwizard but... this: > mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=[REPLACE WITH A VALID DROPWIZARD VERSION] Why is it that everytime I read something about Java I have a feeling it was not meant for humans ? Not as bad as C++ projects setup though, I'll give it that.
      - gerbilly 7y ago
        I don't use maven archetypes too often, the rest of maven seems pretty good to me, but maybe I'm just used to it. I have done a lot more Java than Javascript, so I feel the same about npm error messages.
        guggle 7y ago
        Don't get me started on js/npm stuff...
  - meddlepal 7y ago
    I use javalin.io which was written by one if the maintainers of sparkjava (not to be confused with Apache Spark). I'm a big fan.
pron 7y ago
I know little about EE (and I'm certainly not speaking for anyone but myself), but I believe Java EE has lost dominance not because of any corporate decision, but because it simply started losing ground to unstandardized open source projects [1], as opposed to EE's JCP. So people who liked EE wanted to ditch the slow-moving JCP in favor of a faster process, and one question was whether the new project will be able to change specifications of namespaces that are traditionally reserved to, and associated with, the JCP. In the end it was decided that no, they will not be able to change JCP namespaces (but can choose to maintain them until the end of time in addition to any innovation they do outside of JCP namespaces). The decision obviously disappointed some, but I don't think it's viewed as catastrophic (although some may think so). And I don’t think that the “negotiations have failed” so much as that either side wasn’t able to achieve what they believed was the best outcome for them, but an agreement has been made. You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex. But now everyone can move on. I, for one, am curious to see how Jakarta EE's current approach of what seems to be an internet-based, democratic semi-standard would work out, and if it can be better than both the JCP as well as more common centrally-controlled open-source projects. Anyway, this is what Eclipse's director said on the matter: https://twitter.com/mmilinkov/status/1125213654775889921 https://twitter.com/mmilinkov/status/1125213654775889921 [1]: That post you linked to reminds me of those who blame Oracle for killing Solaris. Solaris is a terrific operating system, that was sadly killed by Linux long before Oracle acquired Sun. After a few years of trying, I guess Oracle decided they could no longer save it, and there was no point in continuing to throw good money after bad.
- dlandis 7y ago
  > You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex. Yes exactly, I think that is what makes if feel like not the safest choice for many companies.
  - 7y ago

ses1984 7y ago

Pardon my ignorance but what does any of that trademark stuff have to do with jdbc?

lenkite 7y ago

JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.

0db532a0 7y ago
How are Java programmers implementing RESTFUL APIs these days?
- atoko 7y ago
  Spring Boot with Webflux and any rx supporting libraries you can get your hands on
  - 0db532a0 7y ago
    Thanks.
- lenkite 7y ago
  Many developers don't want to think too much and generally choose Spring boot for a stable, highly-popular and well-documented framework. There is nothing wrong with this choice but I find it too bloated for lean container based micro-services. Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also a good choice. You can also choose not to use a framework and say use code-generation from a swagger/openAPI REST document and implement the remaining bits on your own. If your deployment target is AWS, you can also choose to leverage Netflix's fantastic set of libraries. Java has tonnes of options, so you usually need to spend some time evaluating what goes into your stack.
  - jjjensen90 7y ago
    I'm curious to hear what specifically is too bloated in Spring Boot in your opinion for container based microservices. I've been writing microservices that run in docker in Java for a few years, then moved to Kotlin recently, all using Spring Boot, and I haven't run into anything that made me feel like they were bloated. I've also written Go and Node microservices for contrast.
    - lenkite 7y ago
      Spring boot has a large startup time, heavy dependency trail and a lot of dynamic class-loading based off auto-configuration. This makes it un-suitable for some areas: if you desire fast scaling micro-services that respond quickly to incoming load. Or say you want to transform your micro-service to a server-less function. One can do that with Graal VM to compile your micro-service to a single binary with microscopic start-up time. However, native-image tends to fail more often than not with Spring boot apps. (I haven't tried this recently though so my knowledge could be out of date).
      - jacques_chester 7y ago
        Spring Boot does what it's asked to do, which is to load everything it finds. The dynamic class work has basically nil effect on load time. The core performance constraint is that classes are loaded essentially linearly. If you ship with something enormous like Hibernate, that's thousands of files read individually from a zipfile. Spring folks are actively involved with Graal. I see a lot of excitement internally at Pivotal. Watch this space.
- BoyRobot777 7y ago
  You should checkout new RedHat framework - [Quarkus](https://quarkus.io/ https://quarkus.io/). This is a framework which leverages Graal to create native images. Those images are very small and optimized. For example one of Quarkus developers showcase the size of native image, spoilers - it's [19MB](https://youtu.be/BcPLbhC9KAA?t=103 https://youtu.be/BcPLbhC9KAA?t=103). It takes 0,004s to start. In [this](https://youtu.be/7G_r1iyrn2c?t=3104 https://youtu.be/7G_r1iyrn2c?t=3104) session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).
  - dlandis 7y ago
    Looks very interesting although unfortunate they went with Maven over Gradle.
    - evacchi 7y ago
      they do support gradle https://quarkus.io/guides/gradle-tooling https://quarkus.io/guides/gradle-tooling
    - deleted 7y ago
      [deleted]
    - deleted 7y ago
      [deleted]
- matwood 7y ago
  Spring boot + jOOQ for RDMS support.
- CountHackulus 7y ago
  I can't speak for others, but I work in games and we've spun up a bunch of servers and we use Netty/Jersey for REST and sockets. It's been incredibly stable and a joy to program for compared to our previous Node servers. Granted we were using bleeding-edge Node 5 years ago which is not the Node of today.
- gerbilly 7y ago
  https://www.dropwizard.io/ https://www.dropwizard.io/ Quoting from the site: Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services. It's a nice microframework which comes with built in health-checks, and metrics and it's also ops friendly because it deploys as a single JAR file.
  - guggle 7y ago
    Not really related to Dropwizard but... this: > mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=[REPLACE WITH A VALID DROPWIZARD VERSION] Why is it that everytime I read something about Java I have a feeling it was not meant for humans ? Not as bad as C++ projects setup though, I'll give it that.
    - gerbilly 7y ago
      I don't use maven archetypes too often, the rest of maven seems pretty good to me, but maybe I'm just used to it. I have done a lot more Java than Javascript, so I feel the same about npm error messages.
      - guggle 7y ago
        Don't get me started on js/npm stuff...
- meddlepal 7y ago
  I use javalin.io which was written by one if the maintainers of sparkjava (not to be confused with Apache Spark). I'm a big fan.

pron 7y ago

I know little about EE (and I'm certainly not speaking for anyone but myself), but I believe Java EE has lost dominance not because of any corporate decision, but because it simply started losing ground to unstandardized open source projects [1], as opposed to EE's JCP. So people who liked EE wanted to ditch the slow-moving JCP in favor of a faster process, and one question was whether the new project will be able to change specifications of namespaces that are traditionally reserved to, and associated with, the JCP. In the end it was decided that no, they will not be able to change JCP namespaces (but can choose to maintain them until the end of time in addition to any innovation they do outside of JCP namespaces). The decision obviously disappointed some, but I don't think it's viewed as catastrophic (although some may think so). And I don’t think that the “negotiations have failed” so much as that either side wasn’t able to achieve what they believed was the best outcome for them, but an agreement has been made. You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex. But now everyone can move on. I, for one, am curious to see how Jakarta EE's current approach of what seems to be an internet-based, democratic semi-standard would work out, and if it can be better than both the JCP as well as more common centrally-controlled open-source projects. Anyway, this is what Eclipse's director said on the matter: https://twitter.com/mmilinkov/status/1125213654775889921 https://twitter.com/mmilinkov/status/1125213654775889921 [1]: That post you linked to reminds me of those who blame Oracle for killing Solaris. Solaris is a terrific operating system, that was sadly killed by Linux long before Oracle acquired Sun. After a few years of trying, I guess Oracle decided they could no longer save it, and there was no point in continuing to throw good money after bad.

dlandis 7y ago
> You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex. Yes exactly, I think that is what makes if feel like not the safest choice for many companies.
- 7y ago