Month: June 2006

Among the new features available (enhanced for loop, generics) in J2SE 5.0 (or 1.5, or Tiger) is the annotations functionality. I have always been hoping to come across simple introduction to such stuff and it came in this issue’s Tech Tips.

Annotations allow us to associate metadata with program elements: metadata is information that describe the program elements, and the elements may be methods or member variables in a class. Annotations are defined using a @xxx tag before the element.

The most common and obvious use is the @Deprecated tag. This tag declares the method as deprecated: it is outdated and kept for backward-compatibility. When the method is called from another class, a warning will be generated.

Other annotations defined in Tiger are @Override and @SuppressWarnings. @Override insists that you are overriding a method in case of a typo or wrong method signature, similar to C#’s Overrides modifier. @SuppressWarnings will tell the compiler not to tell you about certain warnings such as deprecation or unchecked casts in the method. It can be used with some options, such as @SuppressWarnings(“fallthrough”). This looks a lot like .Net’s annotations.

In addition, the tip mentioned that custom annotations may be defined, probably something like XDoclet. That could be something else I could learn in the future. The tip also contains a link to a book “Effective Java Programming Language Guide” by Joshua Bloch, which contains 57 Java tips. Well likely could be the next tip review here.

Javamail is the standard answer for mail access using Java. Currently supported protocols are SMTP, POP3 and IMAP. In short it means you can send outgoing mail using SMTP, receive email using POP3, and I’m not familiar with IMAP, though I remember having it in my Networking course. I think IMAP’s mails are stored and manipulated on the server, as opposed to POP3 mails which are downloaded (generally).

Using the classes was rather easy to me, partly because I am familiar with the SMTP/POP3 protocol (telnet and manually send/receive mails). Might be a good experience for you to try it (the telnet) too, to understand protocols on top of TCP. Online examples also help me to cut&paste code quickly.

Once peculiar thing is that Javamail depends on the JavaBeans Activation Framework (JAF). I’ve seen it around for some time, but never really knew what it was and what it does. I finally learnt that the activation framework handles MIME types (but how?) and so was useful in the JavaMail package. JavaMail was the only library that really used activation for a few years until web services came along. Web services which uses SOAP calls had MIME types as their encoding.

XML has grown to become important over the years, and it is natural that Java gradually adds support to it. Started from external packages in JDK1.3, core JDK1.5 now has JAXP 1.3 in it. JDK1.4 had JAXP version 1.2. Now java.net offers JAXP 1.3 as a standalone package so that JDK1.3 can make use of JAXP as well. However the bundle has no technical support (use at your own risk).

JAXP contains API to CRUD XML, both DOM and SAX. Thats alot of acronyms in one sentence… For DOM you create or obtain a Document, then manipulate elements and attributes within the document. DOM manipulation works generally the same for both Java and Javascript, since they adhere to the DOM specifications. For SAX you hook up handlers to perform tasks when start/end tags are encountered.

Transformers in the JAXP package allows you easily transform XML from one form to another, though I’ve only tried transforming it to a file. Handy output properties during transformation allow formatted output to make it more readable.

This post is purposely made very abstract — commenting very generally on JAXP. However it should contain enough keywords to allow searching for how to perform certain tasks. Dwelling into XML, DOM and SAX can potentially drag very long, with little benefits since there’s so much information out there already.

Other topics in the book did not have significant points (at this moment in time) for me to bring up. However certain bits and pieces keep recurring throughout the topics and are worth mentioning:

Consider Internationalization From the Start

If you’re doing an “Enterprise” application, always I18N your Strings. Especially on the JSPs. For database design, locale-specific fields should be normalized to another table with and additional locale column.

Design First, Optimize Later

Make sure you have a good design before you think about how to make your code run better. Don’t keep optimizing your code, let it go once it works (i.e. passes test case). Instead of worrying how well your code runs, think of the other business functions you have yet to fulfil.

In the end the code may not need to be optimized (maybe due to good design). Even if there is a need to, good design makes it easy to perform such optimizations. If optimization is considered first, the benefit may not be necessary, or further optimization is difficult later and hindered by poor design.

