Java Hair

Over the last couple of years there has been a lot of talk about Ruby on Rails and Grails and how easy it is to use them to quickly build an application.  How would you like to be able to have all of that speed of development, but have it in a technology that you already know?  If you are familiar with Struts or JSF, you can use Rev to quickly build an application for you.

Rev is a code generation tool developed by Vgo Software, and it gives you the power to do that.  All you need is a database, a JDBC driver (most of the common ones are provided with Rev out of the box), a JDK of version 1.5 or better and Rev.  Using Rev you’ll be able to generate a completely functional CRUD application based on the tables that you select.  The output can be in a variety of different flavors: JSF, Struts, JSF with AJAX, JDBC, EJB, Hibernate, etc.  Rev also generates ANT build scripts for a variety of popular application servers so you can build and deploy your application directly from the tool.

What good is a CRUD application?  It all depends on what type of application you are building.  For adding testing data or building some Administration screens for a system, the Rev output may be all you need.  If you are building a more complicated system, then maybe the persistence layer is all you need and you can rework most of the UI layer.  All of the source code is available for you to modify as you see fit, so whether it is the final application itself or the basis for something bigger you will always have something to start with.

One of the unique features of Rev is the ability to customize the generation.  Not only can you easily customize the stylesheet from within Rev, but if you want to go deeper you can customize the templates that Rev uses to generate virtually whatever you’d like.  From modifying the JSP pages that get generated to creating a whole new set of templates for a completely different language, you can do it all!  In fact, included with Rev is a set of templates for generating a PHP-based application.

You can download your free trial of Rev at the Vgo Software site.  Also, be sure to sign up for the webinar I will be presenting on June 30th at 11:00 a.m. EST.  During that webinar I will demonstrate how to use Rev and talk about the various output options.

My last post about frameworks criticized the Spring JDBC Template construct. I don’t really have anything against Spring in particular, I had just stumbled across the JDBC Template a few days earlier and thought it may help make my point. My point, which I attempted to illustrate by that post, was not that the Spring JDBC Template is useless, it is that frameworks in general, which exist to simplify development of complex technologies, by their nature redirect that complexity somewhere else. Hopefully that new complexity is less than the underlying technology and this is often the case. As an architect/designer/developer you should be aware of that the trade-off exists, what the trade off is going to be and make an informed decision.

1.  Configuration Files

Since I used Spring as an example once before, let’s move on to another one of my other favorite frameworks, Struts. Struts has seemed to have fallen out of favor of late, with many developers now hopping on the JSF bandwagon, including our shop. I had to basically be dragged away from it and forced into JSF. However, even though Struts was my framework of choice for years, it had some problems that really bugged me and are issues that still exist today in many frameworks.

One of the nice things about Java is that you can use a smart IDE and it will spot a lot of careless errors for you, especially simple typos. This is important for someone like me who likes to type fast and can tend to be somewhat careless. What I found with Struts is that I often had problems first setting up projects. For some reason I would always end up with a typo in the struts-config.xml file that would cause it to break when starting my application. Struts was never very good at letting me know what the exact problem was and this never ceased to infuriate me, so much so in fact, that one of our products, Rev, was born out of that frustration because it insured that I wouldn’t have to worry about typos impeding my ability to get an application up and running quickly. I continued to use Struts because it’s benefits outweighed it’s difficulties, it didn’t abstract too much of the HTTP layer so I could still understand what was going on pretty easily.

2.  Too much abstraction

Next, for me, came JSF. I actually only started using it because a project we were working on required a technology that was built upon JSF. Once I started using it, I could appreciate how it’s abstraction of the HTTP layer really made things easier for developers, especially for newbies who didn’t really know much about the HTTP layer. All of this abstraction, however, made it difficult to understand what was happening underneath the covers or exactly how it was happening. Some of the simple Javascript patterns I had been using in Struts to solve some common problems became more difficult. Have you ever looked at the source HTML to a JSF-backed page? It’s not nearly as simple and straight-forward as a page developed from Struts. I am still uncomfortable with the fact that I don’t know exactly how to create a request in JSF to accomplish some things seemingly trivial things, whereas the same things in Struts were really easy.

The other problem that I found as we continued to use the framework was that I could have developers who understood JSF and worked in it really well, but they didn’t understand some of the underlying concepts. When something unexpected happened, they weren’t sure where to look. This would occur when a developer’s first experience with developing web applications was with JSF.

That same problem occurs with any framework, since by their nature they abstract the complexity of some underlying technology. This is all well and good until things break. Obviously, Java itself is an abstraction of underlying technology, do I think we’d all be better off going back to assembly language and programming web applications in that? Of course not, but I think as a developer you should be aware of the pro’s and con’s of the frameworks you use.

You should also take it upon yourself to learn something of the underlying technologies so you aren’t completely clueless. I have interviewed plenty of so-called JSP developers who couldn’t tell me what pieces of code were executed on the server and which on the client, who didn’t understand the underlying concept that once your page was executing in the browser, you weren’t able to execute java commands inside a function in a page. I could understand how a newbie might have some problems with that, but an “experienced” JSP programmer?

3.  The Problem with Fixing #1 and #2

Often, with frameworks that become popular, it’s because the abstraction they provide is more useful than the underlying technology by itself and any new complexities it may introduce, it allows developers to become more productive, hopefully much more productive.

