The first week has gone by since the Android SDK has been made available to the public. No matter how well Android fits into the existing Java landscape, it will strengthen Java (the language) in comparison to other languages and this will be very good for Java (the platform) also. Android is, of course, Google's mobile API, meant to standardize mobile application deployment around Java much as GWT is meant to standardize client-side Javascript development by translating Java into Javascript. Here are some of the first reactions from the community in the first week:

• A developer's perspective on Google's Android
• Google Calling: Inside Android, the gPhone SDK
• Google Android: Initial Impressions and Criticism
• Why Android will start the mobile Tornado

What is your first impressions? It's obvious there's a need for something like this, because mobile devices are so common, but the carriers and manufacturers protect their markets so much that programming for them tends to target specific devices - i.e., the Nokia P6225, versus "all Nokia devices" or perhaps "all Sprint phones" instead of "all devices." Do you think this project will be the way to kickstart mobile development?

2 days after Android SDK release, ZK mobile has a quick turnaround. (Twitter as an example) http://blogs.pathf.com/agileajax/2007/11/zk-on-android.html

blatant self marketing follows: http://www.logemann.org/2007/11/14/first-impression-of-the-android-sdk/

I think its gonna be cool to see what developers come out with for the challenge. http://code.google.com/android/adc.html Pretty cool route for Google.

Hi As far as i know, this is not java. Yes you write your own code in java and then....then google compile to java...and then...recompile to .....something else.... This is not a java virtual machine....Is android virtual machine....Is like if you say that the code you write with microsoft .net in J# is java..Cos is not... Other thing is if this is nice or not....The key is that Google didnt want to accept the Sun Java license....So they did something else....But we are not talkin about java

It is java language, but not java platform and they say nothing else on their website. If I heard correctly Sun uses a different jvm for smartcards too, why no different vm (but for a whole class of devices) if it promises better performance. Since they compile it from bytecode there could be a compiler on the phone itself to convert java classes to dalvik code on the fly when uploaded to the phone.

So what? Why are you getting so animated about this? Android looks like a very promising technology, jvm or not. I'm all for another vm implementation specifically designed for mobile devices if it provides better performance/efficiency. The upside to some is that it's java language, so you can use java based tools to develop these apps, like the beautiful IntelliJ. DSL would of been nice as well, but we'll see what happens and how it compares to what ever apple is going to release. Ilya

This is not a java virtual machine....Is android virtual machine........But we are not talkin about java

Read the spec for the JVM. Anything that can read byte code in a .class file and execute it, is a JVM. All other things (JIT, GC algorithm, etc...) are optional and left to the discretion of implementors. In this case, Java code is compiled into .class files. Then the programs are run with Google's VM, which consequently, is still a JVM.

Read the spec for the JVM. Anything that can read byte code in a .class file and execute it, is a JVM. All other things (JIT, GC algorithm, etc...) are optional and left to the discretion of implementors.

In this case, Java code is compiled into .class files. Then the programs are run with Google's VM, which consequently, is still a JVM.

This isn't actually the case. The Dalvik VM doesn't understand Java bytecode, it executes files in the Dalvik Executable (.dex) format. A developer tool called "dx" is used to transform the .class files before they get anywhere near the hardware. Android packages (.apk files) are deployed on the device and sandboxed by running as different users within a Linux kernel. What we do get is Java-the-language and some of Java-the-API, and of course all the Java tools (including the Android Eclipse plug-in). It's perhaps worth stating, nothing's preventing manufacturers from shipping a Java VM on an Android-based phone, just as they ship Java VMs on Symbian OS phones today. But by itself, the Dalvik VM is not part of Java-the-platform. (Whether this matters or not is a whole other debate.)

Read the spec for the JVM. Anything that can read byte code in a .class file and execute it, is a JVM. All other things (JIT, GC algorithm, etc...) are optional and left to the discretion of implementors.

In this case, Java code is compiled into .class files. Then the programs are run with Google's VM, which consequently, is still a JVM.

This isn't actually the case. The Dalvik VM doesn't understand Java bytecode, it executes files in the Dalvik Executable (.dex) format. A developer tool called "dx" is used to transform the .class files before they get anywhere near the hardware. Android packages (.apk files) are deployed on the device and sandboxed by running as different users within a Linux kernel.

What we do get is Java-the-language and some of Java-the-API, and of course all the Java tools (including the Android Eclipse plug-in).

It's perhaps worth stating, nothing's preventing manufacturers from shipping a Java VM on an Android-based phone, just as they ship Java VMs on Symbian OS phones today. But by itself, the Dalvik VM is not part of Java-the-platform. (Whether this matters or not is a whole other debate.)

It matters because sooner or later (probably sooner) Google will diverge the language. They're also if my crystal ball is working going to release Windows (and possible Mac and/or Linux) versions, pushing them through their websites and services as "required plugins" and listing them as JVMs, causing existing Java applications (particularly applets) to break. Your users will demand you deliver things in Google format instead of standard classfiles, and Sun will be out of the Java loop. Google will have de-facto control over the language.

Read the spec for the JVM. Anything that can read byte code in a .class file and execute it, is a JVM. All other things (JIT, GC algorithm, etc...) are optional and left to the discretion of implementors.

