8 ms·

Improved Docker Container Integration with Java 10

74 points by el_duderino 9y ago

chris_wot 9y ago
Genuine question: how many startups are using Java now? is this dealing with older sites that are stuck with Java on the server, or are there genuinely many new deployments of Java-based systems out there?
- deadc0de 9y ago
  JVM is pretty much running half of the internet.
- bebop 9y ago
  My company is not a startup, but we use Java heavily (also a good bit of python). Spring Framework is quite nice these days and being able to use Clojure pain free has been a nice bonus. Recently we have started a migration of our pipeline to Kubernetes, so these improvements are a real benefit to our use case.
- jryan49 9y ago
  Plenty. You'll find it in more enterprise-sy and older software shops, not so much startups. edit: sorry I mean other than startups you'll find plenty.
- dmux 9y ago
  We're currently using Groovy and Grails deployed within Docker containers to ECS.
- mbesto 9y ago
  Really depends on your definition of "startup". Either way, I'd say it's generally still popular for new projects - especially those where the path to product market fit is pretty clear.
- jrs95 9y ago
  Most startups in the Midwest are using Java in my experience. Since most of our job market is banks, insurance, etc there's just a lot of Java expertise.
- fredley 9y ago
  It depends what you've done and what you're going on to do. Spent your time so far as a Java developer, spotted a gap in the market for a tool for Java developers to do [x], then gone on to build a startup around it? I'm sure there's a fair few of those. And if there aren't it's probably an underserved market, there are plenty of very wealthy companies using Java.
- relics443 9y ago
  Almost every one that has an Android app :/ We're also moving ahead with our plan to replace node with the jvm for our backend.
  - Yhippa 9y ago
    Why are you replacing node?
    - relics443 9y ago
      1. Static typing without having to deal with TS 2 (main reason). Our codebase has turned into a disaster, and we realized that none of our node developers are senior despite what their resume says; our interview process was more geared towards hiring anyone than hiring well. We tried finding a more senior node engineer, but we couldn't given our time constraints, so I'm taking some of our actual senior engineers from our mobile team, and the consensus was that we wanted to work with Kotlin.
- actsasbuffoon 9y ago
  We use a bunch of different tech stacks, but there's some Java in there. In fact, I recently had to create a cross-platform desktop app, and I'm still not aware of a better option then the JVM. I would have preferred to write it in Scala, but opted for Java to make it easier for the rest of the team to maintain. Java isn't an awesome language, but it's fine. There's a lot of awful legacy Java code out in the wild, and I wouldn't want to work on it. But Java as a language is boring, inoffensive, and it works. As a result, it's probably going to be around for a long time.
  - joaomacp 9y ago
    > I recently had to create a cross-platform desktop app, and I'm still not aware of a better option then the JVM. What GUI library(ies) did you use? Just Swing? Java-FX as well? I'm curious about this - I've developed the macOS part of a desktop app, where the Windows part used WPF, and we shared C# code (.net core, so it would run in both platforms). The advantages were that each app looked 'native' to its OS. But in my opinion, the disadvantages outweighed them: a) No linux support. b) Double the work on the UI parts. The Java alternative would reverse this: no native-looking UI elements, but they would be done once and run everywhere, including Linux. Another alternative would be Electron, but I feel (though I'm not sure) Java would be more performant. Can anyone chime in on this? I know there's no definitive winner on this space...
    - actsasbuffoon 9y ago
      I just used JavaFX. It looks native everywhere, the tooling was good, and it works on Linux. I recommend taking a look. I've written almost no Java before this project, and I had never used JavaFX before. It took about 2 weeks to go from beginning to end on the project, which I was happy with.
      - vbezhenar 9y ago
        Oracle wants to drop JavaFX. I'm not sure about its future. It might be bright if someone wealthy would pick it up or dark if it'll end up in some apache catacombs. I would use Swing, it's very old, but it works and it's not going anywhere.
