there are several sites out providing Java source code.
Unluckily, these does not refer to the Java native binaries.
In short: The source code of native functions is not shown.
An example is StrictMath.floor.
The only thing provided is the raw Java declaration
public static native double floor(double a);
What I am interested in is the actual c/c++ code. How did they actually implement it?
The OpenJDK project contains the full source. The source for jdk 6 is roughly equivalent to what is in the Sun/Oracle jdk. The source for jdk 7 should be almost exactly equivalent.
You can see the native code generated if you use the debug build of the OpenJDK.
StringMath.floor() is turned into a single machine instruction. i.e. some "native" methods are actually inlined by the JVM. Not sure how that helps you though. ;)
See notes of fistp http://stereopsis.com/FPU.html
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.
The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?
Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.
Try to avoid uses of such APIs, always prefer a public documented and specified class.
The JDK 6 Documentation includes a link titled Note About sun.* Packages. This is a document from the Java 1.2 docs, so references to sun.* should be treated as if they said com.sun.*
The most important points from it are:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java.*, javax.*,
org.* and sun.*. All but the sun.*
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun.*, that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.*
packages are not 100% Pure Java.
and
Each company that implements the Java
platform will do so in their own
private way. The classes in sun.* are
present in the SDK to support the Sun
implementation of the Java platform:
the sun.* classes are what make the
Java platform classes work "under the
covers" for the Sun Java 2 SDK. These
classes will not in general be present
on another vendor's Java platform. If
your Java program asks for a class
"sun.package.Foo" by name, it may fail
with ClassNotFoundError, and you will
have lost a major advantage of
developing in Java.
Try running your code with a non-Sun JVM and see what happens...
(Your code will fail with a ClassNotFound exception)
Yes, because nobody guarantees that these classes or API will be the same with the next Java release and I bet it's not guaranteed that those classes are available in Java versions from other vendors.
So you couple your code to special Java version and loose at least portability.
Sun's proprietary Java classes are part of their Java implementation not part of the Java API their use is undocumented and unsupported. Since they are internal they can be changed at any time for any reason that the team working the Sun JVM decides.
Also Sun's Java implementation is not the only one out there! Your code would not be able portable to JVMs from other vendors like Oracle/BEA and IBM.
Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages
I recently had a case that showed a real-world problem you can hit when you use these classes: we had code that would not compile because a method it was using on a sun.* class simply did not exist in OpenJDK on Ubuntu. So I guess when using these classes you can no longer say things like 'this works with Java 5', because it will only work on a certain Java implementation.
Java is the language, the JRE is the runtime environment, and the JDK are the development tools? The JLS is the spec that says that the JRE must do x,y,z, and therefore makes Java what it is? Are these views correct, and if not can someone enlighten me?
Are there any things we think are Java but are not? I think I heard that about Android -- is it true?
To some extent this is a problem of the ambiguity of natural language; some of these things can mean different things at different times.
"Java" can refer to the Java language, as in "I wrote this amazing FooWidget in Java." It can also be shorthand for the Java platform including the language, runtime, tools, etc., as in "You'll need Java to use this web application."
JRE stands for Java Runtime Environment and is the bundled set of APIs included with the Java Virtual Machine. The JDK, or Java Development Kit, is the set of developer tools including the Java compiler, debugger, javadoc compiler, etc. Confusingly, it also includes a JRE (as seen in Eclipse, for example, where the JDK can be specified as the runtime for a project).
The Java Language Specification (JLS) is, um, the spec for the Java Language. Put another way, it describes the technical details of how the language is implemented.
Android is a platform in which the code is written in Java, but compiled to run on the Dalvik virtual machine rather than the JVM. In that sense, it isn't actually Java, but from the perspective of the developer the difference is mostly library use; the syntax is the same.
Similar questions:
JDK/JRE/JVM/Java SDK | What do they
all mean? Sometimes you can develop
with JRE and sometimes you need
JDK?
What does the JRE consist
of ?
Java specification
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.
Given a Java class file (ClassName.class) with bytecode version X is there a general way to convert this class file from being represented in bytecode version X to being represented in bytecode version Y?
Assumptions:
The source code is not available. The class file is the only available representation of the class.
The class file is heavily obfuscated, so decompiling the class with say jad or similar program and then recompiling it with "-target ..." does not work.
Updates after initial post:
Update #1: Futhermore, assume that bytecode version X and bytecode version Y are sufficiently close so that all instructions used by the class (currently in bytecode version X) also exists in version Y.
For downgrading you can have a look at various methods to get Java 5/6 code running in Java 1.3/1.4. See my anwser to related question Backport Java 5/6 features to Java 1.4?
You could use Apache BCEL
The Byte Code Engineering Library is
intended to give users a convenient
possibility to analyze, create, and
manipulate (binary) Java class files
BCEL gives you the possibility of reading in a class file of a given version, manipulating it, generating a new class file stream, and then loading that into the VM using the low-level ClassLoader API. Very fiddly, no doubt, and I doubt this will let you downgrade the version as easily as you could prograde.
No. While later versions of Java will be able to execute that bytecode, you can't upgrade it: Later versions of the class files have a different format.
You can't downgrade it either because there is no way to replace the missing bytecodes by other constructs in older versions of Java.
[EDIT] IIRC, Sun added at least a single new bytecode instruction for every major version of Java. This is usually the reason for major Java releases: Changes to the bytecode.
That said, just try your luck and change the major version of the class file and see if your newer VM will load it. I doubt it will work for any complex example but you might be lucky.
Use retroweaver