Java News - August 2009 - Java SE 7 and Java-Related Acquisitions

There have been several big news stories related to Java development this month. Several of these stories are sure to have long-term impact on Java developers. These stories include more definitive information on what to expect in Java SE 7 and the continuing consolidation of Java-related companies.

Update on Java SE 7's Project Coin

Project Coin is the aggregation of "small language" changes for Java SE 7. I have blogged about some of the potential features to be added to the Java programming language as part of Project Coin in blog postings such as Small Java 7 Language Changes, Java SE 7 New Features: Latest News, and 2009 JavaOne: Project Coin.

This week, we have learned more information on which small language proposals will be delivered in Java SE 7. Several blog posts have relayed this news and the DZone Top Links currently has the top four links as related to Java SE 7 (three specifically related to the small language changes announcement).



The big announcement of which small language changes will be delivered with Java SE 7 was provided in Joseph D. Darcy's weblog entry Project Coin: The Final Five (or So) (DZone link). Other popular blog postings covering this development include JDK7 Tackles Java Verbosity (DZone/JavaLobby links) and The Seven Small Language Changes that will be in Java SE 7 (DZone link). The last linked post provides additional background detail on some of the implementation progress for the accepted small language changes.

The seven new small language features accepted for inclusion with Java SE 7 are:

1. Switching on Strings

I have written about the lack of Java support for switching on String and on this proposed new Java SE 7 feature. Many other languages have this feature and I have known several developers new to Java who have wondered why it has not been there all along. I feel less interest in it now with the addition of enums in J2SE 5, but it will still be a handy feature to have occassionally.


2. Automatic Resource Management (ARM)

This Joshua Bloch-authored feature proposal is covered thoroughly and relatively succinctly on this Google docs page.


3. Improved Generic Type Inference (Diamond)

I generally like the compile-time type safety provided by Java generics, but there are some ugly things about the generics support. Some improvement in experience with Java generics will be available in Java SE 7 with the generic type inference support. It's not generics reification, but it will still be welcome.


4. Simplified Varargs Method Invocation

Like the improved type inference addition, this new feature will improve developer experience with generics, in this case particularly with mixing generics and varargs.


5. Language Support for JSR 292

This feature is especially attractive to developers who like to use dynamic languages that run on the Java Virtual Machine. JSR 292 is the Java Specification Request called Supporting Dynamically Typed Languages on the Java Platform and the Project Coin portion is specifically related to language support for dynamic languages.


6. Language Support for Collections

In his announcement, Darcy mentions that this accepted Project Coin feature is actually a combination of Collection Literals and Indexing Access Syntax for Lists and Maps. The "Collection Literals" feature would allow for a much more concise and potentially clearer syntax where the Collections class is used today. A main benefit of the "Indexing Access Syntax for Lists and Maps" is the consistent syntax for accessing elements of arrays, Maps, and Lists.


7. Better Integral Literals

Like the last one covered here, this feature is actually a combination of multiple feature proposals. The binary literals proposal and underscores in numbers proposals are the two key proposals Darcy cites as part of this feature.


The Features of Java SE 7

I must confess a little disappointment at the new Java SE 7 small language features from Project Coin. There are some new features that I will be glad to have, but I really wish that Elvis and other null safe operators would have not been voted off the island.

The small features that do appear to be headed for Java SE 7 will be useful and, of course, there are other advancements expected in Java SE 7 of larger magnitude than the Project Coin features such as the improved modularity.

More on the features of Java 7 and a downloadable Java SE 7 preview are available at http://java.sun.com/features/jdk/7/.



SpringSource Acquires and is Acquired

We learned on August 10 that SpringSource was being acquired by VMWare. Just days later, on August 19, we learned that SpringSource had acquired Cloud Foundry.


Terracotta Acquires ehcache

SpringSource was not the only one involved in Java-related mergers and acquisitions this month. We also learned on August 18 that Terracotta has essentially acquired ehcache.


Oracle Acquisition of Sun Approved in United States

The largest Java-related acquisition of the year passed a significant milestone in August with the late August announcement of approval of the Oracle/Sun deal by the United States Department of Justice. The deal also has shareholder approval, but still requires European regulatory approval.

Software Development Bumper Sticker Practices