- ganonm 9y ago
  I am at an early stage startup which is using Java (and Kotlin) on the server-side. There are various reasons for this, most of them pragmatic, but also some technical ones. Pragmatic reasons: - Many engineers know Java to at least an intermediate level, so they can be productive quicker (and hiring is easier) - We had some existing libraries written in Java, so integrating them with the web platform was much easier if we went down the JVM route - Java is the language most familiar to members of the startup (including me, although I also have experience in RoR, Kotlin, ObjectiveC and JavaScript) Technical: - Java is generally very performant and running on the JVM means we don't generally have to worry about platform specific issues (there are well known exceptions of course e.g. file path issues) - The language itself is at a reasonable level of abstraction. It is strongly typed and IMO, writing a non-trivial backend in a dynamically typed language is a sub-optimal choice. It has a huge ecosystem of robust, battle tested libraries that are indispensable to us (e.g. JGraphT). There is a huge community - you are unlikely to run into 'uncharted' territory - It is popular to hate on Java but it really isn't that bad a language, especially if you aim to follow guidelines like those in Effective Java (probably my favourite programming book) e.g. avoiding mutable state and side-effects. It will never be as good as a modern language like Kotlin (data classes are my favourite feature there), but it is good enough - The server frameworks available are seriously robust and 'just work' - There is always the option of using alternative JVM languages (we use Kotlin for a large part of the backend) In summary, we are 6 months into developing the web platform, progress is rapid, and we have no regrets (yet) about the technology choices. IMO, sometimes boring is best.
  - chris_wot 9y ago
    I think people must think I hate Java. I don’t. I think it’s great and I love Spring, though I have been mostly programming in C++ so haven’t touched Java in a long while personally. I’m more concerned with the copyright status of Java APIs. Can you really be sure that you will be safe from Oracle’s clutches?
    - ganonm 9y ago
      I had assumed you weren't a fan, apologies for jumping to conclusions. The copyright concerns are valid - I've only followed the whole Oracle vs. Google litigation from a distance. I'm hoping the little guys like us won't be affected.
- chvid 9y ago
  I think if you count the JVM languages as one (Scala, Java, Kotlin, Groovy) it is the largest even for startups. (This article deals with a property of the JVM not really Java the language.)
- badpun 9y ago
  > are there genuinely many new deployments of Java-based systems out there? Java is absolutely huge in the corporate world, where they build new projects with it all the time.
- maltalex 9y ago
  > Genuine question: how many startups are using Java now? is this dealing with older sites that are stuck with Java on the server, or are there genuinely many new deployments of Java-based systems out there? Quite a few. It's a solid choice for a startup for a variety of reasons: - The Java (and more generally, the JVM) ecosystem is huge and includes stable, performant libraries and frameworks for just about every use case you can have. No need to re-invent the wheel. - Java as a language is mature and performant, but is still actively being improved. - No vendor lock-in. There are multiple implementations of everything including the JVM itself (unlike C# for example). - There are very good tools for developing, debugging and profiling JVM applications. - Some of the most popular big-data related tools are all based on the JVM. Just to name a few - Kafka (Scala), Hadoop (Java), Cassandra (Java), Spark (Scala), Ignite (Java), Elasticsearch (Java), Storm (Clojure), Neo4j (Java) and many more. So even if you're not using Java, you're probably using Java. - Android apps are JVM-based. So every startup with a native android app is writing Java (or Kotlin). - Hiring Java developers is easy(er). Everyone knows Java. Want to hire a junior developer? No problem. Want a veteran with 20 years of Jave experience? You can find those too. - Java is well supported - due to its popularity, vendors usually offer first class SDKs and support for Java developers. - There are many JVM-based languages. Don't like Java? No problem - you can use Clojure, Kotlin, Groovy, Scala, JRuby or even Jython. Some of them are even directly compatible with Java (and/or each other) so you can mix and match in some cases.
