Currently Java on mobile devices is sort of a mess, while J2ME is available on a huge number of devices it lacks the feature set Java developers expect from J2SE. Given any particular mobile phone a developer will find a sub set of features available, not to mention questionable quality and user experience.
For example, I own a Cingular 8125, a Windows Mobile 5 Device. It contains a very capable processor, however in traditional MS style, Java is a second class citizen at best. Each Java application I install is only accessible by first launching an application manager. In contrast, if I install a native application it is available under the programs folder, next to the pre-installed applications. This reminds users they are using a non-native application and smears mud on the face of Java.
The real advantage of using Java over other languages and platforms is the JVM. A fully compliant JVM provides an incredible number of features to a Java developer. This list of features is even larger if you consider the huge number of open source libraries that target the JVM. Making these features available to the mobile developer will prower the coming mobile renaissance.
Those looking at Google's Android might be disappointed to find that the VM provided is not a J2SE compliant VM. Android as it stands now looks more like a mobile phone OS which can be extended easily and openly. The framework provided directly addresses the issue I have with my phone, applications written for Android have the same level of access as every other application and they are presented in exactly the same way. It is almost irrelevant that Java is used at all since code written to Android will not be terrible useful on other devices. This is due to the fact that the VM on Android is a subset of J2SE and is not a subset that maps to J2ME. Additionally Android contains mobile specific APIs found on no other device. It is a new J2ME at this point with an unknown audience. Is it cool that there is a new open source phone OS which is easy to develop for? Absolutely, but it does follow the old "write once, run everywhere" philosophy.
Enter Sun's Java FX Mobile which is approximately a J2SE stack targeting the next generation of mobile devices. I say approximately because we don't exactly which libraries will be available in Java FX Mobile. Will CORBA be included, let's hope so. Lets hope it is a full J2SE+J2ME implementation. With any luck the growing modular JVM movement will influence Java FX Mobile, allowing features to be added as required. I guess there is no reason why a large number of standard packages could not be broken out as jars...want swing? use javax.swing.jar.
We have not seen any devices running either of these two Java implementations. It is unclear how wide spread these two technologies will become. Of course there is the iPhone and some believe Java will be available there as well. You can bet your shorts that it will not inter operate with either of the above technologies. Of course a huge number of embedded devices exits that can run Linux and at least some flavor of Java, like the new Bug Lab's Lego embedded system.
Even though Java is fragmenting (or is fragmented) in the mobile space, at least as a Java developer I can use the language and tools I am most familiar with to develop applications on an ever growing number of devices. And thats cool!
Wednesday, November 14, 2007
Wednesday, May 09, 2007
JavaFX or SwingFX
Those JavaFX demos at JavaONE look great. I have been working with Swing for 10 years (9? time flies), I know what Swing can do if you put the time in. It is very tricky to make swing applications look excellent, and anything to make that simpler is awesome. It looks like JavaFX is just that, an improved way to create an interface in a Java application. But JavaFX is being talked about as competition to Silverlight, Apollo, and Flash and I am not sure about all that.
First lets think about Flash...
Why does Flash exists, what problems does it solve? Why is Flash better then an Applet? Why does Flash need to be replaced? Perhaps answering these questions will shed some light on this JavaFX thing.
Why does Flash exists, what problems does it solve?
Flash exists because DHTML/AJAX/etc is extremely limited in terms of precise layout, animation and media. Both Flash and applets improve upon this serious set of limitations.
Why is Flash better then an Applet?
Flash has a quicker startup time and might be on a few more browsers. Java however has a bijillion open source projects available, has a much better security model, higher graphics fidelity and once loaded is much faster then Flash. Java to me looks like the bester answer for a rich web experience, yet many many more web sites use Flash then Java. Why?
Tools. Flash has better tools then Java for creating rich interfaces. I think this is the only reason why Flash is everywhere and Applets are not. The tools available for Flash allow an amateur to create amazing web pages. Flash programming may be the tonka truck of programming languages, but it is very accessible. If JavaFX is going to compete it must create the best tools on the market.
Why does Flash need to be replaced?
If Flash has great tools and is easy to program why does it need to be replaced at all? Some of the advantaged of Java over Flash that I listed above are all good reasons to replace Flash. Maybe Ill just download the source code to Flash and make some improvements, improve the speed of Flash so it is on par with Java....oh right, I can't. Java is the first rich web technology available with an open licenses, this is big. Java already has a slew of open source projects written with it, that is work that has been done for you. Need a bar code reader in your application, I bet you can find five open source libraries for that, try that with Flash. As Java moves back into the rich interface space, a ton of projects will pop-up to make your application easier to write AND look better.
Silverlight and Apollo
When I heard about these projects, I thought to myself, "Lucas, why would you ever use these platforms when you can use Java?" and then I thought about it some more. Adobe is trying to expand the usefulness of the Flash programmers in the world and leverage their existing tools. This makes perfect sense and is a really good move, reusing the resources they have for a new market. Silverlight, looks like JavaLite to me, the last time I tried to use a MS tool for creating software I was struck by how buggy and feature poor everything was. I was trying to get a C# mobile application to unzip a file and wow, I was of the track and in the weeds, this was nearly unexplored territory in the world of .NET. Seriously, go download Visual Studio and the Mobile add on, you will swear your the first person to every actually use it.
Conclusion
To compete with Adobe in both the browser and desktop space Sun must make tools for creating rich applications on par with Adobe's. If we also get a tool for creating mobile and embedded applications at the same time that would be slam dunk for Sun. Until then, content creators will not choose Java regardless of how handy/fast/ubiquitous Java is. Silverlight is irrelevant, a billion people will be forced to use it in classic Microsoft style, it will be buggy and expensive. Sun could make the best platform in the world and they would still be stuck competing with Microsoft.
Until I see the tools to compete Adobe, JavaFX as a clever way of creating Swing components, with all the same limitations that come with Swing Applications and Applets.
First lets think about Flash...
Why does Flash exists, what problems does it solve? Why is Flash better then an Applet? Why does Flash need to be replaced? Perhaps answering these questions will shed some light on this JavaFX thing.
Why does Flash exists, what problems does it solve?
Flash exists because DHTML/AJAX/etc is extremely limited in terms of precise layout, animation and media. Both Flash and applets improve upon this serious set of limitations.
Why is Flash better then an Applet?
Flash has a quicker startup time and might be on a few more browsers. Java however has a bijillion open source projects available, has a much better security model, higher graphics fidelity and once loaded is much faster then Flash. Java to me looks like the bester answer for a rich web experience, yet many many more web sites use Flash then Java. Why?
Tools. Flash has better tools then Java for creating rich interfaces. I think this is the only reason why Flash is everywhere and Applets are not. The tools available for Flash allow an amateur to create amazing web pages. Flash programming may be the tonka truck of programming languages, but it is very accessible. If JavaFX is going to compete it must create the best tools on the market.
Why does Flash need to be replaced?
If Flash has great tools and is easy to program why does it need to be replaced at all? Some of the advantaged of Java over Flash that I listed above are all good reasons to replace Flash. Maybe Ill just download the source code to Flash and make some improvements, improve the speed of Flash so it is on par with Java....oh right, I can't. Java is the first rich web technology available with an open licenses, this is big. Java already has a slew of open source projects written with it, that is work that has been done for you. Need a bar code reader in your application, I bet you can find five open source libraries for that, try that with Flash. As Java moves back into the rich interface space, a ton of projects will pop-up to make your application easier to write AND look better.
Silverlight and Apollo
When I heard about these projects, I thought to myself, "Lucas, why would you ever use these platforms when you can use Java?" and then I thought about it some more. Adobe is trying to expand the usefulness of the Flash programmers in the world and leverage their existing tools. This makes perfect sense and is a really good move, reusing the resources they have for a new market. Silverlight, looks like JavaLite to me, the last time I tried to use a MS tool for creating software I was struck by how buggy and feature poor everything was. I was trying to get a C# mobile application to unzip a file and wow, I was of the track and in the weeds, this was nearly unexplored territory in the world of .NET. Seriously, go download Visual Studio and the Mobile add on, you will swear your the first person to every actually use it.
Conclusion
To compete with Adobe in both the browser and desktop space Sun must make tools for creating rich applications on par with Adobe's. If we also get a tool for creating mobile and embedded applications at the same time that would be slam dunk for Sun. Until then, content creators will not choose Java regardless of how handy/fast/ubiquitous Java is. Silverlight is irrelevant, a billion people will be forced to use it in classic Microsoft style, it will be buggy and expensive. Sun could make the best platform in the world and they would still be stuck competing with Microsoft.
Until I see the tools to compete Adobe, JavaFX as a clever way of creating Swing components, with all the same limitations that come with Swing Applications and Applets.
Monday, April 16, 2007
Feature Request: External Annotations for Java 7
Annotations in Java allow developers to provide meta-data about a class. This meta-data is used by tools such as JPA, JAXB, JDBC and many others to perform their various functions. However, a developer may only annotate the classes they are writing. They cannot annotate existing classes, such as those provided by J2SE, a third party jar, or those classes generated by tool such as JAXB or wsimport.
When j2EE 5 was new, there was much talk about simplicity, tools no longer required XML descriptor files, since the classes themselves contained the required meta data. The trouble is that only one set of annotations can apply to a class, those annotations that were applied at development time.
Let me give an example of how it would be useful to annotate an existing class. Suppose you are developing an application that works with an existing web-service and you want to store some of the returned objects in a database. The first thing you do is point wsimport at the wsdl file and it generates a bunch of classes. Then you hand edit each class with the appropriate javax.persistence annotations. Ok, this sounds like it will work, but what happens when that wsdl changes slightly (say during development), you have to regenerate all the classes and reapply the persistence annotations, an error prone process to say the least, a unit test could save you some errors, but what could be worse then writing unit test that check annotations:)
It would be much simpler if you could apply those annotations in an external file. Imagine a XML file for annotating a ContactInfo Class that looked something like this:
<annotations>
<class>
<annotation name='javax.persistence.Entity'>
<parameter name='name' valuetype='string'>ContactInformation</parameter>
</annotation>
</class>
<field name='Addresses'>
<annotation name='javax.persistence.OneToMany'>
<parameter name='cascade' valuetype='constant'>javax.persistence.CascadeType.ALL</parameter>
<parameter name='fetch' valuetype='constant'>javax.persistence.FetchType.EAGER</parameter>
</annotation>
</field>
<method name='sendMail' parameters='String,String'>
<annotation name='Deprecated'>
</annotation>
</method>
</annotations>
Maybe or more Java like format would make sense, we could borrow from the interface format, something like:
package org.someone.else's.packages;
@Entity(name='"ContactInformation")
public annotation ContactInfo {
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
protected List<Address> addresses;
@Deprecated public int sendMail(String from, String mode);
}
I image that these annotation files could exists in your Java source. You would place them in a package just as you would a class, so if you wanted to add an annotation to java.awt.Color, you would create the file [srcbase]/java/awt/Color.annotation
This allow javac to check that you are using the new annotations correctly and that you are annotating existing fields and methods. This file (or a 'compiled' version) would also be included in any Jar file you create, so the annotations can be appended at runtime.
you might ask, "Doesn't this just add back the XML configuration files we got rid of?" i would say no, because they are optional, you can always simply annotate a class you are writing in the standard way. Plus, the annotations are all in a standard format and you gain compile time checking.
Also, say you want to distribute a jar that contains your basic data types, but you don't want to include the nasty details of how it maps to your database, then you could simply omit the *.annotation files.
If Properties do find their way into Java and they turn out to be annotation based, then this could provide way of applying annotations to legacy code, since no changes would be required to the source code, simply annotate the existing classes anyway you want.
I would love some feedback on this!
-Lucas
When j2EE 5 was new, there was much talk about simplicity, tools no longer required XML descriptor files, since the classes themselves contained the required meta data. The trouble is that only one set of annotations can apply to a class, those annotations that were applied at development time.
Let me give an example of how it would be useful to annotate an existing class. Suppose you are developing an application that works with an existing web-service and you want to store some of the returned objects in a database. The first thing you do is point wsimport at the wsdl file and it generates a bunch of classes. Then you hand edit each class with the appropriate javax.persistence annotations. Ok, this sounds like it will work, but what happens when that wsdl changes slightly (say during development), you have to regenerate all the classes and reapply the persistence annotations, an error prone process to say the least, a unit test could save you some errors, but what could be worse then writing unit test that check annotations:)
It would be much simpler if you could apply those annotations in an external file. Imagine a XML file for annotating a ContactInfo Class that looked something like this:
<annotations>
<class>
<annotation name='javax.persistence.Entity'>
<parameter name='name' valuetype='string'>ContactInformation</parameter>
</annotation>
</class>
<field name='Addresses'>
<annotation name='javax.persistence.OneToMany'>
<parameter name='cascade' valuetype='constant'>javax.persistence.CascadeType.ALL</parameter>
<parameter name='fetch' valuetype='constant'>javax.persistence.FetchType.EAGER</parameter>
</annotation>
</field>
<method name='sendMail' parameters='String,String'>
<annotation name='Deprecated'>
</annotation>
</method>
</annotations>
Maybe or more Java like format would make sense, we could borrow from the interface format, something like:
package org.someone.else's.packages;
@Entity(name='"ContactInformation")
public annotation ContactInfo {
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
protected List<Address> addresses;
@Deprecated public int sendMail(String from, String mode);
}
I image that these annotation files could exists in your Java source. You would place them in a package just as you would a class, so if you wanted to add an annotation to java.awt.Color, you would create the file [srcbase]/java/awt/Color.annotation
This allow javac to check that you are using the new annotations correctly and that you are annotating existing fields and methods. This file (or a 'compiled' version) would also be included in any Jar file you create, so the annotations can be appended at runtime.
you might ask, "Doesn't this just add back the XML configuration files we got rid of?" i would say no, because they are optional, you can always simply annotate a class you are writing in the standard way. Plus, the annotations are all in a standard format and you gain compile time checking.
Also, say you want to distribute a jar that contains your basic data types, but you don't want to include the nasty details of how it maps to your database, then you could simply omit the *.annotation files.
If Properties do find their way into Java and they turn out to be annotation based, then this could provide way of applying annotations to legacy code, since no changes would be required to the source code, simply annotate the existing classes anyway you want.
I would love some feedback on this!
-Lucas
Subscribe to:
Posts (Atom)