I loathe bumper stickers. I don't understand what a person is trying to accomplish by defacing his or her vehicle with these bumper stickers. In this blog post I examine how bumper stickers and the misuse of best practices have much in common. This post is not intended to offend owners of bumper stickers - I'm sure that there are people out there with bumper stickers who have them for reasons other than those described here.

I have long been a fan of best practices and rules of thumb that make sense. In fact, I have written three articles on best practices (JSP Best Practices, More JSP Best Practices, and Basic JPA Best Practices). However, as Bill Jackson and many others have pointed out, effective software developers must be willing to think for themselves and deviate from best practices when appropriate rather than blindly adhering to "best practices" at any cost and regardless of circumstances.

A "best practice" that is employed without regard for why it is advantageous and without recognition that things are usually too complicated to always be done "one way" is very likely to end up as a "bumper sticker practice." A "bumper sticker practice" suffers from many of the same problems associated with bumper stickers on vehicles.


Two Sides to Every Story / Trade-offs

Political bumper stickers with pithy statements pushing a position or degrading an opposite position can be particularly irritating and useless. The worst offenders are the bumper stickers that try to boil complex issues down to three to seven words that fit neatly on a bumper sticker.

These types of bumper stickers remind me of the software developer who rigidly applies a "best practice" without really trying to understand if the practice is appropriate or if the particular circumstances reduce the value of the "best practice." For a developer in this example, touting their favorite best practice at every turn might make them feel good about themselves, but that doesn't necessarily make the decision correct. Instead, software development is full of trade-offs in design and implementation and the most effective software developer is able to and willing to look at alternatives to their favorite pet practice.


Pride / Showing Off

It is difficult to think of why a person would place a bumper sticker on his or her vehicle about his or her child being an honor student at such-and-such school except out of a sense of pride. Likewise, it is common to see people place bumper stickers on their vehicles advertising the university they went to (or at least cheer for in athletic events).

It is easy for a developer to fall into the trap of throwing around "best practices" phrases, calling design patterns out by name, and doing similar things in an effort to impress others. Like the bumper stickers, others are often far less impressed with these tactics than the person might believe.


Obsolescence

I have seen bumper stickers for political candidates many years after the particular election to which the stickers applied. I have seen this in cases of both candidates who won the particular election and even candidates who lost that election. I do not really understand why a person would keep a bumper sticker advocating a candidate whose election is won or lost for years after election, but it does happen.

Likewise, a favorite "best practice" can be difficult to shed even if its value is overtaken by advancements and time. The best of the best practices are often relatively timeless and will stand the test of time, but some of the "lesser" best practices are more prone to be the recommended approach one day and fall out of favor compared to new and improved ideas that come along later. The most effective developer is able to continually evaluate "best practices" against current trends and circumstances and is willing to learn new ways to do things. New isn't always better than old, but it is a mistake to not be willing to take advantage of new developments.


Indicative of Aggressive / Forceful Nature

In Bumper Stickers Are Dangerous, Jonah Lehrer cites a study linking increased aggressiveness in driving behavior with owners of bumper stickers. This does not seem particularly surprising, at least in the case of political bumper stickers, because apparently the primary reason for having such stickers is to foist one's opinion on others.

Many of us in the software development community (and I intentionally include myself with "many of us") don't need much encouragement or incentive to have and share our strong opinions with others. I actually have found that strongly opinionated software developers are regularly good at what they do, though being aggressive and overbearing does not always translate to being a good software developer. Any software developer, good or bad, can easily become more aggressive as they defend and throw around their favorite pet practice. I have seen developer who almost seem to want to pick a fight about a favorite practice. I don't understand this mentality whether used with a best practice or applied to a bumper sticker.


Is There Substance Behind the Sticker / Practice?

When I see a bumper sticker expressing a "clever" five word opinion about a particularly complex social, economical, or political concept, I wonder if the owner really understands all the complexities of the issue (or at least understands that they exist because it is difficult for anyone to understand the entire issue) or if they truly believe everything is that simple. My impression is that the owner often lacks the sophistication, knowledge, and life experience to truly understand these complex issues or else he or she would be embarrassed to paste a naive and simplistic bumper sticker on his or her vehicle.

