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.
Related
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.
My old projects use Java 6 (1.6), and I don't know when I update (Java 7), they can run fine ?
There is an official list of known incompatibilities between java 6 and java 7 from Oracle (including descriptions of both binary and source-level incompatibilities in public APIs).
Also you can look at the independent analysis of API changes in the Java API Tracker project: http://abi-laboratory.pro/java/tracker/timeline/jre/
The report is generated by the japi-compliance-checker tool.
They should do, yes. Java has a reasonably strong history of backward compatibility. However, if these are in any way important projects you should still perform a thorough test pass before deploying anywhere production-like.
There shouldn't be any compatibility differences as the JVM is basically the same. However it is early days so there may be subtle differences which cause a problem which people are not yet aware of.
e.g. Eclipse looks at the Supplier in the java.exe on Windows and sets the command line arguments differently for different suppliers. It has a problem with Java 6 update 22 because Oracle wanted to change it from "Sun" to "Oracle". I believe this has been changed so it is "Oracle" in Java 7 (but still "Sun" for Java 6)
My point being, that if you write generic Java code, you shouldn't have a problem. However, if you are doing something a bit unusual, you are likely to need to re-test your application.
As was already stated backward compatibility is a very important aspect in new Java releases, so in general there should be no problems in switching to a newer Java version. In this case, however, Java 7 seems to have a few bugs in the new hotspot compiler optimizations. The Apache Software Foundation has issued a warning that their products Lucene and Solr are affected by these bugs.
http://lucene.apache.org/#28+July+2011+-+WARNING%3A+Index+corruption+and+crashes+in+Apache+Lucene+Core+%2F+Apache+Solr+with+Java+7
The affected loop optimizations can be switched off by starting java with -XX:-UseLoopPredicate.
AFAIS here, there's no Java 6 features which get deprecated in Java 7 so yes, your project should run fine.
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.
I'm working on a school project where I am required to use the GNU Compiler for Java. I've always worked using the official Sun JDK and now I'm concerned about differences that might complicate my work.
I'm specially interested in which version of Java is the one supported by the latest GCJ compiler
Could someone shed some light in the differences between one or the other?
PS: I searched on google but failed in finding a recent answer
Since gcj is a compiler on top of GNU Classpath you need the differences between official JDK & GNU Classpath. For SUN JDK 1.4 see this for SUN JDK 1.5 see this one instead.
If this answer should become the highest voted answer, it means that you should ask your prof to please reconsider why he's making you use such an unusual platform. In the real world, people use Sun JDKs predominantly. I don't see this changing much in the near future. It is a quality product, for the most part.
Can this really be helping you learn?
Well from it's home page:
http://gcc.gnu.org/java/
Compiled applications are linked with the GCJ runtime, libgcj, which provides the core
class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically
load and interpret class files, resulting in mixed compiled/interpreted applications. It
has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5
additions.
From the GCJ website. It looks like the GNU compiler is an ahead-of-time compiler and not a just-in-time compiler like Sun's. So there's one difference right there. The front page is a little vague and references that it does have some byte-code interpretation facilities built into the libgcj runtime.
I'd be wary of any library that covers MOST of the 1.4 and 1.5 libraries. If you target 1.4 your probably alright. 1.6 and you're probably in for a world of hurt.
Bear in mind if GCJ can only INTERPRET class files then it could be much slower running uncompiled code than Sun's JIT compiler.
I have run into subtle differences in date parsing last time I looked.
AS the gnu JVM has not passed the Java TCK you must basically treat it as a new platform with full testing needed.
If I'm deploying to servers with WebSphere 6.1 (Java 1.5), should I use IBM's JDK on my build box? Or will Sun's JDK compile to the same binary?
If I should use IBM's, where can I get the Windows x64 version?
I would as much as possible try to keep development as close to production as possible. Ibm and Sun's JDK's certainly both satisfy the SDK certification, but they are by no means identical. Their instrumentation and memory management are at least slightly different. If nothing else, the bugs in the JDK will be different, which your code may only trip over in one scenario vs. another. It'll also probably only happen at 4 am, and when the moon is full especially when you have company over.
I can't tell you where to get IBM's jdk, but if you've got a license to websphere at your company, you should have a contact at IBM to get you a link to that JDK.
Good luck, and always try to minimize differences where possible.
It should not make any difference. It will probably not be exactly the same binary but 100% compatible. I assume you're using external libraries anyways like log4j or maybe hibernate or whatever and those are not built using the IBM JDK.
There are differences in the JREs, however. For example, I remember that when I listed methods or fields of a class using reflection, the IBM JRE used to give them to me in a different order than the Sun one.
I would use the same JDK to build that is going to be used when the application is deployed (if you have control over that).
The binaries may be different if the compiler is different, but they should be semantically identical. I don't know if IBM wrote its own compiler. The JRockit JDK actually uses the Sun compiler but the JVMs are different. So with JRockit the binaries are identical.
If the application is used with different JDKs at run time, I would still build with the one that you think will be used at deployment time most of the time and do some runtime testing with different JDKs.
The IBM JDK ships with J9 VM and SUN JDK runs on Hotspot VM which have different algorithms to function. You application may not perform the same if you deploy and tune in SUN JDK and your production uses IBM JDK for WAS. Check with the vendors and open a ticket,let us know how it goes.
Compiling with any JDK should not cause a problem unless you are referencing classes outside of the java.* and javax.* pacakges (which you should not be.) Of course there's always a chance that there's a discrepancy between a given vendor's JDK and the spec which could cause some really weird runtime errors that are hard to track down, but I've never seen this before in my experience.
I would recommend running any test suites you have using the target JRE as runtime behaviors differ between vendors much more often than compilation semantics do.
JDKs are compiling your code to a bytecode and not directly to machine code. Is expected that compilers of different vendors generating cross-vendor compatible code. For example IBMs compiler for JDK1.5 will produce code that runs on SUN's JDK 1.5 and later without any problem.
Another issue is how compilers optimizing the bytecode, I have not information that some compilers performing better optimization than others. The largest part of optimization is performed during runtime by JVM (for example JIT (just-in-time) or AOT (ahead-of-time) strategies).
Having worked with WebSphere a long time the version of the JDK is very important. WebSphere 6.1 ships with an IBM JDK 1.5 (or is it 5). When you patch the WebSphere there are equivalent patches for the JDK as well. While it may work with a different version of the JDK (even a different vendor) I doubt you will get much support from IBM if something goes wrong.
If you need a 64 bit JVM I would suggest that there is probably a 64 bit build, while I cannot comment on windows specifically I can tell you there is a 64 bit WebSphere 6.1 build for both AIX and Linux.
The best answer is to check with the vendor and see if they will support your configuration. What you don't want to do is get it working, then have an issue in live, call up support and find out that you have an unsupported environment.
They should compile to the same bytecode specification, although they may compile different bytecode (much as in the same way different C compilers generate different machine code). I don't think there would be any problems in running the resulting code - I've compiled Java 1.4 on a Mac and then deployed to IBM's J9 running on a PocketPC before with no problems (this was before J9 could handle Java 5 bytecode).
Regardless, I'd definitely make your compilation platform a bullet point on your readme file so that your client can see if it is a problem.
Alternatively, you could build and deploy with ANT, and use Sun's JDK with ANT.