I decided to start coding for Android. Before the decision, I spent a lot of time improving my Java skills, hoping that it would help me also with Android development.
Today, after opening some classes (e.g. HashMap), I saw that the Android implementation is different from the "regular" implementation.
Can someone explain to me why classes that aren't related to GUI and touch need to be implemented differently in Android? Why not use the same class that already exists?
I searched for an answer but didn't find one. If this question has already been asked, I will be glad to get the link for it and lock the post.
It is all about copyright, licensing and big company's trying to protect their "turf".
The background is that Java was originally a proprietary codebase developed by Sun Microsystems. The Java class library source-code that was made available to developers was covered by a proprietary license.
In 2007, OpenJDK 6 was released as open source. Google looked at OpenJDK, and also negotiated with Sun about licensing, but they decided that they were better off doing a clean-room reimplementation based on the published Java Language specification and the Java SE javadocs. Among other things, this allowed Google to take a fresh look at the user interface framework, and other APIs that are critical to mobile platforms. The end was result was vastly superior to Sun's Java ME offering.
But relations between Sun and Google were still cordial.
Then Oracle merged with Sun and there was a change of corporate culture. There was a big lawsuit between Oracle and Google, and that scuppered any chance of significant cooperation between Oracle and Google in the Java ecosystem.
For more background, read these Wikipedia articles:
Java Programming Language: History.
Android: History.
Oracle America, Inc. v. Google, Inc.
Different SDKs (even from the same publisher) can have different class implementations, however the behaviour on most cases for standard classes should be the same. Years ago the differences were even bigger.
In light of the recent apparent crackdown of Oracle on Java users (read here), I'm wary about my continued use of Oracle's JDK - or anything Oracle for that matter. The above article warns:
“If you download Java, you get everything – and you need to make sure
you are installing only the components you are entitled to and you
need to remove the bits you aren’t using,” our anonymous expert
warned.
I'm only using the OracleJDK for personal use, on my personal laptop. I haven't given the code to anyone. Period.
Is there a simple way to check if I have any of the commercial features enabled? I use IntelliJ IDEA CE. I don't want to accidently activate them so I'm seeking your help. Thank you.
So oracle's java BCLA states the following.
This means that you can pretty much do what ever you want with the software as long as you are the one using it and you arn't violating any of the later clauses such as reverse engineering / decompiling to provided software.
Now who does pay Oracle for the JDK? Well let's look at the highlighted section. Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs. The first part non-exclusive this means that you are not the only person granted the license. Non-transferable this means that you may not give your license to another person. limited license this means Oracle can take your license away and that you are not unlimited with your relation to the intellectual property. without fees Free! to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs. This means that you can use the jdk your self to run your java code. So if you were say a school that charged tuition and used the jdk as part of the curriculum you would owe royalties consequence of providing the jdk to external consumer (the student) as part of a package delivered for a fee.
Now it's the next part that has you worried. THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. Digging deeper for a description of the commercial features we find this page. which includes the following portion that would have anyone a little worried.
While this may seem alarming you would have had that talk with oracle when you were downloading Java SE advanced or Java SE suit. Earlier in the page under [vanilla] Java SE it says 'Java SE can be used for free internally to run applications and may be redistributed in accordance with the Oracle Binary Code License Agreement for the Java SE Platform Products (the “Java BCLA”)'
To address your initial question as to weather the commercial features are enabled or not you can look at the vm options that you are using at run-time, as this is where the commercial addon's are enabled.
Do not modify the software Oracle distributes to you as the license provided to you is for use of the software 'complete and unmodified'.
I'm currently looking at the Metro stack on my search for a nice SOAP web service stack that should be used in a closed source project, but i dont fully understand metros license terms that can be found here:
glassfish.java.net - license
So my questions are:
Can the Java Metro stack be used in closed source projects?
If yes - what am I allowed to do with the libraries if I want to keep my own code closed source?
Best regards
After some more research I found that the Netbeans framework is licensed with the same construct (GPLv2 and CDDL) and luckily the guys at Netbeans took the time to explain the how what and why a bit:
Netbeans license FAQ
Here is what they say about dual-licensing:
Dual-licensing is the practice of distributing identical software under two (or more) different sets of terms and conditions. When software is dual-licensed, recipients can choose which terms under which they want to obtain the software. The two usual motivations for dual-licensing are business models and license compatibility. [...]
Additional search for details about CDDL brought me to this site containing a nice summary:
why the dislike for cddl
Here is one of the parts relevant that is to my question:
CDDL is a file-based license. This means that if you make any changes to CDDL-licensed software, any existing files that you modify need to remain under CDDL, but any new files that you create can be under whatever license you want as long as that license isn't incompatible with CDDL.
Conclusion (note that I'm not a lawyer and this is no legal advice - just my personal interpretation based on the available information):
Metro seems to be useable for commercial closed source projects but changes to the existing source have to be made available under the same license as the original source.
So as long as one is just using the libraries the own source code can be kept completely closed source.
At least if CDDL is chosen.
Alright everyone,
Let's say i wanted to make a system that used only assembly and java, my question would be, as long as i included all of the jvm folders, classes, jars, etc.. java should still function effectively?
i understand there are those things that are compiled platform specifically but this is why i am asking, is it possible, using assembly to replicate all of the .exe, or other executable files that java has included into a pure assembly/java system?
If you are asking whether it is possible to build a system in Java and assembly language that runs on "bare metal", the answer is yes. There are a couple of current examples:
JavaOS is targeted primarily at the embedded systems domain. (Sun consider SunOS to be a "legacy" product line these days.)
JNode aims are broader, and encompass embedded systems, desktop systems, servers and cloud computing.
Be aware that building a system of this kind is a multi-year, multi-person project requiring deep understanding of virtual machine internals, compilers, garbage collectors, hardware architectures, device driver writing and so on.
If you are asking about something else, please be more explicit.
EDIT: responding to the OP's followup question:
It is not practical to use the Java and other "exe" files per se. They require a fully fledged operating system underneath them; e.g. Windows, Linux, whatever. If you had access to the source code, you could conceivably rewrite as required to make them run on "bare metal", but that would entail significant architectural changes, especially if you want to write device drivers, etc in Java. (Besides, the core of Sun's JRE is implemented in C++ ... ).
You cannot directly use the existing Java class library JAR files, because they include a significant amount of platform specific code. However, you can build your own Java class library JARs from an existing open-source version of the Java class libraries (e.g. the OpenJDK 6.0 J2SE libraries). You deal with the platform specific code by providing your own versions as native libraries or (as JNode does) as Java classes.
If I understand your question correctly, you mean something like JavaOS. Sure, its possible to implement the JVM raw on the hardware, not sure why you would, though. And if you did, why you wouldn't use C instead of Assembly for most of the work.
Its theoretically possible to implement the jvm in a whole other language. The best example I can think of is Python/Jpython where there is the original C implementation and a pure Java implementation of the language.
The main argumant against this is -- its a ton of work for not much benefit.
The official Sun jvm and supporting jni libraries are written mostly in C, you would need to provide native assembler implementations for most of the C POSIX APIs at the very least.
Also the original design goal of C was 'a portable assembly language' and to a large extent it still meets these goals. C produces efficient machine code and most C compilers will let code machine instructions inline with the C code.
Another benefit of C is the number of cross compilers available, you dont need to run the development environment on tHe target architecture, you can deveop and unit test on your favourite paltform/IDE, when you are ready you can then export your executables to the target platform.
Jikes RVM and Sun's Maxine provide a JVM implementation with little (of the order of 1 kloc) native code. However, both VMs require an OS and are only research implementations. The process of creating a stream of octets that form machine code, is obviously achievable in Java.
Have a look at JNode. They have been working on this for years.
http://www.jnode.org/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What program can I use to decompile a class file? Will I actually get Java code, or is it just JVM assembly code?
On Java performance questions on this site I often see responses from people who have "decompiled" the Java class file to see how the compiler optimizes certain things.
Update February 2016:
www.javadecompilers.com lists JAD as being:
the most popular Java decompiler, but primarily of this age only. Written in C++, so very fast.
Outdated, unsupported and does not decompile correctly Java 5 and later
So your mileage may vary with recent jdk (7, 8).
The same site list other tools.
And javadecompiler, as noted by Salvador Valencia in the comments (Sept 2017), offers a SaaS where you upload the .class file to the cloud and it returns you the decompiled code.
Original answer: Oct. 2008
The final release of JSR 176, defining the major features of J2SE 5.0 (Java SE 5), has been published on September 30, 2004.
The lastest Java version supported by JAD, the famous Java decompiler written by Mr. Pavel Kouznetsov, is JDK 1.3.
Most of the Java decompilers downloadable today from the Internet, such as “DJ Java Decompiler” or “Cavaj Java Decompiler”, are powered by JAD: they can not display Java 5 sources.
Java Decompiler (Yet another Fast Java decompiler) has:
Explicit support for decompiling and analyzing Java 5+ “.class” files.
A nice GUI:
It works with compilers from JDK 1.1.8 up to JDK 1.7.0, and others (Jikes, JRockit, etc.).
It features an online live demo version that is actually fully functional! You can just drop a jar file on the page and see the decompiled source code without installing anything.
There are a few decompilers out there... A quick search yields:
Procyon: open-source (Apache 2) and actively developed
Krakatau: open-source (GPLv3) and actively developed
CFR: open-source (MIT) and actively developed
JAD
DJ Java Decompiler
Mocha
And many more.
These produce Java code. Java comes with something that lets you see JVM byte code (javap).
To see Java source code check some decompiler. Go search for jad.
If you want to see bytecodes, just use javap which comes with the JDK.
I tried several, and Procyon seemed to work the best for me. It's under active development and supports many features of the latest versions of Java.
These are the others I tried:
CFR
Promising, but often failed method decompilation. I'll be keeping my eye on this one. Also actively developed with support for the latest Java features.
Krakatau
Takes a different approach in that it tries to output equivalent Java code instead of trying to reconstruct the original source, which has the potential of making it better for obfuscated code. From my testing it was roughly on par with Procyon, but still nice to have something different. I did have to use the -skip command-line flag so it wouldn't stop on errors. Actively developed, and interestingly enough it's written in Python.
JD-GUI
Worked, but Procyon's output was much better. Here's a page comparing Procyon output to the original and JD-GUI. JD-GUI is also available as an Eclipse plugin, which didn't work for me at all. Doesn't seem to be open source and development seems sporadic.
JAD
Worked, but only supports Java 1.4 and below. Also available as an Eclipse plugin. No longer under development.
I use JAD Decompiler.
There is an Eclipse plugin for it, jadeclipse. It is pretty nice.
Procyon includes a decompiler. It is FOSS.
Soot is an option for newer Java code. At least it has the advantage of still being recently maintained...
Also, Java Decompiler is a decompiler with both a stand-alone GUI and Eclipse integration.
Lastly, Jdec hasn't been mentioned, though it's not as polished as other options.
JD-GUI is really good. You could just open a JAR file and browse through the code as if
you are working on an IDE. Good stuff.
Here's a list of decompilers as of Feb 2015:
Procyon, open-source, https://bitbucket.org/mstrobel/procyon/wiki/Java%20Decompiler
CFR, free, no source-code available, http://www.benf.org/other/cfr/
JD, free for non-commercial use only, http://jd.benow.ca/
Fernflower, open-source, https://github.com/fesh0r/fernflower,
JAD – given here only for historical reason. Free, no source-code available, http://varaneckas.com/jad/
Outdated, unsupported and does not decompile correctly Java 5 and later.
You may test above-mentioned decompilers online, no installation required and make your own educated choice.
Java decompilers in the cloud: http://www.javadecompilers.com/
There are a few programs you can use. You will get the actual Java code, but sometimes the code will have been obfuscated so methods are named by one letter or number or a random mix of letters and numbers.
DJ Decompiler
Mocha
Most decompilers for Java are based on JAD. It's a great tool, but unfortunately hasn't been updated for a while and does not handle Java 1.5+ classes very well. I have not seen any tools that will properly handle 1.5+ classes.
Take a look at cavaj.
All of the JAD links listed so far far seem to be broken, so I found this site. Works great (for Linux, at least)! On Ubuntu 11.10 I had to download the static one for whatever reason.
http://www.varaneckas.com/jad
JAD is one that works and is simple.
Also, if you just want to see the methods, use javap.
If you want to see how the Java compiler does certain things, you don't want decompilation, you want disassembly. Decompilation involves transforming the bytecode into Java source, meaning that a lot of low level information is lost, and if you're wondering about compiler optimization, this is probably the very information you're interested in.
Anyway, I happen to have written an open source Java disassembler. Unlike Javap, this works even on highly pathological classes, so you can see what obfuscation tools are doing to your classes as well. It can also do decompilation, though I wouldn't recommend it.
JAD doesn't work for me (Ubuntu 11.10 issue) so I've moved forward and sopped on JODO. At least it has Open Java source code and been able to decompile my .class properly.
I recommend to check out 'branches/generic' branch first. The trunks is not stable.
On IntelliJ IDEA platform you can use Java Decompiler IntelliJ Plugin. It allows you to display all the Java sources during your debugging process, even if you do not have them all. It is based on the famous tools JD-GUI.
With AndroChef Java Decompiler you can decompile apk, dex, jar and java class-files. It's simple and easy. AndroChef JD is based on FernFlower. You can evaluate it in 10 free uses.
AndroChef supports Java language features like generics, enums and annotations. According to some studies, AndroChef Java Decompiler is able to decompile 98.04% of Java applications generated with traditional Java compilers - a very high recovery rate. It is simple but powerful tool that allows you to decompile Java and Dalvik bytecode (DEX, APK) into readable Java source.
For OSX I recommend: jarzilla or JD-GUI
They both allow you to view jar,war,etc. file content and decompiles any class files inside of them.
Jarzilla: https://code.google.com/p/jarzilla/
JD-GUI: http://jd.benow.ca/