In my opinion, Oracle’s new version of ADF, 11g, is a framework that does just that, but it isn’t without it’s share of compexities either. ADF 11g makes a lot of building a web application declaritive. This may be a good thing, but again, you run into the problem of having to deal with many XML files. Oracle alleviated this problem to a very large degree by creating JDeveloper 11g which can handle building and validating the XML files for you. However, now we have a new problem. There are some mismatches between JDeveloper 11g and ADF 11g. In some cases, just because JDeveloper tells you something is wrong doesn’t mean it is wrong and won’t work. This hints at a larger problem: that both JDeveloper and ADF need to be maintained and released on the same cycles. If one falls behind in respect to changes that were made to the other, the usefulness of the collaboration between the two is degraded.

Also, again in ADF 11g, there is a larger issue. That is, if something acts in an unexpected manner, the developer now needs to understand an additional layer of complexity in order to debug the problem. Often the developer will need to resort to asking the experts via a forum or a bug report. Even if the product is open source and the developer could access the code itself, finding and fixing a problem deep within the framework will obviously detract from the usefulness of the framework itself.

None of these “dark sides”of frameworks are reasons not to use them, I use or have-used all of them, these are just issues that you should be aware of and investigate before using a framework. My “issues” (some may describe these as pet peeves) can be distilled into two main items, 1. Increased abstraction often leads to less understanding and 2. Declarative programming creates its own problems.

Obviously we are going the way of more abstraction, not less.  It will be  a great day when we no longer have to worry about the framework we are using breaking and exposing us to the dirty underbelly of technology behind it all.

</rant>

A lot of people ask us where the name Vgo Software comes from. (That’s pronounced Vee-Go Software in case you were wondering.)  Since I’m in Greece this week with a client and I haven’t posted anything in a while, I thought I would expound upon where our name came from.

Back in the day, we were just a consulting company. At that time I had come up with a prototype for what eventually became our Rev product. I remember writing an e-mail to my business partner about this prototype. While writing the e-mail I realized that I did not have a name for the project and started to think about what I would call it.

Earlier that day I had talked to a consultant that was working for us and who was a friend of mine. He told me that he had been experiencing bouts of dizziness earlier in the week and didn’t know what was causing it. After suffering for a couple of days without it getting any better he went to the doctor to see what the problem was. As it turned out, the doctor told him he either had a cancerous tumor in his ear or he had Vertigo.

Thinking about what to name the software, which was a code generator, I thought “Vertigo!” what a perfect name! It generates code so fast it will give you Vertigo. Well, I put that in the e-mail as the name of the prototype and the name stuck for a while but at some point before we actually released it somebody did a name search and determined that the name Vertigo was actually being used by another software company for another product.

About a week later we held our monthly staff meeting where we gather everyone from wherever they may be, talk about current company events, and have beer and pizza. We decided it would be a good time to come up with a new name (esp. after the beer part). After everyone throwing out various names for about an hour, we finally settled on a mutilated version of Vertigo, Vgo.

Well, Vgo eventually became our code generator, Rev, and the product built on top of that which was once referred to as Vgo4Oracle became Evo (anybody notice a pattern emerging?). Both products were part of the “Vgo Software Suite” of products and we eventually just started using the name of the software itself as the name of the company.

As you probably saw in Ernt’s earlier post, we exhibited at ODTUG Kaleidoscope this year. It was our first year at the show, but I don’t think it will be our last. To me the show was more valuable than Oracle Open World which we’ve exhibited at for the past 3 years. It may be that as a vendor, exhibiting at OOW is a necessity, but as a developer, exhibiting at the ODTUG show was much better.

What was most encouraging was being able to demo our products to a wide range of people who understood what we were talking about and what our products are trying to achieve. I believe that anyone who believes in code generation as a viable “enhancement’ to custom development should take a look at Rev and see what it can do. I was encouraged to speak to one person who said that he believed we are getting to the point where everything can be done by code generation. I certainly believe that any software project that persists data to a database can benefit from code generation.

Enough about Rev. We had the chance to demo Evo to a number of folks who had some great insight and advice. To me, that was what made the conference such a success. The ability to be able to network with such a great community of people who really want to see a product that can do things right was encouraging.

I had long wanted to speak with Wilfred van der Deijl about his solution to the ADF/Forms integration problem and get his impression on Forms to ADF conversions. At this conference I had the chance to do that. Even though I missed his presentation (the time had changed and I didn’t check the board), he was kind enough to stop by the booth and show it to us personally. It’s a great solution for a problem that we have been asked about many times. If you are into Forms or ADF developement, you should definitely check out his blog. It was nice to see from his blog that he believes we are on the right path.

Peter Ebell over at AMIS in the Netherlands stopped by. If you are into hardcore ADF development, checkout the AMIS blog where Peter is a contributor. Anyway, he stopped by to get a demo of our Forms conversions and hopefully will post his thoughts about it. We talked a lot about Forms Conversions, JHeadstart, and even Whirlyball.

I, unfortunately, did not have the time to attend any of the sessions I wanted to. In each case, when the time for one of those sessions rolled around I was engaged in a product demo or an interesting discussion with one of the attendees. I suppose it’s better to network at these things than sit in on sessions all day, but a nice mix would have been appreciated.

It was a great show and we all had a good time. Though I am not a NASCAR fan in particular, I did get to Daytona USA as guest of Oracle’s at the ODTUG party they held there, and though I was less than impressed, when I stopped by the following day as we were leaving Daytona and got a chance to check out the grandstands with some cars on the track, it was very cool. I don’t think I’ll be watching any NASCAR races on the tube at home, but if I get the chance to attend a race in person, I think I’ll take it. Just the sound of those engines as the cars go screaming by is quite impressive. Not quite as impressive as Evo or Rev, but impressive nonetheless