Ease of Data Access

Summer is here, and when you live as far north as I live, that means you get out and enjoy the great outdoors every chance you get. I devote much more time to learning new technology and programming during the winter months. That being said, I will be devoting some hours to learning Sun's web platform this summer. Phobos and Jmaki in particular. So far I have found Phobos and Jmaki very easy to work with. I find it extremely easy to use Java objects as well. I am looking forward to the final release of Netbeans 6.

There are a few issues that I think would help Phobos along. The first being that a simple data pipe is needed. Every user has data. Every simple website has data. In order for someone to find the whole platform easy to work with, there needs to be a simple data pipe. JPA is the new Java way of working with data. I agree that it is powerful and fast. However, there needs to be a simple pipe as well. Take the following scenario, someone has a database and they want to try Phobos out. If they had a simple data object that they could set a few properties, issue an sql statement, and get a data object back which they could then access to generate a presentation page, they would be successful getting there data and on to using Phobos to design an application. Now lets just say that they have trouble getting at their data, or something does not work right. Now they really have nothing to work with. They are now more likely to become frustrated and give up working with this new technology.

Now consider another scenario. The beginner user programs a simple data access page and now deploys it as a web app. However, because now it is running in the application environment, a data pool has to be configured to access your data. Now the beginner user is frustrated and stops using this new technology because they cannot figure out how to make the web app work on the application server. I know it is impossible to make a default pipe on every application server, but it would be help to have something be standard on at least one like Glassfish. There could always be a simple pipe out of the box, and then if you wanted more performance, you could complete the steps necessary to achieve that performance by using pools and/or JPA.

These all seem like minor issues to the average Java programmer, but for the beginner doing it for the first time, these can be huge issues. The JSF IDE builder in Netbeans is really RAD, but JSF programming is quite complex and far below scripting. The Phobos engine excels in simplicity, but a few added pieces of tooling would really make it fly. Data access just needs to work!

The devoted Visual Foxpro community on the Microsoft side was developed because of easy data access.

Phobos currently has a simple database library and also a JPA generator. These are pretty good, but I it still needs to be easier. The database library needs to be documented with some simple examples. The JPA generator is nice, but requires several steps. The Phobos team is doing a good job. I am sure better tooling is coming. Stay tuned!

Java One, Phobos, JavaFX

I have been watching with interest what has been happening at Java One this year via the web. To be honest, I have never really paid attention to it at all except to see a random news story here or there. Since I have begun using Phobos and looking for ways to move business applications to the Java platform, I have been following Java much more closely. My main area of interest was to see what the Phobos team was presenting and how Phobos fits into the big Java picture. The next thing which jumped out and I found exciting was the JavaFX announcement. I saw F3/JavaFX several months ago, but really have not paid attention to it, but was pleasantly surprised by how far it has come and how it is being developed. It is exciting to see Sun putting effort into making simple, easy to use tools. In my book, this is finally an effort in the right direction to draw new, non-Java programmers into the Java platform. This is what needs to happen in order for Java to dominate and neutralize the operating system monopoly.

It was sad to see the reaction Java developers and Java bloggers being critical of Sun's efforts and JavaFX. With Phobos and JavaFX built on top of Java, Java is not going to go away. Java programmers will still be able to code in Java. What is the problem with building a simple declarative language with easy binding? What is wrong with designing an interpreted language running on the Java stack? What is wrong with bringing the level of complexity to write on top of the Java stack to a very simple proposition? It seems many Java programmers are their own enemy. It is time for Java developers to have some enthusiasm about the Java platform striving to encompass and invite, in whatever ways necessary, those developers who are using other languages. That does not mean forcing them to learn Java. That means creating a migration path that is feasible and comfortable, and giving them the tools to do so. Sun is finally doing it, and it is about time that Java developers and Java bloggers get in the game and support Sun's effort. It is in every Java developers best interest to do so.

Phobos And Data Access

The last few weeks I have been working on some Phobos applications internal to our company and trying to work out the best way to access databases for both data display uses and form usage requiring persistence. The Phobos team has produced a generator which produces all the tiers of code which you can then modify once you have run the generator. The only stipulation is that you have run the JPA wizard on your database and have produced the needed JPA jar by using Netbeans. The JPA Jar is easily produced with the Netbeans wizard if you have a new database and there doesn't happen to be any wrinkles. I accomplished the whole task for a sample app in about thirty minutes. Considering I started with nothing and when I was done, I had a database with tables, a persistence unit, application server code, and a rough web interface, I would say that the process is pretty impressive! The Netbeans and Phobos team have a done a great job.

However, there is more to life than roses. It is not so easy when working with legacy data. For instance, it is not uncommon to have data in at least a couple of different databases. If we need to pull data from MSSQL and MySql into the same application we may have a problem. I ran into a problem running the Netbeans Entity class wizard to generate my JPA jar. Most of the tables could not be used because the primary keys were not recognized by the wizard. This isn't necessarily a problem, it just means if you want to use JPA, you have to hand code the classes in Java. If you are using Phobos and you run into this and you do not know Java, you might have to weigh just using jdbc as you can then script the object directly and you do not have to write Java code.

Check out the Phobos JPA generator tutorial at https://phobos.dev.java.net/tutorials/jpagenerator/index.html

On another note, be sure to check out Roberto's blog and his speech he gave at the Web 2.0 conference. the link is http://weblogs.java.net/blog/robc/archive/2007/04/phobos_at_the_w.html.
Roberto is one of the Sun engineers working on Phobos. He details the impressive speed and features of Phobos. The Phobos team has done a great job.

Phobos has the potential to really take off for the average developer if it can continue to integrate into the application stack. The way I view it, is that it sits very well under the presentation layer and works very well as the free flowing glue. The challenge will be, can it wrap the layers below it to make it really easy for the developer working in the Phobos layer. This what Ruby on Rails has done and its usage is skyrocketing. There are many more advantages to the Phobos/Java platform than the rails obviously, but ease of use and productivity are what will make a platform take off.