The same can be said for some developers who throw around the latest "best practice" and buzzwords. It is disappointing to find out that in some cases the developer really only has a simplistic view of the problem space. In such cases, he or she does not really understand why a "best practice" is recommended or why it works in most situations or recognize situations in which it is not a best practice.


Inside Information Reduces Effectiveness

I occassionally see a bumper sticker with a phrase or clause for which I don't understand the point being made. My guess is that in many of these cases that it not the effect the owner of the bumper sticker wanted.

The same effect can occur in software development with best practices. In my opinion, a "best practice" is one which most experienced developers would agree is generally the best approach for a particular situation. A practice cannot be a best practice, in my opinion, unless it has been proven and confirmed by a large percentage of experienced developers in a wide variety of circumstances.


Distractions

Bumper stickers can be distracting. Some have text so small that another person who might want to read it must tailgate the vehicle to see it. If there are enough small words crammed onto the sticker, another driver trying to read it might be dangerously distracted. I have found myself somewhat distracted in a slightly reluctant way when I have seen a vehicle completely covered with bumper stickers. Almost like a voyeur, I want to read all of those stickers to see what that person is advertising about himself or herself or to laugh at a particularly clever one. I have often felt that bumper stickers are as bad as any commercial advertising when it comes to being visual pollution.

We should not allow our rush to apply a best practice distract us from doing the difficult but necessary work of truly understanding a problem and considering the alternatives to satisfying that problem. We want best practices to help us improve our software rather than clouding our judgement and polluting our decision-making ability.


Letting Others Think For Us

One of the saddest things about bumper stickers is when the owner is so proud of himself or herself for the cleverness of their bumper stick when it is not even their original thinking. Anyone can read an article, column, or blog and regurgitate the cleverness they read or heard there. Adding real value requires effort, creative thinking, and adding person contributions.

Software development is no different. Effective use of best practices includes learning from one's own experiences so that one can better understand why a best practice is generally good and how it addresses particular problems. Also, best practices should be continually tweaked and should evolve based on community contributions and discussion. Best practices will become even better practices through the combined effort and experiences of the software development community.


How Do We Prevent 'Best Practices' from Becoming 'Bumper Sticker Practices'?

I think we as developers can take certain precautions to prevent "best practices" from becoming "bumper sticker practices." These precautions can be categorized as understanding best practices and applying them judiciously. We are more likely to turn a best practice into a bumper sticker practice when we don't understand a best practice or apply them indiscriminately. Here are some things I try to keep in mind when considering application of a particular best practice.

⇒ Understand 'Best Practices' Concept - To me a best practice is a practice that is widely recognized by experienced developers as a practice that generally is superior to alternative practices.

⇒ Understand the 'Why' of a Best Practice - A best practice is most effectively applied when the developer understands the necessity for the best practice (improved maintainability or some other desirable feature).

⇒ Understand the 'How' of a Best Practice - Understanding how the best practice addresses the particular problem is key to understanding when it truly is a good practice and when it is an irrelevant or bad practice.

⇒ Understand Best Circumstances and Worst Circumstances for Best Practice - Although a "best practice" should, in my opinion, be the preferable practice for a majority of situations, there are few, if any, practices that are always the most appropriate in all circumstances. Effective application of a particular best practice requires understanding which situations the best practice is less desirable than alternative practices or even downright detrimental.

⇒ Keep in Mind the Value of Others' Experiences and Opinions - One of the most galling aspects of some political bumper stickers is the implication that the owner of the sticker is smarter than people who don't agree with him or her. Not all political bumper stickers are designed to imply that, but many are. Even when I believe strongly in a particular best practice, I try to be open-minded enough to consider if an alternative approach works better in a given situation. There is no reason to be too stubborn about a particular practice if other practices are better.

⇒ Continual Learning and Hands-On Experience - Continual exposure to new ideas, concepts, patterns, and languages can be useful in reaffirming understanding of current best practices and in identifying new development best practices.

⇒ Know When to Say No - Although I believe that a best practice is one which has earned agreement among experienced developers about being a superior practice in general cases, software development is full of trade-offs and widely varying situations. Our favorite best practice can remain such if we don't misuse or abuse it and end up having a bad experience because of it. Sometimes we just have to let go.

⇒ Focus on What Counts - The value to appropriately used best practices is that they can allow large groups of developers with varying skill levels to write reasonable applications meeting many different architectural and design requirements. However, we cannot become so distracted by our best of intentions to apply a best practice that we miss the finer points of a particular problem.

