Is it true to say that to a high degree what is now done in docker containers can also be done in java with jvm if someone wanted to ?
Besides being able to write an application in your own language and having much customisation flexibility does docker basically do what Java has been doing with its virtual machine for ages ? i.e. it provides executable environment separate from the underlying OS.
Generally Docker containers cannot be done "within Java" because Docker serves to encapsulate the application, and "within Java" is the code being loaded after the JVM launches.
The JVM is already running when it parses the class it will search for the main method. So encapsulation at the process level can't be done because the process (the JVM) is already running.
Java has encapsulation techniques which do provide protection between various Java elements (see class loader hierarchies in Tomcat, for an example); but those only isolate "application plugins" from each other, the main process that is running them all is Tomcat, which is really a program loaded into an already running JVM.
This doesn't mean you can't combine the two to achieve some object, it just means that the types of isolation provided between the two products isn't interchangeable.
what is now done in docker containers can also be done in java with jvm someone wanted to
Short Answer: No. You could wrap a docker container around your JVM, but you cannot wrap a JVM around a docker container, non-trivially.
docker basically do what Java has been doing with its virtual machine for ages ? i.e. it provides executable environment separate from the underlying OS.
Docker containers provide isolation from other containers without introducing a virtualisation layer. Thus, they are different and more performant than VMs.
Docker can perform several things that the Java JVM cannot do however, programming in Java and running on the JVM will provide several of the advantages of running in a Docker container.
I work on a large Java project and this project is 20 years old. We have been evolving and fixing our application without any tools or compatibility issues for all these years. Also, as a bonus, the application is platform independent. Several components of it can run in both Windows and Linux. Because no effort was made initially to build a multiplatform application, there is one component that cannot run on Linux. But it would be relatively easy to make it work on that platform.
It would have been much more difficult to do the same thing using C or C++ and associated toolchain.
Related
I am about to create a java server/client construct, that uses bidirectional communication via tcp sockets. For every requesting client a new thread is created. At this moment it is running on a virtual machine from a hosting service. Now i thought about using docker. But does it really make sense to switch to docker in this case? Is docker really ment to run permanent applications like a java server?
I'm on thin ice here but, I'm going say it anyway... If you're running a process on Linux, to most intents and purposes, the process is running in a container.
Containers are "sugar" atop intrinsic Linux kernel features (namespaces, cgroups etc.). Solutions including Docker Engine mostly made these -- somewhat arcane -- capabilities of the kernel available more broadly available | easier to use.
Containers and VMs are very distinct technologies. Extending the above, you can run VMs in Containers and -- you're almost always -- running Containers in VMs.
It's containers all the way down :-)
To answer your question directly: you are already running your Java server in a container and it's running on a VM. You may decide to do two things but please read up more on each before deciding:
Add Docker (Engine) into your existing VM (if it's not already there) as a way to more easily manage your Java server as a Docker container. Benefits: unclear but see below.
Extract the Java server from the VM (!) and run the server instead as a Docker container. Benefits: unclear; Consequence: may not be possible with your hosting company; potential security concerns; no well-defined benefits; etc.
One benefit for you in using containers and deploying containers to your existing hosting provider (and continuing to use their VMs) is that you would be able to build and test in locations other than your hosting provider and be (mostly) guaranteed that a container image that worked during build and test will also work on your hosting service provider in production.
HTH!
I'm learning CoreOS/Docker and am trying to wrap my mind around a few things.
With Java infrastructure, is it possible to use the JVM in it's own container and have other Java apps/services use this JVM container? If not, I'm assuming the JVM would have to be bundled in each container, so essentially you have to pull the Java dockerfile and merge my Java services; essentially creating a Linux Machine + Java + Service container running on top of the CoreOS machine.
The only other thought I had was it might be possible to run the JVM on CoreOS itself, but it seems like this isn't possible.
It is actually possible to just untar Orcale Java in /opt, but that's just a kind of last resort. The Oracle binaries of JRE and JDK don't require any system libraries, so it's pretty easy anywhere.
I have written some pretty small JRE and JDK images, with which I was able to run Elasticsearch and other major open-source applications. I also wrote some containers that allow me to compile jars on CoreOS (errordeveloper/mvn, errordeveloper/sbt & errordeveloper/lein).
As #ISanych pointed out, running multiple Java containers will not impact disk usage, it's pretty much equivalent to running multiple JVMs on the host. If you find that running multiple JVMs is not quite your cuppa tea, then the answer is really that JVM wouldn't have to be as complex as it is if containers existed before it. However, Java in container is still pretty good, as you can have one classpath that would be fixed forever and you won't get into dependency hell. Perhaps instead of building uberjars (which is what I mostly do, despite that they are known to be not exactly perfect, but I am lazy) one could instead bundle jars in tarball and then use ADD jars.tar /app/lib/ in their Dockerfile.
Applications that run on JVM will have to have JVM installed in the container. So if you want to split application components into separate containers, each of these containers need to have JVM.
On a side note, containers can talk to each other via a process called container linking
Best practice will be to create image with jvm and then other images based on jvm image (from jvm in Dockerfile). Even if you will create many different images they would not waste much space as docker is using layered file system and all containers will use the same single copy of jvm image. Yes each jvm will be separate process eating own memory - but isolated environments that is what docker is used for.
I'd like to run multiple Java processes on my web server, one for each web app. I'm using a web framework (Play) that has a lot of supporting classes and jar files, and the Java processes use a lot of memory. One Play process shows about 225MB of "resident private" memory. (I'm testing this on Mac OS X, with Java 1.7.0_05.) The app-specific code might only be a few MB. I know that typical Java web apps are jars added to one server process (Tomcat, etc), but it appears the standard way to run Play is as a standalone app/process. If these were C programs, most of that 200MB would be shared library and not duplicated in each app. Is there a way to make this happen in Java? I see some pages about class data sharing, but that appears to apply only to the core runtime classes.
At this time and with the Oracle VM, this isn't possible.
But I agree, it would be a nice feature, especially since Java has all the information it needs to do that automatically.
Of the top of my hat, I think that the JIT is the only reason why this can't work: The JIT takes runtime behavior into account. So if app A uses some code in a different pattern than app B, that would result in different assembler code generated at runtime.
But then, the usual "pattern" is "how often is this code used." So if app A called some method very often and B didn't, they could still share the code because A has already paid the price for optimizing/compiling it.
What you can try is deploy several applications as WAR files into a single VM. But from my experience, that often causes problems with code that doesn't correctly clean up thread locals or shutdown hooks.
IBM JDK has a jvm parameter to achieve this. Check out # http://www.ibm.com/developerworks/library/j-sharedclasses/
And this takes it to the next step : http://www.ibm.com/developerworks/library/j-multitenant-java/index.html
If you're using a servlet container with virtual hosts support (I believe Tomcat does it) you would be able to use the play2-war-plugin. From Play 2.1 the requirement of always being the root app is going to be lifted so you will probably be able to use any servlet container.
One thing to keep in mind if that you will probably have to tweak the war file to move stuff from WEB-INF/lib to your servlet container's lib directory to avoid loading all the classes again and this could affect your app if it uses singleton or other forms of class shared data.
The problem of sharing memory between JVM instances is more pressing on mobile platforms, and as far as I know Android has a pretty clever solution for that in Zygote: the VM is initialized and then when running the app it is fork()ed. Linux uses copy-on-write on the RAM pages, so most of the data won't be duplicated.
Porting this solution might be possible, if you're running on Linux and want to try using Dalvik as your VM (I saw claims that there is a working port of tomcat on Dalvik). I would expect this to be a huge amount of work, eventually saving you few $s on memory upgrades.
Ok I just need to understand this thing. I have a JVM installed on my machine. If I develop 2 programs (2 jars with their own main classes) and run them, will they be both running on the same JVM?
If they both run on same JVM instance, how can I make them communicate?
The system I am currently working on has many components installed in one machine but communicate with each other using RMI. Isn't it impractical for these components to use RMI when they are all running on one machine?
If I develop 2 programs (2 jars with
their own main classes) and run them,
will they be both running on the same
JVM?
Typically no, each will be run in their own JVM process (java), unless you start one from the other in a separate thread or something.
The system I am currently working on
has many components installed in one
machine but communicate with each
other using RMI. Isn't it impractical
for these components to use RMI when
they are all running on one machine?
It is sort of impractical, at least inefficient with all the (de)serialization that takes place. (RMI uses object serialization to marshal and unmarshal parameters)
OSGi (Dynamic Module System for Java)
If you are running both locally, and just need components to find each other, I suggest you make them into OSGi bundles. It has been engineering for this sort of use.
(As an example, this is how Eclipse IDE components and plugins interact with each other, while being loosely coupled, and without the unnecessary (de)serialization)
The two applications will run in different virutal machines if they are started separately (even if they are running on the same physical machine). OSGi has already been mentioned as a way of bring them together but if you want to maintain them as separate applications it might be worth considering web services as a communication method. The benefit of this over RMI is interoperability with other applications and flexability for future development.
you may also use observable pattern if both of the application runs on the same machine - a thought.
I'm coming from the .Net camp where virtualization was much more prevalent do to the need to run on server software and system-wide entities such as the GAC.
Now that I'm doing Java development, does it make sense to continue to employ virtualization? We were using VirtualPC which, IMO, wasn't the greatest offering. If we were to move forward, we would, hopefully, be using VMWare.
We are doing web development and wouldn't use virtualization to test different flavors of server deployment.
Pros:
Allows development environments to be
identical across the team
Allows for isolation from the host
Cross-platform/browser testing
Cons:
Multiple monitor support is lacking (not in VMWare?)
Performance degradation - mostly I/O
Huge virtual disks
One possible advantage is that you could technically test out the same program on a variety of operating systems and on a vartiety of JVMs.
Contrary to popular opinion, Java is not 100% portable, and it is very possible to write nonportable code. In addition, there are subtle versions between libraries. If you work with different JVMs, there could also be differences.
However, since Java IDEs are heavyweight, running an IDE within the VM may not be fun.
Java does support some forms of remote deployment, might be beneficial to explore those while still doing the IDE work locally.
I don't like developing in a VM. The good thing is, in contrast to what you're writing as cons, that multiple monitors are supported by VMWare and the huge disk thing isn't really a problem since VMWare runs surprisingly smoothly from USB hard disks.
Running the heavyweight IDEs for Java, as Uri said, won't be much fun in a VM. But then, running Visual Studio in a VM isn't really fun as well. So if you were happy with VS in a VM, then give it a try for Java, because the cons aren't as strong as you might think :)
You said your doing java web development so it makes sense to test your application using different web browsers on different operating systems. VMware will be useful for this.
The Netbeans IDE is operating system independent, so you can have developers working on different operating systems with out any trouble.
I run eclipse inside a VirtualBox instance and it works fine. I've used VMWare in the past and that's fine too.
I like having my development environment segmented away from whatever the rest of my PC is doing (playing games, surfing the web, reading email, etc...)
I work from home so virtualization provides necessary separation of work/play. It also allows me to upgrade each environment separately and have much more control over the environment.
Also I can safely try something new and revert if the install goes "wonky". Sorry for the highly technical term. ;-)
Edit: It also allows me to satisfy the corporate VPN access requirements without subjecting my home environment to excessive corporate influence.
If you need a VM to verify that the app will also run on a different OS, you can cover quite some ground by using a continuous integration server and start/run VM instances on that machine (ie. Linux / Windows / OSX). Then unpack the latest build, run unit-tests on the delivered classes.
Then run automated integration tests. You will then have to report the results back to the CI-environment.
If the integration tests are good, this can catch a lot of the common multi-platform mistakes right after they are committed to the SCM.