I was reading this blog and it says that Sun JDK does not support hot deployment in case of method signature changes/new method gets added in classes etc. I also looked at bug detail on Sun's site. In the bug detail I could see a link for Sun's forum site that I could not browse because after Oracle took over Sun, the link is not working.
By any chance, any of you have any update on this?
This is still not possible and I'm not aware of any plans in the short term from Oracle or IBM to implement this in their JVMs.
That's why zero turnaround has stepped in and created JRebel. This does exactly what you ask. It allows hot deployment of classes being structurally modified.
Related
I am looking for better HotSwapping in the JavaVM. Being able to only apply method body changes is okay but quite limiting.
The options available is JRebel and a discontinued project called Dynamic Code Evolution Virtual Machine (DCEVM).
There is a JEP 159 out there that was written by the core developper of DCEVM. A blog post from 2011 mentioned that the developers of DCEVM now work for Oracle to integrate this into the JDK.
Do we have this kind of support for JDK 8 beta already or was it postponed to JDK 9?
I need hot swapping for adding and removing and renaming private methods mostly. This would help alot. Is there a product allowing me to do so (beside JRebel which PR-campaigns got me upset).
The last supported version of DCEVM is for 1.6u24 and it only provides 32-bit linux binaries. Since I use 1.7 and 64bit Linux this is both a show stopper for me.
There is also another project available on github called Fakereplace. Can this be easily used for my purpose or should I not investigate into this?
There is a fork of DCEVM maintained in the repository on Github. It was recently updated for Java 8. The binaries are available through the GitHub releases or on the downloads page.
For simple things, like adding/removing methods, it should be pretty reliable (verified by automated tests in 16 different configurations). However, it still could eventually crash JVM, so it is by no means should be used in production.
JEPs coming in JDK 8 and JDK 9 are listed in this page. JEP-159 is not among them. From jep index you can see that JEP-159 is not yet targeted to any JDK release, not even jdk 10.
JEP-159 status is currently "Submitted". The process is described as follows:
A successful JEP passes through the following states:
Draft — In circulation by the author for initial review and consensus-building
Posted — Entered into the JEP Archive by the author for wider review
Submitted — Declared by the author to be ready for evaluation
Candidate — Accepted for inclusion in the Roadmap by the OpenJDK Lead
Funded — Judged by a Group or Area Lead to be fully funded
Completed — Finished and delivered
So it's not yet accepted for any roadmap.
Is JVM open source code? If not, how can I get the code of JVM?
It depends entirely on which JVM you use.
If you use the OpenJDK JVM, then you can get the source code from here (or here from a list of OpenJDK projects).
If you use the Kaffe JVM, you can get the source from here.
If you use the Sun JVM version 6 or later, then you can get the source from here.
If you use a Sun JVM earlier than 6, then you can often get the source under an academic license. If you use an IBM, Oracle, HP, or other JVM, then the source is not open.
Update May 2013
The Version 6 source can still be accessed by the above link, or it can be accessed via this link. This latter link also includes a handy genealogy table that shows how the Oracle JDK and OpenJDK versions match with each other.
Additionally, a more up to date version of the Java 7 source can be found here. This also includes the fixes for the releases of Java 7 since GA.
And, of no surprise to anyone, the Java 8 sources can be found here.
Have a look at hotspot JVM here: http://openjdk.java.net/groups/hotspot/
The core part of the JVM is in the hotspot module of the OpenJDK. However what you need is more likely to be in src.zip.
The hotspot module apart of those classes is
mostly in C++
not always easy to understand. This has improved over the years and new code tends to be better as they are more aware that the code will have broader consumption.
often not what you are looking for.
For this reason if you want to know how the JVM runs it is best to look at the commonly used classes. For example, even something as low level as how lambdas really work at runtime is mostly in the src.zip not much is in the JVM.
Most of the source for the libraries come with the JDK in the src.zip file. Your IDE will use that automatically. You are much better off being familiar with the classes in these libraries than playing with the JDK itself.
There is no open source jvm even if there were you can't bypass Oracle's stupid classpath exception. In short openjdk is still tied to $$ driven scheme that forces you to contend with a comercial vm. No different from Microsoft really, you can work with C# under what ever os they even provide .net libraries free but maintain control over Visual Studio which practically forces the end user to make use of Windows as the chosen environment.
I've read the HornetQ FAQ, but I can't find anything related.
I'm using HornetQ 2.2.5, it contains a bug (yeah, just one ;). According to this post https://community.jboss.org/message/624958?tstart=2 it's been fixed from 2.2.7.Final onward.
On the main download page, http://www.jboss.org/hornetq/downloads the latest version available is 2.2.5.Final. I'm not scared of compiling a newer version myself, but can I consider it stable?
I'd say yes since it's a minor release update, but I'd like some other opinions. Thanks.
This answer uses the 2.3.X branch as an example. Let's skip looking at their Downloads page, and go straight to the artifacts:
http://mvnrepository.com/artifact/org.hornetq/hornetq-pom
You can see that 2.3.X went through Alpha, Beta and CR stages, to finally reach 2.3.0.Final, the Community release. This is what most people in the open source world would end up using, and what you will find available for easy download.
It's also the last version the non-paying customers are intended to use (in the typical JBoss release cycle - see e.g. the JBoss AS/EAP FAQ). Now, from a commerical perspective, 2.3.0.Final would be considered Alpha again. An analogy from the JBoss AS/EAP FAQ which probably applies here too: "The first EAP stage Alpha is of equivalent, or better, quality to a community Final release [...] we don't recommend using it in production" (probably an overly harsh judgement, but anyway.)
After 2.3.0.Final, they fix more bugs (2.3.1.Final, 2.3.2.Final, ...) until they get to a commercial production release (which they bundle into their other commercial products). So, you should be using the latest .Final that you can for production (for the 2.3.X branch, it was 2.3.13.Final).
Do you have to pay for 2.3.13.Final? From what I can tell, you don't. (HornetQ is also not available commercially AFAICT, except when bundled into other products.)
How do you get 2.3.13.Final? You probably won't find a nicely packaged RPM or even zip file. Instead, you will need to get the JARs from public Maven repos (or build from source).
Do you need a postgrad degree in JBoss Versioning and Product Naming to use their products? Perhaps :) - I don't have one, so apologies in advance if I have failed to comprehend the enormous complexity of the beast. But I do wish the HornetQ developers would make it easy to get a stable release of their product, and know that this is what one is using. It's a good product (perhaps the most fully featured of the lot), with an excellent manual, but a snap judgement of the download page and FAQ may make some people look at competing projects instead.
Well, after some more research, I can say yes, it is stable.
In particular, JBoss EAP 5.1.2 package includes HornetQ version 2.2.10.GA.
I wonder why there is no direct link on the HornetQ download page.
Is JVM open source code? If not, how can I get the code of JVM?
It depends entirely on which JVM you use.
If you use the OpenJDK JVM, then you can get the source code from here (or here from a list of OpenJDK projects).
If you use the Kaffe JVM, you can get the source from here.
If you use the Sun JVM version 6 or later, then you can get the source from here.
If you use a Sun JVM earlier than 6, then you can often get the source under an academic license. If you use an IBM, Oracle, HP, or other JVM, then the source is not open.
Update May 2013
The Version 6 source can still be accessed by the above link, or it can be accessed via this link. This latter link also includes a handy genealogy table that shows how the Oracle JDK and OpenJDK versions match with each other.
Additionally, a more up to date version of the Java 7 source can be found here. This also includes the fixes for the releases of Java 7 since GA.
And, of no surprise to anyone, the Java 8 sources can be found here.
Have a look at hotspot JVM here: http://openjdk.java.net/groups/hotspot/
The core part of the JVM is in the hotspot module of the OpenJDK. However what you need is more likely to be in src.zip.
The hotspot module apart of those classes is
mostly in C++
not always easy to understand. This has improved over the years and new code tends to be better as they are more aware that the code will have broader consumption.
often not what you are looking for.
For this reason if you want to know how the JVM runs it is best to look at the commonly used classes. For example, even something as low level as how lambdas really work at runtime is mostly in the src.zip not much is in the JVM.
Most of the source for the libraries come with the JDK in the src.zip file. Your IDE will use that automatically. You are much better off being familiar with the classes in these libraries than playing with the JDK itself.
There is no open source jvm even if there were you can't bypass Oracle's stupid classpath exception. In short openjdk is still tied to $$ driven scheme that forces you to contend with a comercial vm. No different from Microsoft really, you can work with C# under what ever os they even provide .net libraries free but maintain control over Visual Studio which practically forces the end user to make use of Windows as the chosen environment.
If I'd switch from Sun JDK to OpenJDK which surprises do I have to prepare myself for?
What does frequently go wrong and how difficult can this be?
Of course, each and every application can have its individual problems, but I'm looking for classes of problems, something many people already have struggled with when switching JDKs.
It is unlikely that anything will go wrong with OpenJDK. It is considered 100% compatible by now. But I think it is good to know what parts had to be rewritten and therefore are not using the same code as the SunJDK.
The Wikipedia entry has a good overview of this:
As of May 2008, the only part of the Class library that remains proprietary and closed-source (4% as of May 2007 for OpenJDK 7, and less than 1% as of May 2008 and OpenJDK 6) is the SNMP implementation.
Since the first May 2007 release, Sun Microsystems, with the help of the community, has released as free and open-source software or replaced with free and open-source alternatives almost all the encumbered code:
All the audio engine code, including the software synthesizer, has been released as Open-source. The closed-source software synthesizer has been replaced by a new synthesizer developed specifically for OpenJDK called Gervill,
All cryptography classes used in the Class library have been released as Open-source,
The code that scales and rasterizes fonts has been replaced by FreeType
The native color management system has been replaced by LittleCMS. There is a pluggable layer in the JDK, so that the commercial version can use the old color management system and OpenJDK can use LittleCMS.
The anti-aliasing graphics rasterizer code has been replaced by the Open-sourced Pisces renderer used in the phoneME project. This code is fully functional, but still needs some performance enhancements,
The JavaScript plugin has been open-sourced (the Rhino JavaScript engine itself was open-sourced from the beginning).
As I know fonts will look garbled, Sun had to remove original ones from OpenJDK since they are not 'open source' and JVM will use some default which are not so nice...
Since OpenJDK is a Sun project, based on the original Java source, I wouldn't expect many problems. The only area where things can break is the code which had to be replaced (because it couldn't be released under the GPL) or changes because of new features (but those should be pretty much the same as in the official JDK).
Use an OpenJDK build known to pass the TCK to minimize the surprises.
Some of the swing UI's did not match up entirely (metal had paddings that were off just aenough to notice). Note that this was 8 months ago.
OpenJDK (IcedTea) applets under linux are a MAJOR PAIN. I'm struggling with remote debugging a piece of rather rusty code for couple of hours already. Official documentation on how to attach to an applet in a browser simply does not work for me. There's no java console by default, BTW. I'm seriously considering replicating the applet config and using JDK built-in applet viewer instead of trying to debug the browser-hosted JVM.
UPD: I am not quite sure that OpenJDK does not have a browser plugin itself. Maybe this changed recently.
OpenJDK is more secure than the Oracle binaries because of IcedTea.