⇒ Best Practices Can Be Contradictory - As evidence that software development is full of trade-offs, there are times when two best practices contradict each other. This tends to occur when one "best practice" is best in terms of a certain quality while the other "best practice" is best in terms of a different (and possibly opposite) quality. For example, a "best practice" for maintainable code can sometimes contradict a "best practice" for performance concerns. With software development being so full of trade-offs that even best practices can be contradictory, it is not surprising that we cannot blindly, naively, and uniformly apply the same practice to all circumstances.


Conclusion

I am a strong believer in effectively applied best practices. I believe the collection of best practices can provide significant benefits to the software development community when discussed, debated, applied, and reapplied. New concepts can be woven into past experience to constantly adapt and improve upon our collections of best practices. Best practices are most effectively applied when the developer understands the problem the practice addresses, understands why the practice is superior to alternatives for that particular problem, and understands that no one practice can be "best" all the time in all situations. When best practices are applied without understanding these things, they can quickly turn to "bumper sticker practices" with all the worst characteristics that can be associated with bumper stickers.




Addendum: My True Feelings about Bumper Stickers

I started this post with the relatively strongly worded statement, "I loathe bumper stickers." To be fair, I loathe political bumper stickers and have only a mild dislike of most other bumper stickers. I also must admit to laughing out loud at some particularly clever bumper stickers that did not seem to have any of the most negative characteristics described above (unnecessary flaunting of one's accomplishments/pride, aggressive forcing of opinions on others, trivializing significant and complex issues, etc.). These bumper stickers (like "My kid beat up your honor student" and "My other car is a piece of crap too") are funny. I'd never put them on my vehicle, but they are funny nonetheless.

Likewise, there are good "bumper stickers" in software development. I like the short bumper sticker-like quotations in Jon Louis Bentley's Bumper-Sticker Computer Science. I also like Joshua Bloch's Bumper-Sticker API Design, but note that he goes past my biggest problem with bumper stickers (naive, simple, and pithy statements) to actually describe each point. Both Bentley and Bloch can also get away with a little "bumper sticker" cleverness because there is no question that they speak from experience and knowledge in the computer science arena. They have contributed to the literature and discussions consistently and prominently. In other words, I know there is substance and depth behind their statements.

Start Refactoring Unfamiliar Code by Starting Refactoring

I refactor my own code frequently. It is often relatively easy to refactor my own code because I know my code well. In fact, the process of maintaining and reading my own code often provides the motivation to refactor it. If the code is covered by comprehensive unit and regression tests, this refactoring is even easier. I have found that refactoring of unfamiliar complex code is much more difficult. In this blog posting, I look at the most important step I have discovered in refactoring other developers' complex code.

The concept of code refactoring has existed probably as long as software development, but the coinage of the term "refactoring" and the subsequent development of the concept formally has added to its popularity. The popularity of code refactoring is demonstrated by the popularity of related books on the subject such as Refactoring: Improving the Design of Existing Code and Refactoring to Patterns. The concept of code refactoring is so popular that it has even spun off related new topics. The book Prefactoring is an example of this phenomenon.

Martin Fowler defines refactoring in multiple sources including in an interview and on the main page of Refactoring.com:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

When initially looking at large, complex code that I am not very familiar with, I often try to understand it all at once in an effort to refactor the entire thing quickly. If the code is unfamiliar enough, large enough, and/or complex enough, this rarely works well. I have found that I am much more successful refactoring large, complex, and unknown code bases when I start with small and easy refactorings. This may seem like common sense (in many ways it is), but in the rush to refactor, I still sometimes try to get ahead of myself.

When writing a book, paper, or article, an author often finds one of the most difficult aspects to be just getting started. This can apply to beginning refactoring of others' complex and unwieldy code. Sometimes it is best to dig in and start refactoring, even if it is small, simple refactoring.

I have found that refactoring small, simple things has helped me refactor unfamiliar complex code for several reasons. First, even simple refactoring often makes the code easier to further refactor because a little complexity is removed during each stage of the refactoring. For example, as code becomes more modular, it is easier to see repeated pieces of code and modularize even further. Another example is that removal of dead code often simplifies reading of the remaining code. It's a very satisfying feeling to see difficult code become significantly more readable. A second reason that I believe that refactoring small and simple pieces at first helps is that the act of refactoring gets me into the previously unfamiliar code so that it becomes increasingly familiar.

Finally, I think that a third reason that these initial, simple steps in refactoring are beneficial is because they are implemented when preconceived notions may be less likely to affect one's thinking. Although refactoring is often performed because new or increased knowledge allows us to improve things, the opposite can also happen: one can be so familiar with what the code is supposed to do that it is less obvious that the code needs refactoring. A fresh set of eyes, which are freshest when first looking at and starting to refactor unfamiliar code, may lead to cleaner code that is more readable for anyone new to it. We can return to the analogy of writing prose again to illustrate this. It is sometimes easier for another person to find issues with one's writing than for the author to find because the author knows what he or she means to write and implicitly fills in any gaps with that knowledge. This is the key principle behind code and writing reviews. In Extreme Perl: Chapter 14: Refactoring, the author points out that another set of eyes can be helpful in refactoring unknown complex code.


Conclusion

Although, by definition, refactoring does not change the functionality of the code, I have found refactoring to be extremely valuable in improving non-functional aspects of my code such as improved maintainability, improved readability, and sometimes even better performance. I can achieve these same benefits by refactoring others' code, but that can often be more difficult than refactoring my own code. However, I have found that perhaps the most important step when refactoring unfamiliar and complex code is to dive right in first with simple, obvious refactoring.


Addition Reference: Once-A-Day Refactoring

Sean Chambers is currently posting on a daily basis on refactoring. If you're new to refactoring or would like to read in-depth coverage of various refactoring techniques, you'll likely find these Refactoring Day XX blog posts to be helpful.

Static Imports and System.out

In Cay Horstmann's recent blog posting Are You Using Static Import? he asks the question, "Have you switched from System.out to out with a static import?" I found this to be an interesting question because it got me thinking about a different ways that my Java coding has changed over the years and over the different versions of Java.


My Use of System.out

I like static imports and do use them in situations that feel appropriate. However, I have only occassionally used a static import in conjunction with System.out or System.err. I realized that there are several reasons for this with the most important being that I simply don't use System.out or System.err as often as I used to.

In production code, I typically use a logging tool such as log4j or java.util.logging rather than using System.out and System.err. For simple tools with command-line interfaces, I have become a big fan of the java.io.Console class. Its readLine() and printf methods are easy to use. The only downside is that it requires Java SE 6 and a console device. I still do use System.out and System.err occassionally for simple examples and for quick and dirty debugging, but often these cases are such that it has not seemed worth the effort to statically import System.out. Although I have not statically imported System.out very often, I don't think it's a bad idea. I explore the reasons for this in the remainder of this blog posting.


Advantages of Statically Importing System.out

For a JavaServer Pages (JSP) developer, importing System.out statically can feel right at home. One of the implicit variables that web containers support for JSPs is the out variable. This implicit out variable (JspWriter) can be used by the JSP author in much the same way that a statically imported System.out (PrintStream) can be used. Statically importing System.out also allows the out to be used in a way that feels similar to using Groovy's println without needing to scope it explicitly.

There are general advantages of static imports that can make them attractive. An obvious advantage is more concise code that uses constants. I especially like to statically import classes used as parameters to Java annotations. For example, static imports allows me to use the JPA annotation @Inheritance(strategy=SINGLE_TABLE) rather than @Inheritance(strategy=InheritanceType.SINGLE_TABLE).

I prefer use of static imports in situation such as these when their use is most likely to be obvious to other developers maintaining my code. Developers familiar with the Java Persistence API (JPA) should not need the class scope on the annotation's parameter and the context of the annotation implies the relationship of the parameter. Likewise, I believe that using out for System.out couple with familiar calls like println() is conventional enough to not be a problem.


Disadvantages of Statically Importing System.out

The comments on the previously cited Cay Horstmann blog post are longer than the blog post itself. We all have opinions. I do believe there are times when static imports can cause more maintenance problems than they are worth, but I think they are beneficial and safe to use in the appropriate circumstances as described above. I don't use static imports indiscriminately, but do think they improve readability and maintainability when used in the appropriate context.

In general, I agree with the "Static Import" portion of the Java Programming Language J2SE 5 New Features and Enhancements documentation which states:

So when should you use static import? Very sparingly! ... If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. ... Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names.

I think the above snippet, along with the more explanatory text I omitted here for brevity, does a nice job of describing appropriate use of static imports.


Conclusion

As with most controversial development issues, my feeling is that absolute positions such as "always use" static imports or "never use" static imports may be easier to remember, but that just a little consideration can lead to effective use of static imports for more readable and maintainable code.


Others' Thoughts on Use of Static Imports

⇒ StackOverflow: What Is a Good Use Case for Static Import of Methods?

⇒ My Dislike of Java's Static Import Feature

⇒ Use Static Imports Rarely

⇒ Do You Like Static Imports?

New Blog for Java Developers: CertPal

Many of the most popular software development blogs are long-running blogs. This is not surprising because it is obvious that the longer a blog exists, the more opportunity there is for it to be discovered and featured on sites like DZone. If a blog is long-running and consistently offers material readers feel is worthwhile, the blog can become extremely popular. Rather than subscribing to particular blogs, I tend to use aggregation sites like DZone or JavaWorld blogs and then click to articles of interest, which often end up linking to a well-known blog or at least to a well-established blog. However, from time to time, a new software development blog comes along that grabs my attention for its freshness and content. I have previously written about the somewhat contrarian blog called The Programmer Has No Clothes. In today's blog post, I want to highlight the CertPal blogs that appear to have just been started this month (August 2009).

According to their About Us page, CertPal provides education services related to certification test preparation and related topics. I am impressed with the frequency and breadth of their posts so far. As of this writing (afternoon of August 22), they have posted seven entries already this month (and the first entry was mid-month). Topics covered so far include Navigable Set (I have previously covered the similar NavigableMap), Sun Java Certification Pitfalls, limitations on a Java method size, autobox/unboxing gotchas, and free UML tools (not including the one I use - Oracle JDeveloper 11g's built-in tool).

Although I typically don't subscribe to blogs because I have found that I ignore such subscriptions anyway, I will be adding the CertPal blogs to my short list of blogs that I browse to on occasion to see what their latest offerings are. Many blogs start out strong and sometimes quickly wither away, but CertPal's blogs look like a valuable addition to the Java side of the blogosphere.

Note: I have absolutely no affiliation with CertPal and no idea of their future plans for their blog posts.

Faithful Old Development Tools

I had the opportunity to visit Yellowstone National Park this past week for the first time in many years. One of Yellowstone's most famous attractions is the Old Faithful geyser. This geyser is so named because it relatively faithfully keeps to its eruption schedule. There is some variance, but most of us who have gone to watch it erupt at its scheduled time have not gone in vain.



In this blog posting, I discuss some of the software development tools that have proven faithful for me for many years. In most cases, there are new and advanced tools available that I use more frequently, but I still find situations when the older tools are useful and I’m glad to have them around and to know how to apply them.

The vi Editor

Although I use an IDE for the majority of my development, I still find myself using vi (or a derivative) frequently. Indeed, I prefer IDEs that support a vi plugin or mode so that I can use some of my favorite vi commands within the IDE. There are many things IDEs do very well, but I find myself in situations fairly often where I don’t want to mess with the overhead of an IDE or its projects structure. In such cases, for reading files and making minor edits to well-understood files, I can work more quickly with vi than I can even with the best IDE. In addition, vi is on essentially any Linux or Unix machine I might find myself developing on. Vim and other vi derivatives have added numerous new features to those originally offered by vi to make it even easier to use. Although I am not an emacs user, emacs can provide similar advantages as vi and I know many developers who have emacs as their old faithful text editor.

Some Favorite vi Commands
• Use of period to repeat the last command repeatedly.
• Number before yy to yank that number of lines and p to place them.
• Number before dd to delete that number of lines.
• :x to save and exit (rather than :wq)
• :n where n is a line number to go immediately to that line number
• /expression to search for 'expression' and then n to 'next' searched for expression
• :%s/thingToReplace/ThingtoReplaceWith/g (global search and replace)

Some of vi’s advantages can be experienced in IDEs by learning that particular IDE’s keyboard shortcuts, but I have used vi for so many years that its commands that I most frequently use are old familiar friends.


Basic HTML

I move between development of web applications and development of desktop applications frequently. However, I have found basic HTML skills to be very useful even when developing applications without absolutely no web component and even when developing Flex-based or OpenLaszlo-based web applications when relatively little HTML is required.

The reason that I have found HTML to be so useful in any type of development has largely to do with the pervasiveness of the web browser in daily life and in development life. Understanding basic HTML allows one greater flexibility in the customization of common development communication aids like Wiki pages, blogs, and static web pages. Knowledge of HTML can lead to more effective Javadoc comments because Javadoc is designed with web browsers in mind and renders HTML in the generated documentation. HTML is even used in non-HTML components in Java, Flex, and OpenLaszlo.

Favorite HTML Tips in Non-Web Development
• <ul><li></li></ul> or <ol><li></li></ol> for bulleted and numbered lists respectively, especially in Javadoc comments.
• <span style=”css style goes here”></span> in Javadoc comments, in Wiki pages, and other communication devices to provide easily modifiable CSS support.
• Decorative tags (when too lazy to use CSS stylization) like <strong> and <emphasis>
• "title" attribute to easily apply hover-over comments

I'll sometimes use HTML in these uses outside of actual web applications that I would never dream of using in a "real" web application because in such cases, complete adherence to strict (X)HTML and CSS standards is unnecessary and reduces the efficiency benefits I'm striving for in these uses.


Basic Java Tools: javac and jar

With the prevalence of IDEs and sophisticated build tools like Ant and Maven, it is easy to go quite a while without using the javac and jar commands. However, I have found knowledge of direct use of these to be useful in many situations. Just as vi is present on virtually every Linux and Unix machine, javac and jar will be on any machine configured with a Java SDK even if an IDE or build tool has not been installed. There are times when a proficient user of jar can view and manipulate contents of a JAR file quicker than using any tool or IDE. Of course, I prefer to have an Ant build.xml file for repetitive tasks, but for tasks that I only need to do once, it is often quicker to just use jar directly.

The jps command is one that is not quite as old as some of the other tools listed here, but is increasingly winning me over as an old friend. I have also used JAR to unzip a zipped file on a machine on which I was unable to find a tool specifically for unzipping files (usually on an older Windows box because Unix/Linux boxes usually have unzip).



SQL*Plus

For many years, SQL*Plus was the standard method of viewing and manipulating Oracle database schema contents. For a more sophisticated experience, users tended to use products offered by third party companies such as Quest Software. Today, there are numerous options for viewing an Oracle database schema and manipulating its contents graphically and many of these are offered by Oracle. Example of this are the widely popular SQLDeveloper tool and the SQL Worksheet. In addition, Java IDEs support significant database interaction via JDBC drivers.

Although these new tools are all easier to use than SQL*Plus in most cases, there are still times when I go to SQL*Plus for “quick and dirty” queries and operations. This can be especially quick if I have pre-written SQL scripts that I can execute with the @ sign. In fact, for most of my presentations and demonstrations, I write SQL scripts to create and clean up my schemas and run these from SQL*Plus when needed. SQL*Plus knowledge is especially useful when one wants to maintain the database schema with scripts. SQL*Plus can be used by a script to manipulate the Oracle database.

Favorite SQL*Plus Commands and Tips
• set linesize XXXX to set the linesize to number of characters different than 80
• set null <null> to have "" show up for null values rather than empty area
• column some_column_name format some_format to set the viewable format of a particular column in SELECT statements
• host some_command to run a command in the operating system host environment
• ed to edit SQL statements in text editor
• @ and @@ to run SQL*Plus scripts
• select table_name from user_tables; to see list of tables
• select constraint_name from user_constraints where constraint_type = ‘P’ and table_name = ‘SomeTableName’; to see the name of the primary key constraint on a given table
• select u.constraint_name, u.table_name, c.column_name from user_constraints u, user_cons_columns c where u.constraint_type = ‘P’ and u.constraint_name = c.constraint_name and u.table_name = ‘SomeTableName’;

In many ways, the arguments for use of SQL*Plus can be applied to many command-line tool variants of administrative tools that have GUI counterparts. For example, graphical interfaces have made application server administration much easier, but there are still times when the fastest method of administration is via the command-line. As mentioned above, command-line tools also offer the advantage of being executed with scripts.



Paint

In some form or another, the Paint (or MSPaint) application has been included with Windows distributions for as long as I can remember. Combined with the "PrintScreen" button, I find this to be a very handy tool in both development and in writing blogs. It is often helpful when running into problems with fellow developers’ code to send them a screen snapshot indicating the error message or strange behavior exhibited in the application. Even in cases of text output, taking a snapshot can be almost as quick as copy and paste but can provide additional context at the same time.

Some editions of Vista include the Snipping Tool, which makes my use of Paint on a Windows system much less frequent. However, Snipping Tool and other more sophisticated screen capture tools are not always available on all systems, but Paint is on virtually all Windows systems.

Favorite Paint Tips
• Press the Print Screen button to save a snapshot of the Windows desktop to the clipboard.
• Open Paint and select Edit → Paste
• Click on the “Select” icon (dotted square) and then select the region of the pasted-in image you really want.
• Select Edit → Cut
• Select File → New and don’t save the old one
• Select Edit → Paste to paste in the reduced portion selected
• Use Image → Attributes to set hard constraints on height and width of image (these coordinates can be seen by moving cursor to various areas on image)
• Save File with chosen name and preferred format (I typically prefer PNG for development-related screen snapshots)
• Most of these commands have keyboard equivalents

Admittedly, Snipping Tool and other tools require far fewer steps to use than Paint does for this purpose, but basic Paint operations such as those listed above are invaluable when it is your only choice.


top

There are numerous tools available for understanding a system’s CPU and memory usage, but good old top has been a faithful tool for such purposes on Unix and Linux machines for many years.


The Up and Coming Old Faithful Development Tools

The tools I have covered in this blog post have proven their value over many years, in countless different situations and environments, and have steadily provided the assistance I needed from them. So, what tools are likely to join this group? Search engines in general and Google in particular are definitely leading contenders. I think most of us already realize their importance in software development. They have been around a number of years and it could be argued that powerful search engines are already old faithful development tools. Other candidates for old faithful development tools include the mature Java IDEs and VisualStudio and JConsole. VisualVM is a relatively new tool that could very well end up on this list in the near future.


Conclusion

Newer and better development tools are being released continually. However, even with the many benefits and advantages of these new tools, some old tools have repeatedly proven their faithfulness year after year and continue to be faithful and highly useful in the appropriate circumstances. Many of these older tools are "faithful" in the sense that they repeatedly do what is required and they are always or almost always are available when we need them. I have listed some of my favorite of the old faithful development tools here. What tools would be on your list?

ByteOrder: Especially Useful with Groovy Scripts

The Java New I/O (NIO) class ByteOrder can be useful in determining the native byte order (or Endianness) used by the underlying platform. Knowledge of a particular platform's endianness is vital when working with files.

The following simple Java code demonstrates how easy it is to call the static method ByteOrder.nativeOrder() to determine the host platform's byte order.

ReportEndian.java

import java.nio.ByteOrder;

public class ReportEndian
{
   public static void main(final String[] arguments)
   {
      System.out.println("This machine's native byte order is " + ByteOrder.nativeOrder());
   }
}

Running this simple code will generate this output (on the Intel-powered machine I am currently using):



Because Intel processors use Little Endian (see their white paper on this), it is not surprising that the result of calling ByteOrder.nativeOrder is LITTLE_ENDIAN on this machine.

This is another example of where Groovy can be a particularly powerful scripting language. While enjoying scripting language advantages offered by fellow scripting languages such as Ruby, Perl, and Python, Groovy also has access to the Java SDK and to classes like ByteOrder. A script written in Groovy can easily use the Java-provided ByteOrder.nativeOrder() to determine the byte ordering used on the host machine and process accordingly.

The next example shows how easy it is to do this with Groovy. In this case, I won't even bother creating a Groovy file, but will run Groovy command-line with the -e option specifying the simple Groovy code needed to evaluate the native byte order."



In a script that needed to know which endianness the particular host used, this would be a very valuable piece of information.


Conclusion

The JDK has introduced some features such as NIO that embrace platform-specific features through portable interfaces. These features, such as the ByteOrder.nativeOrder() method, can be especially useful when used in conjunction with the Groovy scripting language to write scripts that can take advantage of platform specific efficiencies.