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.
Saturday, November 17, 2007
Red Rings of Light Again
I got my xbox console, or should I say another used console, two days after sending it in via the good folks over at Purolator. New serial number and new manufacturing date. I also got a letter thanking me for my patience, a one month xbox live gold card and a letter explaining that is a "certified Microsoft refurbished console".
Unfortunately, I also got a 3 red rings of light within the very first half hour the damn thing was connected. I'm starting to wonder if Microsoft really understands what the problem with these consoles really are, or if the defect can't really be fixed at all without major hardware replacement.
In any case, I'll be sending back the replacement again, maybe I'll get another xbox gold card.
Unfortunately, I also got a 3 red rings of light within the very first half hour the damn thing was connected. I'm starting to wonder if Microsoft really understands what the problem with these consoles really are, or if the defect can't really be fixed at all without major hardware replacement.
In any case, I'll be sending back the replacement again, maybe I'll get another xbox gold card.
Google Android
Google recently released a preliminary SDK for their mobile platform called Android for developers. Off the top of my head, looking at their technical documentation, I can't think of anything that is in Android that also isn't in Java ME (or .Net Compact for that matter). That being said, Java ME is an SDK only while Android is a full platform and it comes bundled with standard applications and user interface. Sun has already announced that they too are working on their own platform for mobiles called JavaFX.
Unless I'm mistaken here, the SDK for JavaFX will be Java ME and it too will come with its standard user interface and set of applications. I don't know what the motivation for developing JavaFX was, but I'm guessing Sun is trying to create a synergy similar to the one Microsoft enjoys between Windows Mobile and .Net Micro.
Now that Android has entered the picture, it's sort of hard to not question its existence. Let's face it, Java ME is already on millions of handset worldwide which makes Android seem irrelevant. On the other hand, Google has made Java on handsets look good and exciting again, I can't remember when I felt like that about Java ME.
Now that I'm writting this, Android does codify something I feel is really missing in Java and not just the micro edition, a standard XML syntax for user interfaces. Microsoft is really doing great work with its XAML technology. Not only does this technology have the potential to bridge the gap between web and desktop applications but also the gap between designers and developers. Android doesn't fill that gap obviously since even Google's other toolkits don't support this XML syntax, this is exciting nonetheless. I like GUI editors that generate XML, not when they generate code directly in a class somewhere. This has been, and remains Sun's stategy for Java. Fortunately, even if it's not included directly in Java, I can still use XAML in Java using eFace.
One thing that I find solely missing in Android however is crash reporting. Google is obviously aware this is important, see their breakpad project. I'm not committed to quality in my software, it goes beyond that, I'm committed to perfection. If Google wants to provide a platform, well I think crash reporting is one of those services that developers expect to be part of any platform nowadays. That being said, this also happens to be missing from standard Java but again, I'm not talking about providing software to capture and report crashes only, this also exists for Java. No, I'm talking that platform holders should provide servers where developers can register their binaries like Microsoft allows you to do. Open source developers have tons of resources available to them in the form of Sourceforce, GNU Savannah and Google Code to name a few, but it appears that crash servers aren't readily available from any of these sites.
Finally, I would be remiss if I were to not mention the #1 reason why I like Android. The inclusion of the SQLite database. Meaning that, if you have an Android phone, you have SQLite in there. Words cannot describe how passinate I am about this database. I have used this database extensively in the past and will certainly continue to do so probably till the day I die. I have tried using Derby and SQL Server Compact but if you're looking for embedded, small and complete they just don't come close to SQLite.
Unless I'm mistaken here, the SDK for JavaFX will be Java ME and it too will come with its standard user interface and set of applications. I don't know what the motivation for developing JavaFX was, but I'm guessing Sun is trying to create a synergy similar to the one Microsoft enjoys between Windows Mobile and .Net Micro.
Now that Android has entered the picture, it's sort of hard to not question its existence. Let's face it, Java ME is already on millions of handset worldwide which makes Android seem irrelevant. On the other hand, Google has made Java on handsets look good and exciting again, I can't remember when I felt like that about Java ME.
Now that I'm writting this, Android does codify something I feel is really missing in Java and not just the micro edition, a standard XML syntax for user interfaces. Microsoft is really doing great work with its XAML technology. Not only does this technology have the potential to bridge the gap between web and desktop applications but also the gap between designers and developers. Android doesn't fill that gap obviously since even Google's other toolkits don't support this XML syntax, this is exciting nonetheless. I like GUI editors that generate XML, not when they generate code directly in a class somewhere. This has been, and remains Sun's stategy for Java. Fortunately, even if it's not included directly in Java, I can still use XAML in Java using eFace.
One thing that I find solely missing in Android however is crash reporting. Google is obviously aware this is important, see their breakpad project. I'm not committed to quality in my software, it goes beyond that, I'm committed to perfection. If Google wants to provide a platform, well I think crash reporting is one of those services that developers expect to be part of any platform nowadays. That being said, this also happens to be missing from standard Java but again, I'm not talking about providing software to capture and report crashes only, this also exists for Java. No, I'm talking that platform holders should provide servers where developers can register their binaries like Microsoft allows you to do. Open source developers have tons of resources available to them in the form of Sourceforce, GNU Savannah and Google Code to name a few, but it appears that crash servers aren't readily available from any of these sites.
Finally, I would be remiss if I were to not mention the #1 reason why I like Android. The inclusion of the SQLite database. Meaning that, if you have an Android phone, you have SQLite in there. Words cannot describe how passinate I am about this database. I have used this database extensively in the past and will certainly continue to do so probably till the day I die. I have tried using Derby and SQL Server Compact but if you're looking for embedded, small and complete they just don't come close to SQLite.
Friday, November 16, 2007
Capcom Thinks Wii Owners are Dumb
I had never played Resident Evil before 4. The genre just didn't interest me. The only reason I bought 4 was because of the fantastic, near perfect reviews.
That being said, my experience with Resident Evil 4 on the Gamecube wasn't very positive. I couldn't aim correctly so I never even made it to the first type writer.
Well, a few months ago, I picked up the game again but for the Wii this time. Now, I could aim and now I understood what those rave reviews were talking about. What a fantastic game!
Now, eager to play some more Resident Evil, I picked up the new installment of the franchise for the Wii... Resident Evil: The Umbrella Chronicles. Well, if you're looking for the next great RE game, don't look here.
To put it mildly, this game seems to have been dumbed down for the Wii users. It has more of an arcade style to it. You can play the game pretty much without the nunchuck.
I love my Wii. I think it's the only true next generation console. Unfortunately, most 3rd party publishers are content with dumping bad games on it and then complaining that Nintendo has too much of a market share on their consoles.
Well, I have news for these publishers, Nintendo makes really good games hence why people are willing to give money to buy them. In any case, if you own a Wii, avoid The Umbrella Chronicles, just play the 4th game again.
That being said, my experience with Resident Evil 4 on the Gamecube wasn't very positive. I couldn't aim correctly so I never even made it to the first type writer.
Well, a few months ago, I picked up the game again but for the Wii this time. Now, I could aim and now I understood what those rave reviews were talking about. What a fantastic game!
Now, eager to play some more Resident Evil, I picked up the new installment of the franchise for the Wii... Resident Evil: The Umbrella Chronicles. Well, if you're looking for the next great RE game, don't look here.
To put it mildly, this game seems to have been dumbed down for the Wii users. It has more of an arcade style to it. You can play the game pretty much without the nunchuck.
I love my Wii. I think it's the only true next generation console. Unfortunately, most 3rd party publishers are content with dumping bad games on it and then complaining that Nintendo has too much of a market share on their consoles.
Well, I have news for these publishers, Nintendo makes really good games hence why people are willing to give money to buy them. In any case, if you own a Wii, avoid The Umbrella Chronicles, just play the 4th game again.
Wednesday, November 7, 2007
Red Rings of Light
Once again, my xbox console has succumbed to the dreaded 3 red rings of light problem. This is now the 3rd time this year. Obviously, I am a little peeved even with this now being covered by the xbox warranty.
That being said, this is not another rant on this problem. This has been covered to death by so many people, I don't see how one more would help (or hurt).
This post is more about praising the xbox support team. When I called yesterday, once again, I talked to somebody that was incredibly nice, incredibly helpful in getting this taken care of. Microsoft also threw in a one month xbox gold card for my troubles. I can only imagine how many people this person fields in just a day just for this specific problem. Even assuming all customers are nice and polite, the repetitiveness of this task must be daunting at best.
Yes, it's annoying, but I still think Microsoft is a company that has learned from its mistakes, continues to learn everyday and keeps on improving. As much as I hated Microsoft in the nineties, preaching the Linux gospel and what not, I feel that no one, not even Microsoft is beyond redemption.
That being said, this is not another rant on this problem. This has been covered to death by so many people, I don't see how one more would help (or hurt).
This post is more about praising the xbox support team. When I called yesterday, once again, I talked to somebody that was incredibly nice, incredibly helpful in getting this taken care of. Microsoft also threw in a one month xbox gold card for my troubles. I can only imagine how many people this person fields in just a day just for this specific problem. Even assuming all customers are nice and polite, the repetitiveness of this task must be daunting at best.
Yes, it's annoying, but I still think Microsoft is a company that has learned from its mistakes, continues to learn everyday and keeps on improving. As much as I hated Microsoft in the nineties, preaching the Linux gospel and what not, I feel that no one, not even Microsoft is beyond redemption.
More DS good news
Following up on my post from yesterday, saw this article from next-gen.biz on a Ubisoft investor meeting. In the article, the CFO states that:
"CFO Alain Martinez added that DS games, with their relatively low development costs, achieve profitability at around 100,000 units sold, while a next-gen game for PS3 or Xbox 360 needs to sell around 1.3 million."
This should encourage many 3rd party publishers to bring their top franchises to the DS. However, I'm still worried about what the overall quality of these games will be and if any of the control schemes attempted will be physically hurtful like Metroid Prime Hunters.
My advice, make sure you do what Advance Wars: Dual Strike does. This superb title offers touch screen based controls but also offers a "classic" control scheme that is identical to the Game Boy games of the franchise. This is fortunate since the touch screen control scheme of that game is unusable. Offering a classic control scheme salvaged this gem instead of dooming it.
That being said, offering two control scheme is not always that easy to implement. Zelda: Phantom Hourglass is nothing short of fantastic. One of the reason is the new control scheme based completely on "touch". If given a choice, I suspect many users would have opted for a more classic control scheme and would have missed out on the shear genius that are the touch controls in this game.
"CFO Alain Martinez added that DS games, with their relatively low development costs, achieve profitability at around 100,000 units sold, while a next-gen game for PS3 or Xbox 360 needs to sell around 1.3 million."
This should encourage many 3rd party publishers to bring their top franchises to the DS. However, I'm still worried about what the overall quality of these games will be and if any of the control schemes attempted will be physically hurtful like Metroid Prime Hunters.
My advice, make sure you do what Advance Wars: Dual Strike does. This superb title offers touch screen based controls but also offers a "classic" control scheme that is identical to the Game Boy games of the franchise. This is fortunate since the touch screen control scheme of that game is unusable. Offering a classic control scheme salvaged this gem instead of dooming it.
That being said, offering two control scheme is not always that easy to implement. Zelda: Phantom Hourglass is nothing short of fantastic. One of the reason is the new control scheme based completely on "touch". If given a choice, I suspect many users would have opted for a more classic control scheme and would have missed out on the shear genius that are the touch controls in this game.
Tuesday, November 6, 2007
Call of Duty 4
OK, I think it's a given by now that developing for the Nintendo DS is hard. That being said, game publishers can no longer ignore the massive success of the handheld now having shipped more than 50 million units.
The good news is that titles like Call of Duty 4: Modern Warfare are coming to the console. The bad news is that tiles like Call of Duty 4: Modern Warfare are coming to the console.
On the surface, the availability of a title like CoD4 on the DS is really good news. Having played Call of Duty 2 and 3, I can attest that they are really great, if not very long, games. The problem is fitting that franchise on the DS. The title only comes with one control scheme, this control scheme was pretty much the one used in Metroid Prime Hunters and it didn't work in that title and it doesn't work here either. In fact, the harshest criticism I had about Metroid DS was how hard it was on the hands to play that title, I gave up on it only after a few plays.
The problem with CoD 4 on the DS is that it's clear that the traditional control scheme of the franchise, found on the XBox 360 version of the game for example, is a much better fit. Unfortunately, Activision decided that one control scheme was enough and didn't include an option for it.
I'm all for innovating but more often than not it seems that the price for innovation on the DS is bad controls. Call of Duty 4 on the DS is nonetheless a game with high production values, even delivering speech for all the text in the game, however, it's also clear that the control scheme just doesn't work. Finally, the most frustrating thing about the experience is the DS has all the buttons and controls necessary to actually enable the traditional control scheme.
The good news is that titles like Call of Duty 4: Modern Warfare are coming to the console. The bad news is that tiles like Call of Duty 4: Modern Warfare are coming to the console.
On the surface, the availability of a title like CoD4 on the DS is really good news. Having played Call of Duty 2 and 3, I can attest that they are really great, if not very long, games. The problem is fitting that franchise on the DS. The title only comes with one control scheme, this control scheme was pretty much the one used in Metroid Prime Hunters and it didn't work in that title and it doesn't work here either. In fact, the harshest criticism I had about Metroid DS was how hard it was on the hands to play that title, I gave up on it only after a few plays.
The problem with CoD 4 on the DS is that it's clear that the traditional control scheme of the franchise, found on the XBox 360 version of the game for example, is a much better fit. Unfortunately, Activision decided that one control scheme was enough and didn't include an option for it.
I'm all for innovating but more often than not it seems that the price for innovation on the DS is bad controls. Call of Duty 4 on the DS is nonetheless a game with high production values, even delivering speech for all the text in the game, however, it's also clear that the control scheme just doesn't work. Finally, the most frustrating thing about the experience is the DS has all the buttons and controls necessary to actually enable the traditional control scheme.
Tuesday, October 30, 2007
Tomcat vs. Geronimo
I talked in an earlier post about Java "word salad" and I still stand by it. It's only after playing with the various products that I finally understand the differences between Tomcat, Geronimo and Glassfish for example.
In plain English, Tomcat is a web and application server that implements a java servlet container.
Geronimo and Glassfish are the implementation of the Java EE platform by Apache and Sun respectively. Like Tomcat, Java EE servers need to provide the servlet feature. This can be accomplished by including Tomcat proper and this is indeed what Geronimo does for example. However, a Java EE server also needs to implement tons of other stuff too: transactions, EJB, JDBC, message queues, persistence, clustering, management beans and an internal SQL database to name a few.
Each set of features provided implements interfaces specified in the various java community specification documents. This means you can swap various features for others, e.g., Glassfish implements the JMS API using Sun's Java System Message Queue product, a.k.a OpenMQ, but Geronimo uses ActiveMQ. You could for example put ActiveMQ in GlassFish to gain additional features found in that product. That being said, you could also install ActiveMQ or OpenMQ standalone on additional servers to either complement your Java EE application servers or just for use as a standalone message queue.
Not all components found in these open source Java EE platforms are distinct however. The internal database found in both products is Apache Derby for example.
In plain English, Tomcat is a web and application server that implements a java servlet container.
Geronimo and Glassfish are the implementation of the Java EE platform by Apache and Sun respectively. Like Tomcat, Java EE servers need to provide the servlet feature. This can be accomplished by including Tomcat proper and this is indeed what Geronimo does for example. However, a Java EE server also needs to implement tons of other stuff too: transactions, EJB, JDBC, message queues, persistence, clustering, management beans and an internal SQL database to name a few.
Each set of features provided implements interfaces specified in the various java community specification documents. This means you can swap various features for others, e.g., Glassfish implements the JMS API using Sun's Java System Message Queue product, a.k.a OpenMQ, but Geronimo uses ActiveMQ. You could for example put ActiveMQ in GlassFish to gain additional features found in that product. That being said, you could also install ActiveMQ or OpenMQ standalone on additional servers to either complement your Java EE application servers or just for use as a standalone message queue.
Not all components found in these open source Java EE platforms are distinct however. The internal database found in both products is Apache Derby for example.
The Java Ecosystem
I promised myself to look at the .Net 3.5 Beta by now but I've been overwhelmed by the number of technologies found in the Java ecosystem that I haven't yet found the time. It doesn't help that I only work 2 to 3 hours a day either.
But seriously, I feel like a newborn experiencing all these interesting technologies:
1. Google Web Toolkit. Write a Java application and compile it down to JavaScript to get an Ajax site. Really interesting and really fund to code. I can definitely think of a large application or two that I wrote on the desktop that would have been on the web had this been around circa 2002.
2. Project Phobos. So, if you're planning on writing the web front end in java, why not write the server in JavaScript? OK, haven't played with this one yet but interesting nonetheless and I certainly will find something to do with this if it works well.
The number of tool kits that Sun has made available under its open source initiative is staggering. Need federated single sign on? No problem, just use OpenSSO. It also supports OpenDS as an LDAP back end. If you consider that OpenSSO is extensible and can be made to support InfoCard. Even more attractive it becomes when you consider you can use it from any language thanks to its support of web services via SOAP and Rest.
But seriously, I feel like a newborn experiencing all these interesting technologies:
1. Google Web Toolkit. Write a Java application and compile it down to JavaScript to get an Ajax site. Really interesting and really fund to code. I can definitely think of a large application or two that I wrote on the desktop that would have been on the web had this been around circa 2002.
2. Project Phobos. So, if you're planning on writing the web front end in java, why not write the server in JavaScript? OK, haven't played with this one yet but interesting nonetheless and I certainly will find something to do with this if it works well.
The number of tool kits that Sun has made available under its open source initiative is staggering. Need federated single sign on? No problem, just use OpenSSO. It also supports OpenDS as an LDAP back end. If you consider that OpenSSO is extensible and can be made to support InfoCard. Even more attractive it becomes when you consider you can use it from any language thanks to its support of web services via SOAP and Rest.
Wednesday, October 24, 2007
Moving Blog
Apparently some of my Unix friends still hate Microsoft so this blog is moving over to blogspot. What I find funny is how these guys still hate Microsoft for abusing their market position... i.e., Microsoft the evil corporation.
Personally, I find the Microsoft of today to be significantly different than the one that launched Windows 95. The focus today is really on creating incredibly high quality software and innovation, e.g., UAC and the Office 2007 ribbons to name a few.
The other thing that I find funny is that http://codepimps.blogspot.com is actually taken. The codepimps.org domain will now point to http://codepimpsdotorg.blogspot.com/.
Personally, I find the Microsoft of today to be significantly different than the one that launched Windows 95. The focus today is really on creating incredibly high quality software and innovation, e.g., UAC and the Office 2007 ribbons to name a few.
The other thing that I find funny is that http://codepimps.blogspot.com is actually taken. The codepimps.org domain will now point to http://codepimpsdotorg.blogspot.com/.
Fresh Pot of Java or The Java Platform, Ten Years Later
I haven't looked at Java in a long while, almost ten years. I remember walking away very unimpressed with the language and runtime back then. The promise of "write once, run everywhere" was laughable at most. The only thing I really liked was applets but ultimately dismissed them due to the need of distributing the JRE to clients. Not exactly sure when, but I also played around with JSP when it came out. Ultimately, I felt Java was slow, big, not portable, that the language was just too clean and lacked some very important features and that crafting libraries to compensate for those missing features was just too painful.
I also felt the supporters of the technology downplayed real issues (and still do?) when building applications in order to market the language. Correct use of threading and memory management to name a few are still no walk in the park no matter what the environment supports or not. I also worried about deployment issues related to applications and the runtime itself.
In any case, I started looking at Java again recently. Not sure why, maybe it's the idea of the virtual machine that I always liked, just plain boredom or maybe just a new outlook on life in general.
With the latest version of Java, i.e., 6, I can honestly say it's nice, real nice. I still don't know how portable it really is but I don't particularly care anymore. Let's face it, with most applications delivered over the Web now, the application/JVM would run on a server/OS that would be fully validated anyway.
Things I really like:
1. The huge class libraries
2. Support for generics. I can't tell you how I hated having containers full of "Object" classes and having to rely on runtime exceptions to determine correctness. This is the job of the compiler to tell me and it's about time it did so.
3. Tools. Eclipse and NetBeans to name a few. The NetBeans 6 Beta is really nice.
4. Application servers. Only tried Glassfish and Tomcat, neither really have everything I want but interestingly enough, if combined they would most likely be ideal.
5. Management of application servers. Haven't tried to do anything with them really yet scalability wise but I have written quite a few highly scalable servers in my day and configuration and management was always lacking. Why? Time simply, budgets had to be spent on other areas. The administrative application included with Glassfish is good and does its job really well.
6. Web deployments
7. Java DB, A.K.A. Apache Derby. If you're dealing with simple brochure website or something like that, it might be worthwhile to just use this DB and not bother with anything else if your developing in Java, it's included in the SDK after all.
8. Java.nio was something I solely missed previously. Let's face it, sometimes simple blocking I/O just won't do even with thread support. In my line of work, standard blocking I/O is too often the wrong answer.
9. Support for scripting. JRuby, JPython and Sun also has its own scripting language whose name escapes me right now.
Also, I found that speed and application interactivity is fine on modern hardware and that assertions are finally supported.
In all, I invested two full days on Java and its related technologies and came away impressed. Using Eclipse, I wrote a sample console application. Using NetBeans, I wrote a sample web application. The application was unimpressive but the web application I wrote was much more interesting.
This web application was a less (much less) ambitious version of the DinnerNow .Net sample application. Ajax support, Google maps, mobile backend, web marketplace driven by Apache Derby in network configuration of all things and a simple workflow using BPEL. I didn't bother with all features, i.e. command line client, management console and secure authentication didn't make the cut. However, I did enough to get a feel for Java and found it pleasant to work with which is a lot more than I can say about it ten years ago.
That being said, not everything is positive. I've been around this industry for a while. It's easy for me to pick up new toolkits and languages. I really feel the Java documentation is hard for newcomers to get into easily. The name of the different Java technologies and tools is one such barrier. A much more complete map of Java related technologies is needed and more importantly, it needs to offer guidance on how these technologies relate to one another.
Don't believe me? Have a look at the Apache Software Foundation site. Obviously, a priceless resource for any aspiring Java developer. Look at the software directory on the left side of the main page... You will see a list of very colorful names like Cayenne, Jakarta, Lucenne and Maven among others with no clear indication of what these really do for you or where to start. To learn about each project, you have to dwell into each of their individual websites and somehow track all the projects yourself, great. Needless to say, Apache is not Sun but the company does suffer from the same techno word salad in its own documentation of the Java platform.
It's still too early to tell if I will use using Java in a future project but I'm seriously considering it. I plan on delving into .Net shortly in the future since I haven't bothered looking since 1.1 beta something. This evaluation will obviously impact this one on Java.
Wii Game Boy Channel?
I've been experiencing with the Wii channel technology lately. I picked up a few games for the different platforms available and tried them. The ports are really good but I still do not quite understand why the Wii insists on stretching the output if you have a wide-screen television set. Needless to say, these retro titles do not support wide-screen.
The other big question that comes to mind is why is there no Game Boy channel? It seems that Nintendo is no longer actively promoting this platform and with good reason considering the massive success of the DS. It is true that the DS can play Game Boy Advance games and Nintendo may still be protecting revenue there. That being said, the DS is incapable of playing older titles for the original Game Boy(GB) and Game Boy Color(GBC) platforms since it doesn't contain the vintage hardware to run those games.
The GB and GBC platforms have a fantastic software library that I never got to play. Do I really want to pickup Zelda: Oracle of Seasons and a GBC from Ebay? No, no I don't, but I can really see myself purchasing that title virtually on the Wii however.
Now, what about linking? That annoying game technology that Nintendo tried to push on the market as an alternative to online play. The simple answer... just don't support it. The DS doesn't after all. Nintendo was able to use this linking technology to provide some unique gaming experiences but it ultimately failed since most gamers seemed isolated or missing all the required hardware and cables. So again, just don't bother supporting it.
Finally, I would argue that Nintendo is probably losing some real sales here. There seems to be an abundance of GB emulators and illegal software ROMs available on the Internet. A legalized option, at least, would most certainly deter some gamers from getting the setup on their computers.
Subscribe to:
Posts (Atom)