More specifically the Java language versus the Java platform. I have been playing around with some non-Ajax technologies for rich web clients. I think creating Ajax sites by hand is nuts. Thankfully, we have GWT, RAP and Visual Studio 2008 seems to have Ajax support directly in its palette. At the same time, it's clear that some very powerful forces are converging on Ajax. Namely Flash, Silverlight and JavaFX.
These 3 technologies do something that Ajax can't really do, or at least not very well. They bridge the gap between developers and designers. For example, if you are working in Visual Studio on your client application using Silverlight, the designer can open your Visual Studio project and edit the XAML form from Expression Blend. That's right, the Microsoft designer tools use Visual Studio projects as their project files.
I don't want to spend too much time on this, but you can script Silverlight in any language that the DLR supports. You can code Silverlight in any language that the CLR supports. You can code in Silverlight using C#, IronPython or JavaScript for example. Silverlight is really just a .Net runtime that runs as a browser plugin that depends on WPF to do all its shiny effects. These explanations are bit crude but I want to get to JavaFX sometime this year.
JavaFX is the Flash, Silverlight competitor from Sun. JavaFX is also a completely new scripting language i.e., it's not XML based and I have to ask why? Did Sun forget again that Java is a platform and not just a language? Why can't JavaFX be just like XAML? Forget the new language and just allow us to code in any language supported by the Java platform. I've seen some JavaFX scripting code and I don't care for it. I do not want this. I just want the presentation part. I want the code behind the presentation to be Groovy or any language of my choice that runs on the JVM.
I've talked before about how Matisse, the NetBeans GUI builder, only outputs Java code. The NetBeans JSP page editor, I'm not sure if that is also Matisse or not, suffers from the same problem. Any tooling made available for JavaFX will most likely have the same flaw.
At this point, I just wish I could say I don't care about JavaFX, I really wish I could. Unfortunately for me and fortunately for JavaFX, Sun has committed to bring JavaFX to Java ME, even the puny CLDC profile. With over a billion phones out there running the CLDC profile, it's sort of hard to ignore this. Java ME is a hard place to develop, you have the CLDC, CLDC/MIDP and CDC profiles. All profiles have different versions with tons of packages being optional and not to mention vendor specific packages. Anything JavaFX can do to help in that space would be appreciated.
In the meantime, JavaFX is far from version 1 and while Sun toils away at its new scripting language, you have to ask where are the designer tools? The tools that will actually compete with Microsoft Expression and Adobe Flex.
Friday, December 21, 2007
Sunday, December 16, 2007
Compilers no Longer a Threat?
This all started innocently. I've been using the excellent version 6 of NetBeans as my primary IDE for a while now. Have been doing so since the beta releases. Since Java is now my primary platform. I use it for Java, Groovy, JRuby and even C++. I also have the Microsoft Platform SDK hooked in so I can pretty much do all my Win32 C++ work from there also.
The NetBeans project claims NetBeans is the only IDE you need. Well, not quite, if you're looking into .Net for example, NetBeans is a dud. Not that you couldn't write plugins to support it but that seems unlikely. I was really interested in looking into .Net, well .Net Compact more precisely.
I have no commercial interests in .Net, I like my solutions, all jokes aside, to be portable. The compact edition of the framework however is something I find truly irresistible compared to the Java ME headache.
If you want to test drive .Net, you're in luck, you can just download a copy of Visual Studio Express from here and incur away. I've been having quite a bit of fun with Visual C# Express 2008. If you want to try .Net Compact however, well the express editions don't do compact. What to do? Both Visual Studio 2005 and 2008 offer a trial version available from here and here respectively and this is what I used initially.
Both these products have restricted licenses and I started looking for an IDE project that would work directly on the top of the .Net SDK. I wasn't expecting much really but I was simply shocked when I found out about SharpDevelop.
A very, very good clone of the Visual Studio IDE. It doesn't support C++ but it supports Boo, Visual Basic, C# and has a new IronPython plugin. This IDE is really good. It could even teach NetBeans a few tricks or two. For example, the visual form designer in SharpDevelop works with all the supported languages, not just C#. Compared this to Project Matisse who only works with Java, and according to this blog entry at least, getting it to work on other languages will be difficult.
What does all of this have to do with this blog entry? Well, when I was initially surveying the SharpDevelop web site, the requirements for the product caught my eye. Namely, SharpDevelop doesn't require the .Net SDK, only the .Net runtime.
OK, since SharpDevelop works out of the box with Boo on Windows, then we can conjecture that SharpDevelop ships a copy of Boo. Correct.
OK, since SharpDevelop works out of the box with C# and Visual Basic on Windows, then we can conjecture that SharpDevelop ships a copy of the C# and VB compilers from Mono. Incorrect.
Process Explorer put this to bed very quickly. SharpDevelop was using "csc.exe" for compiling. I never installed the .Net SDK on this machine, where did it come from? Well, it turns out that, just like Java, the compiler is available from .Net as a service. Unlike Java however, the compiler executables for C# and VB actually ship with the .Net runtime. If you look in "C:\Windows\Microsoft.Net", you'll find that you have a folder in there for each version of the .Net runtime you have installed. You'll also find compilers for C# and VB inside those folders. This means that on a fully patched Windows Vista system running .Net 3.5, a user has 6 compilers installed, a C# compiler version 1, 2 and 3 and VB compiler version 7, 8 and 9.
For an old UNIX war horse like me, it's tough to see all these compilers. A long time ago, it was common practice to make sure all compilers were disabled on UNIX servers. So, if you had an attacker using say FreeBSD version 2 attacking a server running IRIX or HPUX, the attacker could not upload a C source of a password cracker to the system, compile it and run it. It was uncommon that an attacker would go to the trouble of setting up a cross compiler just to attack a server.
The popularity of Linux and/or Perl "fixed" that problem. Both systems now just run Linux on Intel and at one point, most UNIX systems started shipping Perl out of the box around version 4 of the interpreter. Disabling the compiler isn't as important has it used to be. Using the noexec bit on the file system is obviously more important than ever.
We can make the same assertion about Windows, someone can easily compile from their system and attack the target system. Still, I feel the only reason why all these compilers aren't being used for more mischief is because they are much more easier alternatives. Now, is this just me? Am I just an old dinosaur in the age of .Net? Am I the only one that finds the presence of these compilers on ordinary non-developer boxes unsettling?
The NetBeans project claims NetBeans is the only IDE you need. Well, not quite, if you're looking into .Net for example, NetBeans is a dud. Not that you couldn't write plugins to support it but that seems unlikely. I was really interested in looking into .Net, well .Net Compact more precisely.
I have no commercial interests in .Net, I like my solutions, all jokes aside, to be portable. The compact edition of the framework however is something I find truly irresistible compared to the Java ME headache.
If you want to test drive .Net, you're in luck, you can just download a copy of Visual Studio Express from here and incur away. I've been having quite a bit of fun with Visual C# Express 2008. If you want to try .Net Compact however, well the express editions don't do compact. What to do? Both Visual Studio 2005 and 2008 offer a trial version available from here and here respectively and this is what I used initially.
Both these products have restricted licenses and I started looking for an IDE project that would work directly on the top of the .Net SDK. I wasn't expecting much really but I was simply shocked when I found out about SharpDevelop.
A very, very good clone of the Visual Studio IDE. It doesn't support C++ but it supports Boo, Visual Basic, C# and has a new IronPython plugin. This IDE is really good. It could even teach NetBeans a few tricks or two. For example, the visual form designer in SharpDevelop works with all the supported languages, not just C#. Compared this to Project Matisse who only works with Java, and according to this blog entry at least, getting it to work on other languages will be difficult.
What does all of this have to do with this blog entry? Well, when I was initially surveying the SharpDevelop web site, the requirements for the product caught my eye. Namely, SharpDevelop doesn't require the .Net SDK, only the .Net runtime.
OK, since SharpDevelop works out of the box with Boo on Windows, then we can conjecture that SharpDevelop ships a copy of Boo. Correct.
OK, since SharpDevelop works out of the box with C# and Visual Basic on Windows, then we can conjecture that SharpDevelop ships a copy of the C# and VB compilers from Mono. Incorrect.
Process Explorer put this to bed very quickly. SharpDevelop was using "csc.exe" for compiling. I never installed the .Net SDK on this machine, where did it come from? Well, it turns out that, just like Java, the compiler is available from .Net as a service. Unlike Java however, the compiler executables for C# and VB actually ship with the .Net runtime. If you look in "C:\Windows\Microsoft.Net", you'll find that you have a folder in there for each version of the .Net runtime you have installed. You'll also find compilers for C# and VB inside those folders. This means that on a fully patched Windows Vista system running .Net 3.5, a user has 6 compilers installed, a C# compiler version 1, 2 and 3 and VB compiler version 7, 8 and 9.
For an old UNIX war horse like me, it's tough to see all these compilers. A long time ago, it was common practice to make sure all compilers were disabled on UNIX servers. So, if you had an attacker using say FreeBSD version 2 attacking a server running IRIX or HPUX, the attacker could not upload a C source of a password cracker to the system, compile it and run it. It was uncommon that an attacker would go to the trouble of setting up a cross compiler just to attack a server.
The popularity of Linux and/or Perl "fixed" that problem. Both systems now just run Linux on Intel and at one point, most UNIX systems started shipping Perl out of the box around version 4 of the interpreter. Disabling the compiler isn't as important has it used to be. Using the noexec bit on the file system is obviously more important than ever.
We can make the same assertion about Windows, someone can easily compile from their system and attack the target system. Still, I feel the only reason why all these compilers aren't being used for more mischief is because they are much more easier alternatives. Now, is this just me? Am I just an old dinosaur in the age of .Net? Am I the only one that finds the presence of these compilers on ordinary non-developer boxes unsettling?
Monday, December 10, 2007
TopLink Error Messages
Whoever is responsible for the error messages found in Oracle's TopLink product is one sick individual.
TopLink Essential is a Java EE 5 persistence provider. It was contributed by Oracle to Glassfish and serves as the reference implementation for JPA. If you're a Glassfish user, do yourself a favor and setup another JPA provider.
Following these instructions, getting Apache OpenJPA to run inside Glassfish takes about 2 minutes. You can also use Hibernate if you so wish by following these instructions.
TopLink Essential is a Java EE 5 persistence provider. It was contributed by Oracle to Glassfish and serves as the reference implementation for JPA. If you're a Glassfish user, do yourself a favor and setup another JPA provider.
Following these instructions, getting Apache OpenJPA to run inside Glassfish takes about 2 minutes. You can also use Hibernate if you so wish by following these instructions.
Glassfish JDBC Realm Authentication
Judging by the numbers of posters on the Glassfish and NetBeans users list that are having problems with this, I thought I would explain how I got Glassfish to play well with JDBC for authentication.
1. The first gotcha is the database driver. Most developers get their copy of Glassfish bundled with NetBeans. Please note that even if the NetBeans IDE comes with drivers for Java DB, MySQL, PostgreSQL and the ODBC bridge, that is not the case for the bundled copy of Glassfish that ships with the IDE.
You will need to install the proper JDBC driver for your database in $GLASSFISH_HOME/domains/yourDomainNameHere/lib or in $GLASSFISH_HOME/lib if you want the drivers to be available from all domains. Additionally, you can also use the database drivers that come with NetBeans and just copy them over to Glassfish instead of hunting them down. The JDBC drivers installed with NetBeans 6 are found in "$NB_HOME/ide8/modules/ext".
2. If you do not have a database pool setup. You will need to define a database resource from Glassfish. You can do this from the admin console by going to "resources" -> "JDBC" -> "Connection Pool". Setup a pool using "javax.sql.DataSource". Complete the wizard and make sure you can "ping" the database.
3. Setup a new JDBC resource for the pool you selected in step 2. JDBC resources can be defined in "resources" -> "JDBC" -> "JDBC Resources". Select whatever JNDI name you want for the resource. Assign the JDBC pool you selected in step 2 above to the new resource.
4. You need to define a new realm for authentication. You can do this in "Configuration" -> "Security" -> "Realms". Assign a name for this realm, let's say "dbtest" for this example and select "com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm" as the class name.
We now need to setup all the properties here for the new realm:
Gotcha #3 is that the group name column absolutely needs to be a string. So, for example, if you use numeric foreign keys in your database, you will need to create a view that maps user names to user groups by string. You then use this database view for the group table/group name column fields.
Gotcha #4 is that digest algorithm field is actually required even if this doesn't look to be the case from the web page. Furthermore, the "none" algorithm found in Tomcat for example doesn't exist here, you need to digest your passwords, you can specify any Java supported algorithm here, i.e., MD5 or SHA-256.
Finally, to test it out, just use the NetBeans tutorial here but change the realm name in the web.xml file of the application to the one you specified in step #4 above.
1. The first gotcha is the database driver. Most developers get their copy of Glassfish bundled with NetBeans. Please note that even if the NetBeans IDE comes with drivers for Java DB, MySQL, PostgreSQL and the ODBC bridge, that is not the case for the bundled copy of Glassfish that ships with the IDE.
You will need to install the proper JDBC driver for your database in $GLASSFISH_HOME/domains/yourDomainNameHere/lib or in $GLASSFISH_HOME/lib if you want the drivers to be available from all domains. Additionally, you can also use the database drivers that come with NetBeans and just copy them over to Glassfish instead of hunting them down. The JDBC drivers installed with NetBeans 6 are found in "$NB_HOME/ide8/modules/ext".
2. If you do not have a database pool setup. You will need to define a database resource from Glassfish. You can do this from the admin console by going to "resources" -> "JDBC" -> "Connection Pool". Setup a pool using "javax.sql.DataSource". Complete the wizard and make sure you can "ping" the database.
3. Setup a new JDBC resource for the pool you selected in step 2. JDBC resources can be defined in "resources" -> "JDBC" -> "JDBC Resources". Select whatever JNDI name you want for the resource. Assign the JDBC pool you selected in step 2 above to the new resource.
4. You need to define a new realm for authentication. You can do this in "Configuration" -> "Security" -> "Realms". Assign a name for this realm, let's say "dbtest" for this example and select "com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm" as the class name.
We now need to setup all the properties here for the new realm:
- JNDI. Set the name you selected in step 3 above.
- User Table. The table name in your database that has users
- User Name Column. The column that represents the user name in the user table
- User Name Column. The column that represents the column in the user table
- Group Table. The group table.
- Group Name Column. The column that represents the column in the group table.
- Digest Algorithm. Glassfish will transform the clear text password using this algorithm before comparing it to the value in the database.
Gotcha #3 is that the group name column absolutely needs to be a string. So, for example, if you use numeric foreign keys in your database, you will need to create a view that maps user names to user groups by string. You then use this database view for the group table/group name column fields.
Gotcha #4 is that digest algorithm field is actually required even if this doesn't look to be the case from the web page. Furthermore, the "none" algorithm found in Tomcat for example doesn't exist here, you need to digest your passwords, you can specify any Java supported algorithm here, i.e., MD5 or SHA-256.
Finally, to test it out, just use the NetBeans tutorial here but change the realm name in the web.xml file of the application to the one you specified in step #4 above.
Krita
Just a quick blurb on Krita. It has been a while since I checked in on this project. I was involved in Krita a while back. At that point, the project, Krayon at the time, had been abandoned. I started work on Krita because I wanted to learn the Qt, KDE and the KOffice libraries. From this perspective, the project was a success for me since I learned all these libraries while working on Krita.
Real life got in the way of my involvement as I went to work in digital signage for a few years. That being said, before I left, I was able to kick start a new round of developers on Krita by answering questions on the actual code base.
I don't want to make it sound like I did much but trying out Krita today, I'm happy to see that it has continued and thrived. Congrats to all the Krita developers.
Real life got in the way of my involvement as I went to work in digital signage for a few years. That being said, before I left, I was able to kick start a new round of developers on Krita by answering questions on the actual code base.
I don't want to make it sound like I did much but trying out Krita today, I'm happy to see that it has continued and thrived. Congrats to all the Krita developers.
Friday, December 7, 2007
Dynamic Languages for a New World
Long ago, almost a lifetime now, I was a Perl developer. Perl 5 had just come out and I was a happy camper. Then, I started coding some very large programs, and I wasn't happy anymore. Moved away from Perl to C++ and pretty much stayed there for the last decade.
With my recent incursions in Java world and Java EE, I felt there was a lot of good technologies I could use in there but one part still bothered me, namely JSP and AJAX. JSP seems to be a capable technology but JSP and Ajax seems to be a marriage made in hell.
The prospect of writing HTML, CSS and JavaScript by hand, even with the help of toolkits like jMaki, is something that has always scared me so I kept on looking. I finally came across Google's web toolkit. I was happy again, full Java on the server and compile down Java to JavaScript on the client.
Now, I already knew about IronPython and JRuby, I decided to look around for a Perl for .Net and Java just to see what was available. Well, needless, to say I didn't find much except a discontinued Perl on .Net product from ActiveState and abandoned Perl on Java project. Signs of Perl's waning popularity I suppose.
I did come across a number of interpreters however, and I was quite surprised by the ample choice that was available, mainly:
Now, I tried all these languages and none of them felt right. All of them felt odd because of the importance of maintaining compatibility to their C counterpart. Is it a Ruby string or a Java string? A Python string or .Net one? To both questions, it depends on the context of what that module is importing.
I was a little bit discouraged. I felt Java everywhere except mobiles and C# on mobiles was just too monogamous. I like to spices things up but at the same time I didn't feel like moving away from GWT was a good move.
Well, it turns out that there are open source scripting languages being built natively on Java and .Net at Codehaus.org. Groovy for Java and Boo for .Net.
Both support support static typing instead of just duck typing. Now, I don't know much about Boo, I'm not looking to complement C# since I only use that on mobiles. I will say this however, Boo is supported by the very good SharpDevelop IDE, including visual form design and everything.
Groovy on the other hand has been a really good experience especially considering I use NetBeans and the Groovy plugin for that IDE is still incomplete. I get a first class citizen of the Java platform. At first, due to the fact that I wanted to use GWT, I was planning to limit my use of Groovy to testing code, i.e. write my JUnit stuff in Groovy. After all, I couldn't write Groovy code for GWT right? That things compiles Java down to JavaScript, it won't know what to do with my Groovy code right?
Enter Grails. Now, I can't for the life of me think of why anyone would use JRuby on Rails, i.e. using Rails from JRuby instead of Ruby, but I can see why a lot of Java developers would migrate from JSP/jMaki to Grails.
Grails follows the Rails philosophy of RAD web development but also features a GWT plugin. Unlike Rails, production deploys of Grails are done to a standard Java EE container using a WAR file.
Now, I can only imagine doing all my web services and back end stuff in Java, doing the web front end using Groovy and GWT, just very exciting times. Now, I'm still in the process of learning and using Grails and still fiddling to see how good GWT support is in Grails but exciting times nonetheless.
With my recent incursions in Java world and Java EE, I felt there was a lot of good technologies I could use in there but one part still bothered me, namely JSP and AJAX. JSP seems to be a capable technology but JSP and Ajax seems to be a marriage made in hell.
The prospect of writing HTML, CSS and JavaScript by hand, even with the help of toolkits like jMaki, is something that has always scared me so I kept on looking. I finally came across Google's web toolkit. I was happy again, full Java on the server and compile down Java to JavaScript on the client.
Now, I already knew about IronPython and JRuby, I decided to look around for a Perl for .Net and Java just to see what was available. Well, needless, to say I didn't find much except a discontinued Perl on .Net product from ActiveState and abandoned Perl on Java project. Signs of Perl's waning popularity I suppose.
I did come across a number of interpreters however, and I was quite surprised by the ample choice that was available, mainly:
- IronPython. C# implementation of the Python language. Licensed under the MS Public License. Impressive but I never liked Python much, I'm too much of a braces ('{', '}') man myself.
- IronRuby. C# implementation of the Ruby language. Also licensed under the MS Public License.
- JRuby. Java implementation of the Ruby language. Triple licensed, available under the LGPL.
- Jython. Java implementation of the Python language. Licensed under the Python Foundation License.
Now, I tried all these languages and none of them felt right. All of them felt odd because of the importance of maintaining compatibility to their C counterpart. Is it a Ruby string or a Java string? A Python string or .Net one? To both questions, it depends on the context of what that module is importing.
I was a little bit discouraged. I felt Java everywhere except mobiles and C# on mobiles was just too monogamous. I like to spices things up but at the same time I didn't feel like moving away from GWT was a good move.
Well, it turns out that there are open source scripting languages being built natively on Java and .Net at Codehaus.org. Groovy for Java and Boo for .Net.
Both support support static typing instead of just duck typing. Now, I don't know much about Boo, I'm not looking to complement C# since I only use that on mobiles. I will say this however, Boo is supported by the very good SharpDevelop IDE, including visual form design and everything.
Groovy on the other hand has been a really good experience especially considering I use NetBeans and the Groovy plugin for that IDE is still incomplete. I get a first class citizen of the Java platform. At first, due to the fact that I wanted to use GWT, I was planning to limit my use of Groovy to testing code, i.e. write my JUnit stuff in Groovy. After all, I couldn't write Groovy code for GWT right? That things compiles Java down to JavaScript, it won't know what to do with my Groovy code right?
Enter Grails. Now, I can't for the life of me think of why anyone would use JRuby on Rails, i.e. using Rails from JRuby instead of Ruby, but I can see why a lot of Java developers would migrate from JSP/jMaki to Grails.
Grails follows the Rails philosophy of RAD web development but also features a GWT plugin. Unlike Rails, production deploys of Grails are done to a standard Java EE container using a WAR file.
Now, I can only imagine doing all my web services and back end stuff in Java, doing the web front end using Groovy and GWT, just very exciting times. Now, I'm still in the process of learning and using Grails and still fiddling to see how good GWT support is in Grails but exciting times nonetheless.
Tuesday, December 4, 2007
Ninja Gaiden Dragon Sword
Went to the shopping mall today, I'm always excited when I go to mall, or at least this mall. This mall has a Toys "R" Us store with a Nintendo DS demo station. I'm always excited to see which demo I'll download today.
Well, today, I was right to be excited. I blogged before about the success of the DS would start to attract more established franchises, the result was only passable with Call of Duty 4, but this new Ninja Gaiden doesn't take any prisoners.
Wow! What kind I say, what an incredible game this is going to be. Incredible visuals, by far the best on the DS yet. Incredible audio. Incredible controls. Incredible action. Incredible everything. The only bad thing I have to say about the game is that I can't buy it, turns out it will only be released in February of 2008.
Well, today, I was right to be excited. I blogged before about the success of the DS would start to attract more established franchises, the result was only passable with Call of Duty 4, but this new Ninja Gaiden doesn't take any prisoners.
Wow! What kind I say, what an incredible game this is going to be. Incredible visuals, by far the best on the DS yet. Incredible audio. Incredible controls. Incredible action. Incredible everything. The only bad thing I have to say about the game is that I can't buy it, turns out it will only be released in February of 2008.
Java ME vs Android Take 2
I have just completed my first ever .Net program. This program, as it turns out, is built using the .Net Compact framework.
All in all, I believe .Net has been very beneficial for Java. .Net lit a fire under Sun's behind and this helped propel Java, both SE and EE, to new heights in order to stay competitive. Unfortunately, seeing how much better .Net Compact is, it appears this statement doesn't hold true for Java ME.
The first problem is the lingo. Java ME comes in basically 3 flavors: CLDC, CLDC/MIDP and CDC. CLDC is puny and doesn't offer much, it currently runs and ships on over a billion phone. CLDC/MIDP is a version of the CLDC with additional packages to make the experience a little less dreadful. Finally, we have the CDC, the CDC is a modern Java ME that supports a feature set that is considerably richer and on par with .Net Compact and Android.
Now, if it would end there, one could easily ask what the point of Android was? Unfortunately, it doesn't end there, that would be too simple. Each of the above profile has different versions and all of them are still being actively developed. If that's not enough fragmentation for you, Sun doesn't actually provide Java for mobiles. Instead it licenses the code to carriers and these carriers port the profile to their operating system. Carriers can also ship other ME implementations, e.g., the one from IBM. Just to spice things up, most, if not all of these carriers add their own packages on top to compensate for missing features. It also means that without a standard distribution, unlike .Net Compact, updating the version of Java on a mobile is practically impossible because carriers don't usually bother publishing updates. If a phone is shipped with an old version of the MIDP, that's it, deal with it.
That being said, I missed the real killer benefit of Android the first time I blogged about it. All these profiles from Sun still use the Java 1.4 language. So you can forget about using generics or anything of the sort. I could not find anything about updating the Java dialect to 5 or 6 for Java ME. Android uses the Java 5 dialect. The other good thing about Android is that there is, at least for now, only one SDK, not one per mobile.
All is not lost for Java ME however. Sun is still busy toiling away at its own Java mobile environment called JavaFX. Sun is still hoping to converge Java ME to the full Java SE in the future, good deal.
The best hope for Java ME in the short term is that Sun has now GPL'ed Java ME and is maintaining ports of the distribution for Linux and Windows CE. The project doesn't seem that active but it will at least give a standard build of ME that developers can distribute to their customers directly. Unfortunately, this project also has no information about updating the Java dialect to 5 or 6.
I am now a big supported of the Java platform, i.e. Groovy, JRuby, Java SE 6 and Java EE 5. Until Java ME cleans up its house or until Android finds a market, I'll stick to .Net Compact thank you very much. I would not consider .Net for any type of project outside of mobiles due to, all jokes aside, the lack of portability, but I can't think of anything better for mobiles right now.
All in all, I believe .Net has been very beneficial for Java. .Net lit a fire under Sun's behind and this helped propel Java, both SE and EE, to new heights in order to stay competitive. Unfortunately, seeing how much better .Net Compact is, it appears this statement doesn't hold true for Java ME.
The first problem is the lingo. Java ME comes in basically 3 flavors: CLDC, CLDC/MIDP and CDC. CLDC is puny and doesn't offer much, it currently runs and ships on over a billion phone. CLDC/MIDP is a version of the CLDC with additional packages to make the experience a little less dreadful. Finally, we have the CDC, the CDC is a modern Java ME that supports a feature set that is considerably richer and on par with .Net Compact and Android.
Now, if it would end there, one could easily ask what the point of Android was? Unfortunately, it doesn't end there, that would be too simple. Each of the above profile has different versions and all of them are still being actively developed. If that's not enough fragmentation for you, Sun doesn't actually provide Java for mobiles. Instead it licenses the code to carriers and these carriers port the profile to their operating system. Carriers can also ship other ME implementations, e.g., the one from IBM. Just to spice things up, most, if not all of these carriers add their own packages on top to compensate for missing features. It also means that without a standard distribution, unlike .Net Compact, updating the version of Java on a mobile is practically impossible because carriers don't usually bother publishing updates. If a phone is shipped with an old version of the MIDP, that's it, deal with it.
That being said, I missed the real killer benefit of Android the first time I blogged about it. All these profiles from Sun still use the Java 1.4 language. So you can forget about using generics or anything of the sort. I could not find anything about updating the Java dialect to 5 or 6 for Java ME. Android uses the Java 5 dialect. The other good thing about Android is that there is, at least for now, only one SDK, not one per mobile.
All is not lost for Java ME however. Sun is still busy toiling away at its own Java mobile environment called JavaFX. Sun is still hoping to converge Java ME to the full Java SE in the future, good deal.
The best hope for Java ME in the short term is that Sun has now GPL'ed Java ME and is maintaining ports of the distribution for Linux and Windows CE. The project doesn't seem that active but it will at least give a standard build of ME that developers can distribute to their customers directly. Unfortunately, this project also has no information about updating the Java dialect to 5 or 6.
I am now a big supported of the Java platform, i.e. Groovy, JRuby, Java SE 6 and Java EE 5. Until Java ME cleans up its house or until Android finds a market, I'll stick to .Net Compact thank you very much. I would not consider .Net for any type of project outside of mobiles due to, all jokes aside, the lack of portability, but I can't think of anything better for mobiles right now.
Monday, December 3, 2007
Latest Apple anti Vista campaign is retarded
The latest advertisement from Apple promoting the benefits of a Mac versus PC states: "Ask not what Vista can do for you but what can you buy for Vista?". Saying that even a simple printer will not work and that you will need to buy a new one.
Well, not only will your printer work with Vista. You have to ask yourself what kind of backwards compatibility does OSX offer versus Vista.
When OSX showed up, its compatibility was simply disastrous. You had to run MacOS classic inside an emulator, a very slow and painful process. Not only did all the old software not work, but Apple excluded a huge number of models from the the OSX compatibility list since all but the absolute newest PowerPC models had enough horsepower to run the new OS.
But that was just the migration from MacOS classic to X right? Nope, on every point release (or is it non-free service pack?), Apple keeps on dropping older models with extreme prejudice.
Finally, what about all those people who bought a PowerPC based Mac instead of an Intel based on? Surely Apple will keep on releasing software for them right? Yeah, don't hold your breath.
The truth is, Apple may make fun of Microsoft for its compatibility woes with Vista but underneath it all, Apple customers are terribly jealous of the compatibility offered by Microsoft to its customers.
Well, not only will your printer work with Vista. You have to ask yourself what kind of backwards compatibility does OSX offer versus Vista.
When OSX showed up, its compatibility was simply disastrous. You had to run MacOS classic inside an emulator, a very slow and painful process. Not only did all the old software not work, but Apple excluded a huge number of models from the the OSX compatibility list since all but the absolute newest PowerPC models had enough horsepower to run the new OS.
But that was just the migration from MacOS classic to X right? Nope, on every point release (or is it non-free service pack?), Apple keeps on dropping older models with extreme prejudice.
Finally, what about all those people who bought a PowerPC based Mac instead of an Intel based on? Surely Apple will keep on releasing software for them right? Yeah, don't hold your breath.
The truth is, Apple may make fun of Microsoft for its compatibility woes with Vista but underneath it all, Apple customers are terribly jealous of the compatibility offered by Microsoft to its customers.
Subscribe to:
Posts (Atom)