Continuing from the previous entry, I’ll discuss JDBC. Although there was a section on Servlets, the recommendations are more decision-levels such as deciding on a framework, mad caching and hiring a UI designer. So here I go…

Use DataSource Whenever Possible

I don’t fully agree with this yet, since I still don’t see the absolute benefit when using the DataSource technique. The book explains that using the old Class.forName() and DriverManager.getConnection() contains references to specific implementation classes.

I don’t agree because these information are Strings, which can be read from a config file and drivers can be loaded dynamically. Java programmers have always also used generic JDBC interface to deal with the underlying database (as I mentioned in a previous post).Therefore I see the same level of portability in using both methods, especially when a ConnectionManager is used to retrieve connections (encapsulation of connection logic).

Pool Database Connections

Enough said. If you don’t understand this ask me or Google.

Separate Application, Persistence and JDBC logic.

As per most apps, beans are used to model entity information and are already separate from JDBC logic. As a plus, using a DAO interface model can further isolate your persistence logic from the application, allowing your underlying persistence implementation to switch to non-JDBC.

This is already a common pattern in EJB, where entity beans rely on a DAO to perform stores, loads and finds.

Do not Rely on Built-in Key Generation

For portability sake, this is a must. Besides difficulty in locating the record just inserted, other databases might not have this feature.

The book also provide a sequencing method to generate unique keys, though I think it can be more easily implemented with a SELECT MAX (only for trivial apps) or a separate table storing the current sequence. The method presented offers better performance than my methods, so do an evaluation before deciding which to use.

Use PreparedStatement

I would say not only use it, but use it correctly. The purpose of using PREPARED statements is that it can be executed repeatedly efficiently. Therefore if you prepare a statement, execute it once, and prepare the same statement again next time and execute it once, you aren’t really using PreparedStatement correctly.

The preferred way to use PreparedStatements is have it prepared once, and executed many times. Be it a static query or with ? parameters, these “prepared” statements will offer better performance.

Reference Columns By Number

This is actually two problems in one. The first is that access to metadata information is expensive, and referencing column by name requires metadata. Most programmers access columns by name now due to the flexibility and convenience of not needing to remember column numbers as well as able to change the sequence in the SELECT without affecting the code.

However, just like column numbers can change, column names can change as well when the SQL is changed. The book says that rs.getLong(1) is as bad as rs.getLong("personID")

The “correct” solution is to externalize both the SQL and the sequence number so that the query can be changed without affecting the code

new PreparedStatement(PERSON_QUERY);
rs.getLong(PERSON_QUERY_PERSON_ID);

Close Statements and ResultSets

Despit JDBC specifications, some drivers do not clean up as cleanly as specified. To clean up completely, use the finally clause. In fact, this template should always be used.

Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
conn = ..;
stmt = conn.prepareStatement(..);
stmt.set..(..);
rs = stmt.executeQuery();
while (rs.next())
// ..
} catch (SQLException sqlE) {
// handle exception
} finally {
if (rs != null)
try { rs.close() } catch (SQLException sqlE) {}
if (stmt != null)
try { stmt.close() } catch (SQLException sqlE) {}
if (conn != null)
try { conn.close() } catch (SQLException sqlE) {}
}

Thread JDBC code in Swing Applications

In general I think this should be “Thread time-consuming task in GUI applications”. The threading, though it complicates the code, is necessary to provide a responsive GUI to the user. When time consuming tasks are performed in the GUI event thread, the event thread is unable to perform other tasks such as redrawing the UI or getting input from the user through the UI. This includes unable to cancel the event if the user chooses to.

At the same time, care should be taken when accessing GUI elements from threads. See the wiki for more information on this.

Do Not Use Primary Keys with Real-World Meaning

This tip effectively contradicts with the perfect data model of the primary key. The fact it is listed as a best practice in a published book demonstrates the vast difference between academic theory and industry practice. However for practical purposes, it is still better to issue a meaningless identifier to the data row.

You might argue some data like your IC number don’t change, but they might be entered incorrectly into the system in the first place (data entry, human/machine error) and needs to be modified.