In this case, Java code is compiled into .class files. Then the programs are run with Google's VM, which consequently, is still a JVM.

This isn't actually the case. The Dalvik VM doesn't understand Java bytecode, it executes files in the Dalvik Executable (.dex) format. A developer tool called "dx" is used to transform the .class files before they get anywhere near the hardware. Android packages (.apk files) are deployed on the device and sandboxed by running as different users within a Linux kernel.

What we do get is Java-the-language and some of Java-the-API, and of course all the Java tools (including the Android Eclipse plug-in).

It's perhaps worth stating, nothing's preventing manufacturers from shipping a Java VM on an Android-based phone, just as they ship Java VMs on Symbian OS phones today. But by itself, the Dalvik VM is not part of Java-the-platform. (Whether this matters or not is a whole other debate.)

It matters because sooner or later (probably sooner) Google will diverge the language.
They're also if my crystal ball is working going to release Windows (and possible Mac and/or Linux) versions, pushing them through their websites and services as "required plugins" and listing them as JVMs, causing existing Java applications (particularly applets) to break.
Your users will demand you deliver things in Google format instead of standard classfiles, and Sun will be out of the Java loop. Google will have de-facto control over the language.

Google can't "diverge" Java, since use of the Java trademark etc is subject to passing a compatibility test for a given platform. As others have already said, yes Andrioid does use the Java syntax but no it is not a recognised Java(tm) runtime environment. It can't pass the compatability tests for JSE or JME (or JEE ;-), and is therefore not called 'Java SE Andriod Edition' or some such. The argument about what actually gets deployed _is_ irrelevant since Java native compilers can turn classes into native instructions even if you deploy class files. The point is, as long as the full Java (SE/ME/EE) API is supported and the comaptibility tests pass, then you have a bona fide Java implementation. Even if Google do push this as a required plugin for Google apps on the non-mobile Web, it won't be, and can't replace, Java, without the JCP agreeing to re-scoping an existing platform spec or creating a new one just for Google. But hang on, Sun are already working in the mobile space... let me see, yes, JavaFX... With the power being packed into modern mobile devices (can't call them phones any more), Java ME is looking more and more dated. If JavaFX can unify mobile and desktop GUI skills then I think this is far more likely to form the basis of a future successful Java Mobile API.

Read the spec for the JVM. Anything that can read byte code in a .class file and execute it, is a JVM. All other things (JIT, GC algorithm, etc...) are optional and left to the discretion of implementors.

In this case, Java code is compiled into .class files. Then the programs are run with Google's VM, which consequently, is still a JVM.

This isn't actually the case. The Dalvik VM doesn't understand Java bytecode, it executes files in the Dalvik Executable (.dex) format.

My mistake. Thanks for clearing that up.

This isn't actually the case. The Dalvik VM doesn't understand Java bytecode, it executes files in the Dalvik Executable (.dex) format. A developer tool called "dx" is used to transform the .class files before they get anywhere near the hardware.

What's stopping someone to just add a small layer on top of the Dalvik VM that does this transformation automatically and transparently?

Hi

As far as i know, this is not java. Yes you write your own code in java and then....then google compile to java...and then...recompile to .....something else

If you have ever developed for something like the "awesome" MIDP 1.0 or 2.0 and seen the results on different phones you might get a very good pointer why that is the case.

Hi, Small devices means small resources. The problem is not really the SDK (J2ME or something else) but the right jvm ( What happened to jedoek??? It was a good JVM). Esmertec's commercial Jbed (see: http://www.esmertec.com/solutions/mobile_multimedia/jbed_cdc/VM/index.shtml )was doing the same thing: transforming java code to native code. Esmertec was doing this for many years long and it's largely accepted by companies that requires real-time execution from their java code. It was funny to know that Esmertec has contributed to the Open Handset Alliance initiative with their OMA applications (MMS, WAP, DRM, SyncML, and IM). Android is free and Jbed not! Android Jbed killer? http://www.esmertec.com/solutions/mobile_multimedia/android_platform/ Regards, Abdeslam

Being curious about the Android SDK, I put together a quick Android Blackjack game to see what was involved to get something working and to start to exploring what issues may present themselves regarding the custom VM. My limited overview can be found at: http://blog.bumblemachine.com/archives/15 For the most part, all of my Java knowledge seems to apply and while I was worried about things like reflection, everything I did in my very, very, basic application worked. I will also add that they seem to have take an approach similiar to Flex with the way the GUI components are laid out in XML. I haven't dug too deep yet, but so far it hasn't been a bad experience.

It's obvious there's a need for something like this, because mobile devices are so common, but the carriers and manufacturers protect their markets so much that programming for them tends to target specific devices - i.e., the Nokia P6225, versus "all Nokia devices" or perhaps "all Sprint phones" instead of "all devices."?

What I have seen so far with regards to the API looks very promising - BUT I don't really believe that you can prevent the above to happen. Keep in mind that various parts of the API are optional. Manufactures and phone companies will continue to create proprietary extensions because that is basically their business model. If a phone does not outshine an older phone "feature wise" what is the purpose of a new phone?

Here's my impressions: http://www.manageability.org/blog/stuff/google-android-disappointment with another take, more on the business strategy side: http://www.manageability.org/blog/stuff/google-open-source-gphone