|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 17
Messages: 17
Messages: 17
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The first week of the Android SDK
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?
|
|
|
Message #242830
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
this is not java!!!!
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
|
|
|
Message #242831
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not 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.
|
|
|
Message #242834
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The first week of the Android SDK
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.
|
|
|
Message #242837
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not java!!!!
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
|
|
|
Message #242841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not java!!!!
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.
|
|
|
Message #242859
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not 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.
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.)
|
|
|
Message #242876
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not 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.
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.
|
|
|
Message #242880
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not java!!!!
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.
|
|
|
Message #242881
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The "specific phone"
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?
|
|
|
Message #242893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not 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.
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.
|
|
|
Message #242901
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: this is not java!!!!
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?
|
|
|
Message #243025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google Diverging 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.
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
