ten commandments for Java programmers

There are many standards and best practices for Java Developers out there. The article 10 Commandments for Java Developers outlines ten most basic rules that every developer must adhere to and the disastrous outcomes that can follow if these rules are not followed. Briefly summarizing the 10 commandments:

    1. Add comments to your code. – It is true comments do not literally contribute to the functionality of a program. But time and time again you return to the code that you wrote two weeks ago and, for the life of you, you cannot remember what it does!
    2. Do not complicate things. – Developers tend to come up with complicated solutions for the simplest problems. We introduce EJBs into applications that have five users. We implement frameworks that an application just does not need. We add property files, object-oriented solutions, and threads to the application that do not require such things. For those who do not know any better, I recommend reaching out to the more experienced programmers for advice.
    3. Keep in Mind – “Less is more” is not always better. – Code efficiency is a great thing, but in many situations writing fewer lines of code does not improve the efficiency of that code.
    4. No hard coding, please. – Developers often forget or omit this rule on purpose because we are, as usual, crunched for time. But maybe if we had followed this rule, we would not have ended up in the situation that we are in. How long does it take to write one extra line of code that defines a static final variable?
    5. Do not invent your own frameworks. – There are literally thousands of frameworks out there and most of them are open-source. Many of these frameworks are superb solutions that have been used in thousands of applications. We need to keep up to date with the new frameworks, at least superficially. One of the best and most obvious examples of a superb widely used framework is Struts. This open source web framework is a perfect candidate to be used in web-based applications.
    6. Say no to Print lines and String Concatenations. – I know that for debugging purposes, developers like to add System.out.println everywhere we see fit. And we say to ourselves that we will delete these later. But we often forget to delete these lines of code or we do not want to delete them.
    7. Pay attention to the GUI. – No matter how absurd it sounds; I repeatedly observe that GUI is as important to the business clients as functionality and performance. The GUI is an essential part of a successful application. Very often IT management tends to overlook the importance of GUI. Many organizations save money by not hiring web designers who have experience in design of “user-friendly” applications. Java developers have to rely on their own HTML skills and their limited knowledge in this area.
    8. Always Prepare Document Requirements. – Every business requirement must be documented. This could be true in some fairy tale, but it is far from that in the real world. No matter how time-pressed your development is, no matter how tight the deadlines, you must always make sure that every business requirement is documented.
    9. Unit-test. Unit-test. Unit-test. – I am not going to go into any details as to what is the best way to unit-test your code. I am just going to say that that it must be done. This is the most basic rule of programming. This is one rule that, above all, cannot be omitted. It would be great if your fellow developer could create and execute a test plan for your code, but if that is not possible, you must do it yourself. When creating a unit test plan, follow these basic rules:
      1. Write the unit test before writing code for the class it tests.
      2. Capture code comments in unit tests.
      3. Test all the public methods that perform an “interesting” function (that is, not getters and setters, unless they do their getting and setting in some unique way).
    10. Remember – quality, not quantity. – Do not stay late (when you do not have to). I understand that sometimes production problems, urgent deadlines, and unexpected events might prevent us from leaving work on time. But, managers do not appreciate and reward their employees because they stay late on regular basis, they appreciate them because they do quality work. If you follow the rules that I outline above, you will find yourself producing less buggy and more maintainable code. That is the most important part of your job.

 

Advertisements

TIOBE Programming Community Index

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.

Since there are many questions about the way the TIOBE index is assembled, a special page is devoted to its definition.

The ratings are calculated by counting hits of the most popular search engines. The search query is executed for the regular Google, Google Blogs, MSN, Yahoo!, and YouTube web search for the last 12 months. The web site Alexa.com has been used to determine the most popular search engines.

The number of hits determine the ratings of a language. The counted hits are normalized for each search engine for the first 50 languages.

