-
The first week of the Android SDK (17 messages)
- Posted by: Carl Rosenberger
- Posted on: November 19 2007 05:19 EST
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: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?Threaded Messages (17)
- Re: The first week of the Android SDK by Kadacha Muller on November 19 2007 06:58 EST
- mine is missing by Marc Logemann on November 19 2007 09:55 EST
- $10 Million Developer Challenge by Andrew Rubalcaba on November 19 2007 15:10 EST
- this is not java!!!! by Bruno Sanz on November 19 2007 15:12 EST
- Re: this is not java!!!! by Georg Mueller on November 19 2007 15:32 EST
- Re: this is not java!!!! by Ilya Sterin on November 19 2007 22:12 EST
- Re: this is not java!!!! by tony siciliano on November 20 2007 07:17 EST
-
Re: this is not java!!!! by Dave H on November 20 2007 01:48 EST
-
Re: this is not java!!!! by Jeroen Wenting on November 21 2007 01:41 EST
- Google Diverging Java by Phil Haigh on November 27 2007 10:07 EST
- Re: this is not java!!!! by tony siciliano on November 21 2007 08:43 EST
- Re: this is not java!!!! by arjan tijms on November 21 2007 01:10 EST
-
Re: this is not java!!!! by Jeroen Wenting on November 21 2007 01:41 EST
-
Re: this is not java!!!! by Dave H on November 20 2007 01:48 EST
- Re: this is not java!!!! by Karl Banke on November 21 2007 03:42 EST
- Re: this is not java!!!! by tarta mudo on November 21 2007 10:51 EST
- Re: The first week of the Android SDK by Kenneth Riggio on November 19 2007 18:24 EST
- The "specific phone" by Karl Banke on November 21 2007 03:47 EST
- Yet another blatant self marketing by Carlos Perez on November 21 2007 07:10 EST
-
Re: The first week of the Android SDK[ Go to top ]
- Posted by: Kadacha Muller
- Posted on: November 19 2007 06:58 EST
- in response to Carl Rosenberger
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 -
mine is missing[ Go to top ]
- Posted by: Marc Logemann
- Posted on: November 19 2007 09:55 EST
- in response to Kadacha Muller
blatant self marketing follows: http://www.logemann.org/2007/11/14/first-impression-of-the-android-sdk/ -
$10 Million Developer Challenge[ Go to top ]
- Posted by: Andrew Rubalcaba
- Posted on: November 19 2007 15:10 EST
- in response to Carl Rosenberger
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. -
this is not java!!!![ Go to top ]
- Posted by: Bruno Sanz
- Posted on: November 19 2007 15:12 EST
- in response to Carl Rosenberger
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 -
Re: this is not java!!!![ Go to top ]
- Posted by: Georg Mueller
- Posted on: November 19 2007 15:32 EST
- in response to Bruno Sanz
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. -
Re: this is not java!!!![ Go to top ]
- Posted by: Ilya Sterin
- Posted on: November 19 2007 22:12 EST
- in response to Bruno Sanz
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 -
Re: this is not java!!!![ Go to top ]
- Posted by: tony siciliano
- Posted on: November 20 2007 07:17 EST
- in response to Bruno Sanz
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. -
Re: this is not java!!!![ Go to top ]
- Posted by: Dave H
- Posted on: November 20 2007 13:48 EST
- in response to tony siciliano
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.
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.)
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. -
Re: this is not java!!!![ Go to top ]
- Posted by: Jeroen Wenting
- Posted on: November 21 2007 01:41 EST
- in response to Dave H
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.) -
Google Diverging Java[ Go to top ]
- Posted by: Phil Haigh
- Posted on: November 27 2007 10:07 EST
- in response to Jeroen Wenting
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. 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. -
Re: this is not java!!!![ Go to top ]
- Posted by: tony siciliano
- Posted on: November 21 2007 08:43 EST
- in response to Dave H
My mistake. Thanks for clearing that up.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. -
Re: this is not java!!!![ Go to top ]
- Posted by: arjan tijms
- Posted on: November 21 2007 13:10 EST
- in response to Dave H
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? -
Re: this is not java!!!![ Go to top ]
- Posted by: Karl Banke
- Posted on: November 21 2007 03:42 EST
- in response to Bruno Sanz
Hi
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.
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 -
Re: this is not java!!!![ Go to top ]
- Posted by: tarta mudo
- Posted on: November 21 2007 10:51 EST
- in response to Bruno Sanz
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 -
Re: The first week of the Android SDK[ Go to top ]
- Posted by: Kenneth Riggio
- Posted on: November 19 2007 18:24 EST
- in response to Carl Rosenberger
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. -
The "specific phone"[ Go to top ]
- Posted by: Karl Banke
- Posted on: November 21 2007 03:47 EST
- in response to Carl Rosenberger
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? -
Yet another blatant self marketing[ Go to top ]
- Posted by: Carlos Perez
- Posted on: November 21 2007 07:10 EST
- in response to Carl Rosenberger
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