This book from O’Reilly provides “Expert Tips & Tricks for Java Enterprise Programmers”. Apart from pure EJB stuff, the book covers tips for servlets, JDBC, XML, etc. I’ll be wrapping up the tips in a few short notes, espcially those I’ve seen/read around. First I discuss EJB tips.

Use ValueObjects for bulk data transfer.

Instead of making a get call for each property in your remote object, use a session bean to grab all necessary properties in a single call (thus also using the session facade)

Handle Exception in EJB Code Correctly.

My opinion about this is you should handle exceptions correctly EVERYWHERE! This involves understanding of when to throw, catch or wrap an exception. For EJB the logic is:

RemoteException: declared on all remote interfaces exposed by EJB. Used to indicate a network problem. You should not throw it yourself. If you call another remote object and receive a remote exception, wrap it in an EJBException.

EJBException: Thrown by developer and caught by container. Indicates major error to signal container to perform a transactional rollback. Like a NullPointerException, it’s a runtime exception and should not be caught by a developer. A common use is wrapping SQLExceptions into EJBException.

Application-level Exception: Should be thrown/caught by developer as part of application logic. Must be serializable (the exception will travel across the network). Do remember Exception Basics: Don’t use exceptions to indicate normal flow.

Using Business Delegates for Clients

This may look like pure redundancy to new-to-EJB programmers, however this cleanly separates client logic and EJB logic. One way to see this problem is when importing EJB packages in servlet classes. If the back end changes to non-EJB or the front end changes to non-webbased you get a problem. By introducing another layer into the already-many-layers you improve scalability and maintainability of your application (theoratically).

Create a Build Environment.

Even if you have a fantastic IDE that can automatically do all these for you, it’s useful to be able to make small changes to your app and re-building it without firing up and twiddling with the (likely-heavy) IDE. This is even more useful if you really understand your deployment. (and useful for people to learn about the actual deployment)

The displaytag library is a useful JSP taglib for generating html tables containing data in lists. By putting JavaBeans in an iterable list, the tag library can format the list into a HTML table, complete with the following features:

• Mapping columns to bean properties
• Built-in Pagination
• Built-in Sorting
• External sorting/pagination
• I18n
• Styles
• Exporting to PDF/Excel
• Integration with struts
• Grouping (never tried)
• Integration with webwork, sping framework (never tried)

Rating 4 out of 5. Excellent features, easy to use. 1 missing for un-organized documentation.

http://displaytag.sourceforge.net/11/

For the past two weeks I have actually been looking at a lot of Struts, but i’m still not well-versed enough to document it down, also because of the amount of information needed to document it. Seems like it’ll take a few pages.

Briefly going through it, Struts is a web application framework that enforces the MVC model. The sequence generally goes like this:

1. The user makes a HTTP request through the web (e.g. Employee.do?method=retrieve&empId=23)
2. The web server receives the request. By servlet mapping in web.xml, *.do requests are handled by the struts ActionServlet. The HTTP request is passed to the ActionServlet, which works as a controller dispatcher.
3. The ActionServlet receives the request, and checks the name of the .do (Employee). It looks up the action mapping configured in struts-config.xml (or a corresponding module config file). Information regarding the action’s form bean, Action class, validation, mapping forwards are retrieved.
4. The form bean declares the request parameters as Java data types, allowing automatic mapping to be performed, instead of retrieving all parameters as Strings.
5. If validation is required, validation is performed based on the form bean types, and any validation.xml as configured in the Validator plug-in. The configuration file allows basic checking such as required fields, less-than/more-than, regex, as well as custom validation providers. If validation fails, the request is immediately forwarded to the validation failure page.
6. Once validation passes, the Form Bean class is created and populated with the corresponding values in the request. The Action class is then called to perform business logic, using the information in the form bean class. The Action then redirects to the appropriate mapping forwards as defined in the action configuration.
7. Control returns to the ActionServlet, which looks up the actual URL of the mapping forward in the config file. All these lookups allow complete separation of URLs between the view and model.
8. The actual URL content is served to the client.

The framework is highly configurable, such as splitting the configuration into modules, using dynamic forms without creating actual form beans, tag libraries that easily display and retain information in form beans, etc.

Apart from Action 1, Struts also evolved into Action 2 and Shale Frameworks, which I’m unsure of the differences.