Besides the rating of programming languages, there is also a status indicated in the TIOBE chart. Programming languages that have status “A” are considered to be mainstream languages. Status “A-” and “A–” indicate that a programming language is between status “A” and “B”. If a programming language has a rating that is higher than 0.7% (yes, this number is arguable but we had to fix it somewhere) for at least 3 months it is rewarded status “A”. The first two months the programming language will receive status “A–” and “A-” respectively. The opposite holds for languages that go from status “A” to status “B”. So if a language had status “A” 2 months ago, a rating of “0.607%” last month and a rating of “0.687%” now, it will have status “A–“.

Programming languages that are very similar are grouped together. Currently the maximum of the hits of the individual languages is taken into account when calculating the ratings of groupings. In the future we will do a better job and take the union (from mathematical set theory) of all the hits.

The long term trends for the top 10 programming languages can be found in the line diagram below.

No wonder Java tops the ranking. And it will continue to hold that position for some time to come. What I am surprised to see there was Pascal is gaining popularity and people are using it nowadays. You can see the list of top 50 languages here.

Which is the Hottest Java Web Framework?

The “Break it Down” Blog has a lengthy post on Which is the Hottest Java Web Framework? Or Maybe Not Java? Comparing Java Web Frameworks is hard because so many people are passionate about the framework they know best. Add a couple more like Flex and Ruby on Rails and its downright difficult. Nevertheless, this post is good in that it contains a lot of pretty trend graphs and it looks like the author has done some good research. It’s likely the folks that will scream foul are the ones that did poor in the comparison (Tapestry and Stripes, I’m talking about you).

 

 

Surprising among the top Java Web Frameworks is the rise of Struts 2.

Which is much more interesting I think is how Wicket adoption has stayed almost flat while Struts 2 adoption has spiked. Spring MVC/WebFlow seems to be going no where fast and racing JBoss Seam there.The popularity of Struts 2 really caught me off guard with it being quite a bit different from Struts 1, I figured it got thrown into the “just another web framework” category, but I guess there is something in a name and it’s doing quite well.  
Regardless of what you think of the post and trends, you have to appreciate the amount of time the author put into it.

 

 

Java Launcher

Java Launcher is a powerful Java tool which can run java applications and applets by double-clicking class files in explorer as if they are normal windows executable files.

Java Launcher includes nine features totally. Six features in Windows explorer: Run Java applications and applets by double-clicking class files; view class source codes and class hierarchies in graphic format by right-clicking; display contents of jar and zip files without extracting them by right-clicking and allow to save selected files from jar or zip to disk; compile thousands of Java files by right-clicking, execute and debug thousands of applications and applets by right-clicking. Two features of creating: create Windows EXE files from Java applications with user icons, arguments of Java main method, system and user classpaths; create executable JAR files. Last feature is named Java-Help-System, which can auto generate an advanced Help System for J2SE documentations without spending user’s any time and energy.

Click here to know more

Java 6u10 with many features

Java Kernel

Java Kernel is a new distribution aimed at getting Java software up and running faster. Instead of a full JRE, users download a small installer (the “kernel”) which includes the most commonly needed JRE components. Additional components are downloaded as needed, and the JRE will download remaining components in the background and then reassemble itself.

More information about Java Kernel can be found in the 6u10 FAQ.

Java Plug-in

Java SE 6u10 includes a brand-new implementation of the Java Plug-in, which is used by default as long as you are using Firefox 3 or Internet Explorer. The next-generation plug-in runs applets outside of the browser in one or more separate processes. Applets still appear inside of the web browser window as they always have, but this means that it is now possible to use different JRE versions, command-line arguments, and configurations to run different applets. The isolation provided by running the web browser and the JRE — two very large, very complex pieces of software — in separate process spaces improves the reliability of both, and gives applets the same flexibility and control over JRE configurations that other Java software has always enjoyed.

New Plug-In Advantages:

  • Improved reliability
  • Improved JavaScript communication
  • Per-applet control of JRE command-line arguments
  • Per-applet control of JRE memory settings, larger maximum heaps
  • JNLP support
  • Per-applet JRE version selection
  • Improved Vista support

Much more information about the new plug-in can be found in the release notes.

Java Deployment Toolkit