- specialist 9y ago
  FWIW, Java on the desktop is alive and well, including games and IDEs. For example, Spine is best in class 2D animator. http://esotericsoftware.com http://esotericsoftware.com
rhacker 9y ago
I can't seem to upgrade to Java 9 still. Its the module system. Waiting for open source to catch up in some situations. See one of the problems is that the way Java is started needs to change to enable JAXB. But many open source products have lots of code that start Java processes, and never use that command line. Did this change in Java 10, did they bring back JAXB so things will start again?
- SanderMak 9y ago
  Nope. In fact the module containing JAXB (and 5 other EE technologies) have been deprecated and will be removed in Java 11. So indeed, you can use the `--add-modules java.xml.bind` workaround, but it will break with Java 11. The real solution is to add a JAXB implementation of your choice as dependency to the application. (disclaimer: I'm author of the O'Reilly book Java 9 Modularity (see https://javamodularity.com https://javamodularity.com) which discusses this and other migration issues in great detail)
- krzyk 9y ago
  If you are using maven you can try following dependencies for JAXB from glassfish: <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-runtime</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-core</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.0</version> </dependency> As other commenter said, JAXB will disappear form Java 11 (and all other Java EE stubs that exist in Java SE) so it is better to upgrade sooner than later. And BTW, I would skip Java 9 and go straight to Java 10 now.
chenzhekl 9y ago
Could anyone point me to the advantages of running Java inside a Docker container? It seems to be VM in VM. Why do we need the extra redirection?
- AlphaSite 9y ago
  It’s not a VM, it’s faster and far lower overhead per container. Obviously it also looses some of the isolation guarantees.
- navaati 9y ago
  I see your point but Docker is not a VM, there is not a "redirection" cost or anything. So you can see it as a convenient way to distribute the JVM. Say that the JVM makes your application portable wrt the OS, Docker makes the JVM itself more portable.
- joeskyyy 9y ago
  A container is not a VM (at least in the traditional sense). The advantages of running java inside of a container is that you can ship all of your things as one artifact, and run it on a bunch of different infrastructures, with all it's dependencies packaged together. So rather than needing to use something to ensure your properties are configured correctly, and all your passwords are where they need to be, and all your other bits and such are in place, you can pack it all in a container and run it anywhere (Well... "anywhere" being a bit of a stretch, but you get the idea haha)
  - delecti 9y ago
    So Java, which was supposed to be "write once, run anywhere", didn't meet that goal enough, so Docker wraps it in something that "actually for real" is supposed to be "write once, run anywhere", but even then doesn't quite meet that goal?
    - inamberclad 9y ago
      And so, the cycle continues
e12e 9y ago
Is it me or does it seem odd that docker community edition is left out? And isn't adding an additional "silent c is for container" in front of cgroups a bit... Much? I mean, if java 10 recognises cgroup limits, that should work under things like systemd and all container runtimes?
- sofaofthedamned 9y ago
  I can't see how it's EE only. It reads the appropriate bits to work out the memory available, can't see how CE would hide that. The problem is wider than Java anyways. Containers see the system free memory, not what's available to that container regardless of the cgroup constraints. We've hit this many times and sometimes workarounds are available (mongodb) but sometimes they're not and in our k8s environment this means some pods will restart constantly when they try to cache over and above what their cgroup allows. The real fix is to tell a container not the system free memory but that which it's been allowed to use - afaik this is really difficult to implement, which is why the kernel hasn't had this done yet. EDIT: obvs the container could read the cgroup limits (which I assume is what Java 10 does) but all the userland tools would have to be changed as well as some kernel functions.
  - e12e 9y ago
    Hm, I wonder if this might possibly be related to an issue I've seen in production with docker - of a container being killed by the oom killer... But only on server boot.
    - sofaofthedamned 9y ago
      Maybe. We've had serious problems with this, mostly with mongodb but other stuff as well.Java 10 is making an effort to fix this but I hate Java, and really it's a kernel/userland linux issue as you can't expect software not to request cache memory that it doesn't know exists.

74 points by el_duderino 9y ago

Genuine question: how many startups are using Java now? is this dealing with older sites that are stuck with Java on the server, or are there genuinely many new deployments of Java-based systems out there?

deadc0de 9y ago
JVM is pretty much running half of the internet.
bebop 9y ago
My company is not a startup, but we use Java heavily (also a good bit of python). Spring Framework is quite nice these days and being able to use Clojure pain free has been a nice bonus. Recently we have started a migration of our pipeline to Kubernetes, so these improvements are a real benefit to our use case.
jryan49 9y ago
Plenty. You'll find it in more enterprise-sy and older software shops, not so much startups. edit: sorry I mean other than startups you'll find plenty.
dmux 9y ago
We're currently using Groovy and Grails deployed within Docker containers to ECS.
mbesto 9y ago
Really depends on your definition of "startup". Either way, I'd say it's generally still popular for new projects - especially those where the path to product market fit is pretty clear.
jrs95 9y ago
Most startups in the Midwest are using Java in my experience. Since most of our job market is banks, insurance, etc there's just a lot of Java expertise.
fredley 9y ago
It depends what you've done and what you're going on to do. Spent your time so far as a Java developer, spotted a gap in the market for a tool for Java developers to do [x], then gone on to build a startup around it? I'm sure there's a fair few of those. And if there aren't it's probably an underserved market, there are plenty of very wealthy companies using Java.
relics443 9y ago
Almost every one that has an Android app :/ We're also moving ahead with our plan to replace node with the jvm for our backend.
- Yhippa 9y ago
  Why are you replacing node?
  - relics443 9y ago
    1. Static typing without having to deal with TS 2 (main reason). Our codebase has turned into a disaster, and we realized that none of our node developers are senior despite what their resume says; our interview process was more geared towards hiring anyone than hiring well. We tried finding a more senior node engineer, but we couldn't given our time constraints, so I'm taking some of our actual senior engineers from our mobile team, and the consensus was that we wanted to work with Kotlin.
actsasbuffoon 9y ago
We use a bunch of different tech stacks, but there's some Java in there. In fact, I recently had to create a cross-platform desktop app, and I'm still not aware of a better option then the JVM. I would have preferred to write it in Scala, but opted for Java to make it easier for the rest of the team to maintain. Java isn't an awesome language, but it's fine. There's a lot of awful legacy Java code out in the wild, and I wouldn't want to work on it. But Java as a language is boring, inoffensive, and it works. As a result, it's probably going to be around for a long time.
- joaomacp 9y ago
  > I recently had to create a cross-platform desktop app, and I'm still not aware of a better option then the JVM. What GUI library(ies) did you use? Just Swing? Java-FX as well? I'm curious about this - I've developed the macOS part of a desktop app, where the Windows part used WPF, and we shared C# code (.net core, so it would run in both platforms). The advantages were that each app looked 'native' to its OS. But in my opinion, the disadvantages outweighed them: a) No linux support. b) Double the work on the UI parts. The Java alternative would reverse this: no native-looking UI elements, but they would be done once and run everywhere, including Linux. Another alternative would be Electron, but I feel (though I'm not sure) Java would be more performant. Can anyone chime in on this? I know there's no definitive winner on this space...
  - actsasbuffoon 9y ago
    I just used JavaFX. It looks native everywhere, the tooling was good, and it works on Linux. I recommend taking a look. I've written almost no Java before this project, and I had never used JavaFX before. It took about 2 weeks to go from beginning to end on the project, which I was happy with.
    - vbezhenar 9y ago
      Oracle wants to drop JavaFX. I'm not sure about its future. It might be bright if someone wealthy would pick it up or dark if it'll end up in some apache catacombs. I would use Swing, it's very old, but it works and it's not going anywhere.
ganonm 9y ago
I am at an early stage startup which is using Java (and Kotlin) on the server-side. There are various reasons for this, most of them pragmatic, but also some technical ones. Pragmatic reasons: - Many engineers know Java to at least an intermediate level, so they can be productive quicker (and hiring is easier) - We had some existing libraries written in Java, so integrating them with the web platform was much easier if we went down the JVM route - Java is the language most familiar to members of the startup (including me, although I also have experience in RoR, Kotlin, ObjectiveC and JavaScript) Technical: - Java is generally very performant and running on the JVM means we don't generally have to worry about platform specific issues (there are well known exceptions of course e.g. file path issues) - The language itself is at a reasonable level of abstraction. It is strongly typed and IMO, writing a non-trivial backend in a dynamically typed language is a sub-optimal choice. It has a huge ecosystem of robust, battle tested libraries that are indispensable to us (e.g. JGraphT). There is a huge community - you are unlikely to run into 'uncharted' territory - It is popular to hate on Java but it really isn't that bad a language, especially if you aim to follow guidelines like those in Effective Java (probably my favourite programming book) e.g. avoiding mutable state and side-effects. It will never be as good as a modern language like Kotlin (data classes are my favourite feature there), but it is good enough - The server frameworks available are seriously robust and 'just work' - There is always the option of using alternative JVM languages (we use Kotlin for a large part of the backend) In summary, we are 6 months into developing the web platform, progress is rapid, and we have no regrets (yet) about the technology choices. IMO, sometimes boring is best.
- chris_wot 9y ago
  I think people must think I hate Java. I don’t. I think it’s great and I love Spring, though I have been mostly programming in C++ so haven’t touched Java in a long while personally. I’m more concerned with the copyright status of Java APIs. Can you really be sure that you will be safe from Oracle’s clutches?
  - ganonm 9y ago
    I had assumed you weren't a fan, apologies for jumping to conclusions. The copyright concerns are valid - I've only followed the whole Oracle vs. Google litigation from a distance. I'm hoping the little guys like us won't be affected.
chvid 9y ago
I think if you count the JVM languages as one (Scala, Java, Kotlin, Groovy) it is the largest even for startups. (This article deals with a property of the JVM not really Java the language.)
badpun 9y ago
> are there genuinely many new deployments of Java-based systems out there? Java is absolutely huge in the corporate world, where they build new projects with it all the time.
maltalex 9y ago
> Genuine question: how many startups are using Java now? is this dealing with older sites that are stuck with Java on the server, or are there genuinely many new deployments of Java-based systems out there? Quite a few. It's a solid choice for a startup for a variety of reasons: - The Java (and more generally, the JVM) ecosystem is huge and includes stable, performant libraries and frameworks for just about every use case you can have. No need to re-invent the wheel. - Java as a language is mature and performant, but is still actively being improved. - No vendor lock-in. There are multiple implementations of everything including the JVM itself (unlike C# for example). - There are very good tools for developing, debugging and profiling JVM applications. - Some of the most popular big-data related tools are all based on the JVM. Just to name a few - Kafka (Scala), Hadoop (Java), Cassandra (Java), Spark (Scala), Ignite (Java), Elasticsearch (Java), Storm (Clojure), Neo4j (Java) and many more. So even if you're not using Java, you're probably using Java. - Android apps are JVM-based. So every startup with a native android app is writing Java (or Kotlin). - Hiring Java developers is easy(er). Everyone knows Java. Want to hire a junior developer? No problem. Want a veteran with 20 years of Jave experience? You can find those too. - Java is well supported - due to its popularity, vendors usually offer first class SDKs and support for Java developers. - There are many JVM-based languages. Don't like Java? No problem - you can use Clojure, Kotlin, Groovy, Scala, JRuby or even Jython. Some of them are even directly compatible with Java (and/or each other) so you can mix and match in some cases.
specialist 9y ago
FWIW, Java on the desktop is alive and well, including games and IDEs. For example, Spine is best in class 2D animator. http://esotericsoftware.com http://esotericsoftware.com

rhacker 9y ago

I can't seem to upgrade to Java 9 still. Its the module system. Waiting for open source to catch up in some situations. See one of the problems is that the way Java is started needs to change to enable JAXB. But many open source products have lots of code that start Java processes, and never use that command line. Did this change in Java 10, did they bring back JAXB so things will start again?

SanderMak 9y ago
Nope. In fact the module containing JAXB (and 5 other EE technologies) have been deprecated and will be removed in Java 11. So indeed, you can use the `--add-modules java.xml.bind` workaround, but it will break with Java 11. The real solution is to add a JAXB implementation of your choice as dependency to the application. (disclaimer: I'm author of the O'Reilly book Java 9 Modularity (see https://javamodularity.com https://javamodularity.com) which discusses this and other migration issues in great detail)
krzyk 9y ago
If you are using maven you can try following dependencies for JAXB from glassfish: <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-runtime</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-core</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.0</version> </dependency> As other commenter said, JAXB will disappear form Java 11 (and all other Java EE stubs that exist in Java SE) so it is better to upgrade sooner than later. And BTW, I would skip Java 9 and go straight to Java 10 now.

chenzhekl 9y ago

Could anyone point me to the advantages of running Java inside a Docker container? It seems to be VM in VM. Why do we need the extra redirection?

AlphaSite 9y ago
It’s not a VM, it’s faster and far lower overhead per container. Obviously it also looses some of the isolation guarantees.
navaati 9y ago
I see your point but Docker is not a VM, there is not a "redirection" cost or anything. So you can see it as a convenient way to distribute the JVM. Say that the JVM makes your application portable wrt the OS, Docker makes the JVM itself more portable.
joeskyyy 9y ago
A container is not a VM (at least in the traditional sense). The advantages of running java inside of a container is that you can ship all of your things as one artifact, and run it on a bunch of different infrastructures, with all it's dependencies packaged together. So rather than needing to use something to ensure your properties are configured correctly, and all your passwords are where they need to be, and all your other bits and such are in place, you can pack it all in a container and run it anywhere (Well... "anywhere" being a bit of a stretch, but you get the idea haha)
- delecti 9y ago
  So Java, which was supposed to be "write once, run anywhere", didn't meet that goal enough, so Docker wraps it in something that "actually for real" is supposed to be "write once, run anywhere", but even then doesn't quite meet that goal?
  - inamberclad 9y ago
    And so, the cycle continues

e12e 9y ago

Is it me or does it seem odd that docker community edition is left out? And isn't adding an additional "silent c is for container" in front of cgroups a bit... Much? I mean, if java 10 recognises cgroup limits, that should work under things like systemd and all container runtimes?

sofaofthedamned 9y ago
I can't see how it's EE only. It reads the appropriate bits to work out the memory available, can't see how CE would hide that. The problem is wider than Java anyways. Containers see the system free memory, not what's available to that container regardless of the cgroup constraints. We've hit this many times and sometimes workarounds are available (mongodb) but sometimes they're not and in our k8s environment this means some pods will restart constantly when they try to cache over and above what their cgroup allows. The real fix is to tell a container not the system free memory but that which it's been allowed to use - afaik this is really difficult to implement, which is why the kernel hasn't had this done yet. EDIT: obvs the container could read the cgroup limits (which I assume is what Java 10 does) but all the userland tools would have to be changed as well as some kernel functions.
- e12e 9y ago
  Hm, I wonder if this might possibly be related to an issue I've seen in production with docker - of a container being killed by the oom killer... But only on server boot.
  - sofaofthedamned 9y ago
    Maybe. We've had serious problems with this, mostly with mongodb but other stuff as well.Java 10 is making an effort to fix this but I hate Java, and really it's a kernel/userland linux issue as you can't expect software not to request cache memory that it doesn't know exists.