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.
Related
Disclamer
Sorry in advance if this is a stupid question, but my research to clarify this was not as successful as i needed it to be.
Problem description
I am working on a project using jdk 11 and in order get decent testcoverage, i added something to mock calls/answers to/from external services. So i included wiremock.
As suggested on their setup getting-started section, i included
testImplementation "com.github.tomakehurst:wiremock-jre8:2.34.0"
Even though everything works on my machine (and tests run fine on the pipeline), i don't know if this will potentially cause issues on other machines. The architect involved in the project also stated his concern that we do only use jre 11.
Therefore i need some more insight to either change things up or argue why this is not an issue.
Attempts so far
I expected there to be an higher version of wiremock on mavencentral, but ther were only two projects:
mvnrepository: wiremock - last updated Sep, 2020
mvnrepository: wiremock-jre8 - last updated Sep, 2022
To my surprise, wiremock-jre8 was the most recent version. I don't know what the older version was compiled with but i was using annotations that wouldn't work with the 2020 version either way. So it would be nice to not downgrade the current implementation to a less readable solution.
I should mention, that i only guess that wiremock-jre8 has been compiled with jdk8 from the naming. I did not find any evidence about what compiler did produce the bytecode for either of those dependencies or clues on how to interpret this.
When trying to figure out how back and forwards combability works with java, the compiler and the produced bytecode, i found this older post. In short it states:
Compatibility from the point of view of javac (as it is the part specific to the JDK), meaning that the bytecode generated can be run in future releases of the jvm (that is more related to the JRE, but also bundled in the JDK).
JDK's are (usually) forward compatible.
JRE's are (usually) backward compatible.
I do understand that in parts, but not fully concerning my issue. Especially the "usually" part.
So are there some more insights someone has to spare to enlighten me? :)
The Download and Installation section of their documentation contains this sentence:
Additionally, versions of these JARs are distributed for both Java 7 and Java 8+.
So if you are still running Java 1.7 you must use the version for Java 7.
For all later versions of Java there is the version for Java 8+ (the version that you use.)
Since this is an actively supported project any problems related to Java versions later than Java 8 will be properly addressed and resolved (see for example Build on & fully support JDK 17 which was resolved in "com.github.tomakehurst:wiremock-jre8:2.32.0").
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.
Our Java Applet is built using JDK 7u7.
We have a client who is worried that this exposes them to security flaws that were patched between 7u7 and the current Java 7 release (7u72). (They're not worried about any specific known issues, just "concerned".)
I believe the answer is that because the package is dependent on calls to the JRE libraries, it will call the (fixed) 7u72 libraries, and therefore the fact that it was developed against 7u7 will not be an issue.
Is this correct? A link to authoritative statements on this point would be much appreciated.
It is correct. Output of compilation is defined in the java VM specification in class file format, which has not changed between java update releases, it doesn't matter if it's compiled in 7u7 or 7u72.*
You can see all the java virtual machine specifications since java 5 on this page. There are no other changes to the specification, so it has only changed between major releases.
*on further thought, this assumption is true only if there hasn't ever been security-related bytecode generation bugs in JDKs. I've never heard of one, and certainly between versions 7u7 and 7u72 there isn't any. I guess it is possible in theory, but at least for the cases you specified there aren't such security issues.
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.
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.