The Java Deployment Toolkit makes deploying Java applets or Java Web Start programs a snap. The Deployment Toolkit JavaScript file provides:

  • Accurate detection of installed JREs
  • Seamless JRE installation
  • Complete applet launching (JRE detection and, if necessary, upgrading) in a single line of code
  • Complete Web Start program launching in a single line of code

The following HTML code is all it takes to ensure that Java 1.6 is installed and then a Java applet is launched:

<script src="http://java.com/js/deployJava.js"></script>
    
<script>
  deployJava.runApplet({codebase:"http://www.example.com/applets/",
     archive:"ExampleApplet.jar", code:"Main.class",
     width:"320", Height:"400"}, null, "1.6");
</script>

More documentation about the deployment toolkit can be found here.

Nimbus Look and Feel

Metal look and feel for Swing was the only competition for the Windows 95 interface in Java. Given the state of graphical user interfaces a decade ago, Metal was an attractive and elegant alternative to the other common interfaces of the time.

The updated Ocean theme in Java SE 5 helped to keep Metal a viable choice up to the present day, but it’s time for Swing’s cross-platform look and feel to get an overhaul.

Enter the Nimbus Look and Feel. A brand new, modern look and feel based on Synth, Nimbus provides a polished look to applications which choose to use it. And because Nimbus is drawn entirely using Java 2D vector graphics, rather than static bitmaps, it’s tiny (only 56KB!) and can be rendered at arbitrary resolutions.

Swing in Metal

Swing in Nimbus

For compatibility reasons, Metal is still the default Swing look and feel, but updating applications to use Nimbus couldn’t be simpler. It only takes a single line of code:

UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");

You can also force Nimbus to be the default look and feel by specifying -Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel on the command line. A more permanent way to set the property is to add

swing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel

to the file <JAVA_HOME>/lib/swing.properties. You will have to create the swing.properties file if it does not already exist.

For further reading about Nimbus, take a look at the Nimbus early access page.

Just-in-time compilation

In computing, just-in-time compilation (JIT), also known as dynamic translation, is a technique for improving the runtime performance of a computer program. JIT builds upon two earlier ideas in run-time environments: bytecode compilation and dynamic compilation. It converts code at runtime prior to executing it natively, for example bytecode into native machine code. The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language). It also has advantages over statically compiling the code at development time, as it can recompile the code if this is found to be advantageous, and may be able to enforce security guarantees. Thus JIT can combine some of the advantages of interpretation and static compilation.

Several modern runtime environments, such as Microsoft‘s .NET Framework and most implementations of Java and most recently Actionscript 3, rely on JIT compilation for high-speed code execution.

In a bytecode-compiled system, source code is translated to an intermediate representation known as bytecode. Bytecode is not the machine code for any particular computer, and may be portable among computer architectures. The bytecode may then be interpreted, or run, on a virtual machine. A just-in-time compiler can be used as a way to speed up execution of bytecode. At the time the bytecode is run, the just-in-time compiler will compile some or all of it to native machine code for better performance. This can be done per-file, per-function or even on any arbitrary code fragment; the code can be compiled when it is about to be executed (hence the name “just-in-time”).

In contrast, a traditional interpreted virtual machine will simply interpret the bytecode, generally with much lower performance. Some interpreters even interpret source code, without the step of first compiling to bytecode, with even worse performance. Statically compiled code or native code is compiled prior to deployment. A dynamic compilation environment is one in which the compiler can be used during execution.

A common goal of using JIT techniques is to reach or surpass the performance of static compilation, while maintaining the advantages of bytecode interpretation: Much of the “heavy lifting” of parsing the original source code and performing basic optimization is often handled at compile time, prior to deployment: compilation from bytecode to machine code is much faster than compiling from source. The deployed bytecode is portable, unlike native code. Since the runtime has control over the compilation, like interpreted bytecode, it can run in a secure sandbox. Compilers from bytecode to machine code are easier to write, because the portable bytecode compiler has already done much of the work.

References

John Aycock, “A brief history of just-in-time”
Wiki, Just-in-time compilation