Is Android equivalent to Java? Please note that I'm not talking about equality, I'm talking about equivalence, just like in P = NP.
Equivalent class/bytecode format On many levels, Android and Java are obviously equivalent. Android applications are written in the Java language and compiled using JDK's javac (or similar tools, such as ECJ). This process generates standard Java bytecode (. Class files). These files are then converted into. Dex file of Android, which is a Java class file, has different formats from the perspective of use. Yes, this is a better format; Sun's design has been greatly improved since 1994. But just like you can convert a picture in GIF format into a more advanced, perfect and completely equivalent PNG format, although their byte streams are completely different.
Equivalent file formats vary greatly in details, mainly for optimization. For example, if we are simply satisfied with the low-efficiency video data stream and do not adopt high-end compression technology across different frames, then we can avoid the trouble of patenting MPEGLA video decoding.
Android-specific class file design has several motives; In order to avoid conflicts with Sun's intellectual property protection, this is obviously a major factor. In any case, Google is not far enough from Java. These two file formats are very similar. They are different in specific underlying data structures, but these structures are syntactically consistent and store exactly the same information. I believe that in JavaSE or JavaME VM, it is easy to add a. dex parser to their system class loader to load "Android classes".
Android SDK depends on. Java-& gt； . class->； The fact. Dex conversion is negligible and there is no loss. The fact that it is "not lost" is very important: when GIF = PNG, it is different from a damaged JPG file-it cannot decode exactly the same information. If the JVM and Dalvik are independent, it is difficult for you to write a relatively simple tool to convert one compiled code into another-there is no loss: no information is lost, no redundancy is used to compensate that a feature is first-class in one VM but not in the other VM, and no extra runtime layer is needed to implement the core API of the other VM in one VM.
I know how complicated dx converters are. I have read its source code. That bytecode converter is a huge, full-featured decompilation/recompilation program, which is completed through SSA construction. But this converter is still conceptually irrelevant; The mapping from Java bytecode to Dalvik bytecode is smooth in design. Optimize the stack relative to the fine parts in the register architecture; And important things, such as the type system of VM layer, are completely consistent. )
It is easy to see that VM is equivalent to Dalvik and JVM. Not just source code or bytecode formats: so are their runtime versions. Once an "Android class" is loaded into Dalvik VM, it will run and work like a Java class. If you know Java programming (go deep into high-level and low-level details), you also know Android programming. You just need to learn some new API and framework concepts. They are peer-to-peer systems.
You remember Microsoft. Net? When? NET was just born, and the Java camp quickly countered the accusation. Java plagiarism network. I am one of them, but today I see the problem more clearly. Yes, it was once the product of serious plagiarism; C# 1.0 is a ... The easiest way to distinguish one language from another is to look at their idiomatic styles-for example, ToString () and toString (). But on the most important VM specification, Microsoft has done a lot of homework. Its CLR, CLI and core framework are very different from Java, so it cannot be said that the equation JVM = CLR. You can't use simple file format conversion tools to convert your compiled Java classes into files that can be used in. NET runtime.
Do you want proof? You just have to look at IKVM to know. This is an interesting project, which can make Java and. NET is cross-platform-compatible, so your Java code can be downloaded in CLR (or equivalent. NET runtime, such as Mono) without modification … but IKVM is not a simple dx-like file format converter. The conversion of Java classes and the adaptation of Java core API are very complicated, even for a simple HelloWorld program. The internal mechanisms of each platform, such as reflection, security, parallelism, exception handling, bytecode verification, I/O and other core APIs, are basically the same in characteristics, but completely different in details. Some dead-end situations will force IKVM to drill through one fire circle after another and let Java code continue to run. NET virtual machine. It needs to rely on a huge extra runtime layer to adapt to the complete JavaSE API from OpenJDK source code. I have been paying close attention to the development of IKVM for several years-I read this wonderful IKVM blog-so I am fully aware that they are trying to adapt Java programs and JavaSE applications. Net. The work is still unfinished; And many parts need to be at the cost of losing some performance. )
(The old Visual J++ Visual J# is not a simple Java-to-. Network converter. I hate to say it, but we can say that the compatibility between Visual J# and Java is not much better than the earliest IKVM. )
I introduce P = NP into the discussion; Someone introduced Turing equivalence theory, saying that any Turing-complete platform/language /VM is equivalent to each other. Yes, but it's irrelevant. Turing model is too general; Considering this superficial value will destroy more software patent systems (although this is not a bad thing! )。 We need to draw a line for JVM equivalence on the ground, a line closer to the actual needs and far away from Turing equivalence. In my opinion, this trivial binary format conversion, exhausted advanced source code and runtime compatibility make Android obviously within the Java equivalence line.
API and runtime are equivalent. Android uses a fairly large subset of JavaSE APIs. These APIs (from Harmony Project) are all new implementations, but they are modeled based on JavaSE. Harmony could have obtained JavaSE certification if it wasn't for TCK licensing. But this does not change the fact that Harmony and JavaSE APIs are completely equivalent-this is intentional, not accidental. As the famous JRuby character Charles Nutter recently wrote:
Android supports an incomplete (but quite large) subset of Java 1.5 class library. This subset is so large that a complex JRuby project can run on Android without any modification and few restrictions.
It seems that Dalvik is so close to the JVM that it has to be fully compatible with most JVM specifications, including the fully detailed JMM (just as Android supports Java-style threads and concurrency, which has gone deep into the advanced java.util.concurrent package). But why are there so many arguments that Dalvik is a new VM or that Dalvik can't run Java classes (90% of the forums and blogs discussing this lawsuit hold this view)?
Finally, this blog is not about the legal basis of the lawsuit between Oracle Bone Inscriptions and Google. I will ignore (I will delete) those off-topic comments (if they have nothing to do with Android = Java). I just hate the nonsense "Android has nothing to do with Java"; Advocates of Google and Android must find a more meaningful argument.
I will wait and see the progress of this lawsuit with all my foresight until all the details and final results come out. Don't be naive unless you have inside information (I don't). Stay calm. We don't know all the real motives and plans of Oracle Bone Inscriptions or Google. We don't know the story behind this screen. Since Google first announced the birth of Android in 2007 (which led to the collapse of JavaME's ecological environment), Sun hated it, but in the end he had to act with his tail between his legs. I don't believe that any shareholder holding company with $654.38+0 billion will be altruistic: not Google, not Oracle Bone Inscriptions, not even my favorite old company. Let's wait and see. )
I don't believe that Google can't create a platform based on Java style that doesn't deviate too far from Java. NET). Dalvik, as well as the Android framework, may be the final result of weighing the desire to be highly compatible with a large number of existing Java programs, class libraries, Java geniuses and Java tool chains. Microsoft gave up the benefits of porting ready-made Java and created a brand new one. Net. Google didn't do that.
This Android = Java equation obviously does not contain everything (not one-to-one correspondence). Each platform has its own unique API. Of course, Android is a complete operating system, including a Linux-based kernel, graphics system and telecom stack. Obviously, I will only talk about the most commonly used part: Java-centered user area/application framework, which relies on Java source code, Java classes (regardless of format), Java APIs (including thousands of commonly used Java SEAAPIs) and excellent Java-like virtual machines. An accurate statement about the relationship between Android and other Java platforms is the concept of using version. I once remember a blog saying "Android doesn't have a' J'". Well, it's not too late for me to say: I suggest that Android be renamed Java GE(Java Google Edition). In this way, there will be no more confusion.
From: 5 1CTO Technical Forum