Juixe Techknow

Michael Yaun, JBoss/Red Hat evangelist and co-author of JBoss Seam: Simplicity and Power Beyond Java EE, presented on the Seam development using NetBeans. Michael started by stating the state of the art in web applications which include animations, effects, partial page upload, AJAX, RESTful URLs, back button support, etc. Any modern framework needs to have support for all these features. JBoss Seam takes a page from Ruby on Rails.

JBoss Seam is a complete Java EE stack made up of JavaServer Faces (JSF), Hibernate, and Spring-like dependency injection which adheres to Convention over Configuration and generators for rapid web application development.

JBoss Seam provides code generation, configuration by exception, testing is crucial, simplify simple cases (don’t over engineer), and adhere to agile web development. A key feature of JBoss Seam is that is follows the Java way, is standards based, scalable, allows for reusable components, and provides a choice in enterprise components.

JBoss Seam has code generators that can create a whole scaffold web application based on your database schema. For each HTML page you have two files, one XHTML and one XML use for page navigation. From what I gather, Seam seems more verbose than Grails or Rails and even Yuan himself said, “If you are not familiar with Seam it might seem really intimidating with all those XML files.”

JBoss Seam can be easily integrated with JBoss Rules engine and all those popular AJAX libraries such as Dojo and GWT. You can use the Red Hat Developer Studio for Eclipse will make Seam development easier.

Technorati Tags: javaone, javaone2007, jboss, seam, jsf, hibernate, spring

This JavaOne 2007 Bird of a Feather (BOF) session seemed like a brief history of web application development. In the beginning there was pain. In the second day XML moved forth. And on the last day there was Rails, and developers thought it was good. Ruby on Rails’ most mentioned philosophical innovations include Convention Over Configuration, Don’t Repeat Yourself, Opinionated Software, Test Driven Development, and the 80/20 rule. The 80/20 rules indicates that Rails is not all things for all web developer. Rails does one thing and it does CRUD applications well.

Rails growth coincides with the disillusion of EBJ 2.x, and the painful write, compile, deploy, and restart cycle.

Sails models leverage Hibernate, view uses custom template engine Viento, and the controller is rigged using custom dependency injection library which provides Convention Over Configuration. The Viento templating system provides Ruby-like features such as method missing, mixin, and reopening classes.

The second Java-based framework heavily influenced by Rails mentioned during this session was Trails. In addition to Rails, Trails was influenced by the Naked Object pattern, and domain driven design. Trails uses Tapestry, Spring, Hibernate, and Maven to tie everything together.

Grails was originally named Groovy on Rails and as such it was heavily influenced by Rails’ Convention Over Configuration, MVC, dynamic finders, and agile web development. Grails is powered by Hibernate, Spring, Sitemesh, Quartz, and the Groovy programming language.

A key benefit of Grails models over Rails models is that your model does not need to inherit some ORM ActiveRecord-like class, like in Rails. Grails embraces legacy enterprise systems with more complex relationships by leveraging Hibernate. Grails allows you to configure Hibernate and Spring when needed. A possible draw back, depending how you see it, is that in Grails you need to declare the properties in your model which will be mapped to your database table.

Groovy code compiles down to Java byte code. A Groovy class is a Java class, and vice versa.

According to the speaker both Trails and Sails don’t solve enough pain points while Grails is worth a shot. It is worth to note that as soon as some performance improvements have been made, JRuby on Rails will soon be a legitimate platform for your next web application. The benefits of Rails is that there are more books, more documentation, more inertia, and perhaps more developers for Ruby on Rails.

Technorati Tags: javaone, javaone2007, jruby, sails, trails, grails, webdev, ejb, ror, rails

David Botterill walk the audience through the design, analysis, issues, and resolutions of creating the NetBeans plugin portal site using NetBeans, of course, and JavaServer Faces (JSF). Some of David’s best practices for JSF development include are to come up with a preliminary set of requirements, use best guess at page design and page flow in prototype to get feedback, solidify the UI during analysis (the UI will effect the architecture), use Firefox Firebug to debug tricky HTML, CSS, and JavaScript.

Many of the issues described in by David seemed to have been web pack bugs that have since been fixed. That said, he did suggest some common pitfalls and how to avoid them. David suggested to start with Plain Old Java Objects, POJOs, not with relational tables and foreign keys, and joins, etc. David also stated that getting started with JPQL queries was a bit difficult, if for no other reason than it is something new that he had to go through. David found it difficult to have a button for a form which you can just press the enter button to submit it because there was no submit button on the form. Be aware of session timeouts, don’t make assumption in your software about the state of the session, always test for it. Be diligent about separating your CSS in separate files from your HTML. If you have a web application that relies heavily on the GET method then reevaluate using JSF because it makes it difficult.

Finally, David believes that for web applications resiliency is better than efficiency.

Technorati Tags: javaone, javaone2007, jsf, firebug, firefox, netbeans, jpql

This JavaOne 2007 session was packed the rim but I soon discovered I should have gone elsewhere. Everything in Java has some type of context and JPA is no different, the speaker was talking about the Persistence Context, blah, blah, Entity Manager, something or other. I found this session a bit hard to follow, a bit too technical and really dry. The slides looked like endless paragraphs from Tolstoy’s The Death of Ivan IIyich. A JPA junkie snapped pictures of the slides so that he can decipher and analyze them at a later time, or so I imagined, with the help of Java non the less.

Here are some general rules that I was able to grasp from this session… You need to manage the relationship of the parent and child object explicitly for each object individually. You should try to use left joins to fetch data in your queries. Using the @Version annotation attribute will help to detect parallel updates to a entity. You should use named queries whenever possible because they are cached by the JPA provider. Use fully qualified names for your queries such as ‘Employee.findByName’ to avoid named collisions. Concatenating strings in an attempt to make dynamic queries is not a best practice because it is open to SQL injection. Use named parameters in queries to avoid SQL injection. Try to avoid native SQL queries so that your application can be more database portable. That said, native queries might be required for vendor specific functionality or stored procedures.

Technorati Tags: javaone, javaone2007, jpa, best practices, orm, sql, sql injection

The jMaki project started as a wrapping utility for JS libraries and widgets. The j stands for JavaScript and maki comes from the Japanese word for wrapping, maku. The intent of jMaki is to promote clean seperation between content, style, and javascript and do so in an abstraction layer that lends itself well to a component model. jMaki is a client-server framework with support in PHP, Rails, or Java web applications.

jMaki has nice IDE support in NetBeans with plenty of wizards to get you started. Since jMaki provides a nice component model you can use the visual editor to wire together the UI of a web application in your IDE. Since a big part of web application development is getting the layout right, jMaki comes with several layouts right out of the box, all you do is select the template you want to use from the IDE.

To wrap a custom JavaScript library with jMaki you will need to create a jMaki widget. A jMaki widget uses the convention, instead of configuration, which is basically a folder containing three files, a HTML template, a CSS style, and JavaScript behavior. jMaki already has support for popular JavaScript libraries such as ExtJS, YUI!, Dojo, etc.

Greg Murray stated that he developed jMaki because he “wanted the reload button to be the redeploy button.” Well, since HTML, CSS, and JS aren’t compiled, that is easy to do. One button redeploy is not the stregth of jMaki, what jMaki has going for itself is that you can visual develop a web application using NetBeans and that this wraps several libraries in a easy to use fashion. jMaki also allows you to mix and match different JavaScript libraries together and communicate with each other using Glue. jMaki provides a common ground for integrating multiple of the currently existing AJAX libraries.

There is a jMaki on Rails plugin available and a PHP library.

Technorati Tags: javaone, javaone2007, jmaki, javascript, js, extjs, dojo, yui, php, rails, ruby, ror

The complete name of this JavaOne 2007 session was Java Puzzlers, Episode VI: The Phantom-Reference Menace/Attack of the Clone/Revenge of the Shift. This technical session was presented by perhaps the most effective Java developer Joshua Bloch and fellow puzzler William Pugh. Joshua and William presented 8 short programs with curious behavior. This session was basically a what does this program print interactive question and answer discussion.

The puzzles where like Google interview questions, a bunch of brain teasers which intended to preach a few moral and teach a few tips regarding interesting behavior at the language and JDK level. For example here are some tips I took away from the session, use URI instead of URL because the hashCode and equals method in URL is broken. Don’t mix short, long, int primitives and objects because autoboxing with knock you out. Autoboxing happens, when you least expect it. JUnit does not support concurrency. Wrapped primitives aren’t primitives. Watch out for circular class initialization when you mix statics and constructors, remember static code is process from top to bottom before constructors. If an API is broken, wrap it. For API designers, don’t violate the principle of least astonishment. Math.abs doesn’t guarantee non-negative results, for example Math.abs(Integer.MIN_VALUE) because Integer.MIN_VALUE == -1*Integer.MIN_VALUE. Avoid mixing types in the ?: ternary operator. Use find bugs, acording to Joshua and William Find bugs warned all of the questionable behavior.

Lastly, William said that the “Collections API where designed for what is type-safe, not what is sensible.”

Technorati Tags: javaone, javaone2007, effective java, api, puzzlers, programming, interview questions