10 Things all Java developers should know

Since Java (I know it’s not an acronym, but it stands out like that) was officially introduced in 1995, it has changed the way most of us look at the Operating System. Bill Gate (how ironic) once said that it was not about the hardware but the software which will be the future. A decade or more later, the fifth employee of SUN, John Gage said “The Network is the Computer”. Fast-forwarding to the 21st century and John seemed to be right. Anyway, Java was built not to depend on an Operating System and deployed through the network. Java through its applet technology gave birth to Rich Network Application aka Rich Internet Application (RIA). Java is not perfect; or we would not have various releases and more on the way, but Java has given birth to a wide range of programming language (just Google it to find out more).

Without further ado, I am going to get back to subject. This is a brief article on what I believe that every Java developers should know regardless of their experience. I do not personally believe that someone with 5 years experience is not as good as someone with 10 years experience. We all develop our own methods of working but as a developer you need to stay abreast of your technology. So, here are my top 10 not in order of importance (or?):

  1. Remember the basic of Java language and OOP paradigm.
    Most experience developers seem to forget the theory behind the language. I am not saying that they are not good at their job but can they explain to junior developers why they have used interfaces instead of abstract classes or why implement a pattern over another one? As a programmer, you become very arrogant as you believe that you write the best code but in the real world, people work in teams with different skill set and experiences. It is important that you can backup your actions/ codes. A very simple question such as; when should I use a String object instead of a StringBuilder/ StringBuffer? You might take this question lightly but can you actually tell someone else the difference?
  2. Know your technology stack
    All developers have to know their technology stack. What does it mean? Java is not like other languages; Java has subsets such J2ME and superset such as Java EE. We have our own area of expertise but it is important to know the differences between the various sets of Java. Some basic questions such as the differences between SWING, Applet, Servlets, EJBs and JavaFX will boost your confidence. Most developers do not know how to tweak the JVM and the differences between the JRE and the SDK environment. Do you know why you need the SDK to be installed to run Tomcat but you only need the JRE to run an application?
  3. Experiment with various Java EE framework
    I am not asking you to be an expert in every single Java EE framework but it will make the difference if you are familiar with Spring and EJB. That should actually be the de facto framework that should be on every developers CV. Developers should know the difference between Java EE 5 (soon 6) and Spring. Hibernate is also brilliant and it’s used for data access but all developers should have moved to JPA by now. Hibernate also comply with JPA therefore there is no more excuses.
  4. Know a scripting language
    Java can be heavyweight for some simple tasks which can be implemented using a simple dynamic language such as Python, Perl(?) and others. I would also recommend to developers to learn shell scripting on their target OS.
  5. Know how to develop web services
    The network is the computer, therefore it is important to know the different web services framework available. Data are integrated through web services and opening your services to the “cloud”. SWING developers will probably not develop web services but I am sure that they will be connecting to data through web services clients. Understanding the difference between the standardised SOAP and non-standardised ReST will help you choose which is best to implement your services.
  6. Know how and when to multithread your application
    I have to put that in there. Developers should know when and why to multithread an application, thread inter-communication and monitoring. All developers, junior or not, should know how to write a multi-threaded application.
  7. Database development using JDBC and JPA
    This should be a development law. All developers should know how to write SQL queries and how to create databases. All enterprise applications store data in some sort of relational database systems and it is therefore imperative that this knowledge should be of second nature. Java EE 5 introduced JPA (JDO was there before) but it is not applicable to all situation. Hence, knowing the difference and when to implement one instead of the other is important.
  8. Know a client side scripting language and what is AJAX
    The network is the computer and Internet is the deployment platform. Java EE and its various framework are server side executiong which can put extra “load” on the server. If you are looking to move a cloud based system where the providers charges you per resources used, it might be wise to move some of the execution to the client side. AJAX has been buzzing the scene for the last 3 years and more. This is not a technology but a new way of doing something that already existed. There are numerous Java AJAX framework such as GWT and DWR which makes it easy to develop AJAX based application which are compiled to JavaScript. Developers should also know what is the AJAX theories.
  9. Know your competitors and do not take part on “what is the best IDE” discussion
    Java is not the only language that can do what it does. I think that Java is more mature and complete as opposed to other languages. Knowing the difference between Java and .NET or Java and Ruby is a good asset to have. You also need to know when and why to use one instead of the other. Please please please, do not get into “my IDE is better than x because…” discussion as it is good for the Java community to have multiple IDEs and framework available to use. Every tools have their place as for example JDeveloper is better than x if you are going to solely develop on an Oracle stack and etc…
  10. Know ANT (MAVEN?), TOMCAT and any other mainstrean application server
    ANT is the de facto build script for Java and its IDE-based development. Maven is becoming popular and soon can be as popular as ANT (not sure of its popularity in the financial sector). TOMCAT  should be immortalised as the based servlet container that all developers should be familiar with.

There are alot more to add but this is just some of the basics that I think all developers should have in their repertoire. Feel free to add to this list in the comments box. If I could had another one to this, would be; all developers not just Java, should know how to search the web and Google is your best friends (now support my advertisers by clicking on the links on the right 😉 ). I hope you enjoyed the entry and feel free to comments good or bad!!! are welcome.

PHP vs Ruby vs JAVA for web applications, part 1

This is not a thorough comparison of the languages per se. I was recently contracted as web application consultant for a start-up company. My role was to make a recommendation of which out of PHP, Ruby or JAVA would be more suitable for web applications development. For contractual reason, the web application and its requirements will not be discussed.
When comparing PHP and Ruby against JAVA, their technology evangelists usually make the following point:

PHP and Ruby are dynamic languages compare to JAVA static type feature. So our first debate here will be about; which one is better, static or dynamic language?

Static typing

A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Examples of languages that use static typing include Ada, C, C++, C#, Java, Fortran, ML, Pascal, and Haskell. Static typing is a limited form of program verification (see type safety): accordingly, it allows many errors to be caught early in the development cycle. Program execution may also be made more efficient (i.e. faster or taking reduced memory).

Because they evaluate type information during compilation, and therefore lack type information that is only available at run-time, static type checkers are conservative. They will reject some programs that may be well-behaved at run-time, but that cannot be statically determined to be well-typed. For example, even if an expression <complex test> always evaluates to true at run-time, a program containing the code

if <complex test> then 42 else <type error>

will be rejected as ill-typed, because a static analysis cannot determine that the else branch won’t be taken.

Some statically typed languages have a “loophole” in the programming language specification that enables programmers to write pieces of code that circumvent the default verification performed by a static type checker. For example, Java and most C-style languages have type conversion; such operations may be unsafe at runtime, in that they can cause unwanted behavior due to incorrect typing of values when the program runs.

Dynamic typing

A programming language is said to be dynamically typed, or just ‘dynamic’, when the majority of its type checking is performed at run-time as opposed to at compile-time. Examples of languages that are dynamically typed include Clojure, Groovy, JavaScript, Lisp, Objective-C, Perl, PHP, Prolog, Python, Ruby, and Smalltalk. Dynamic typing can be more flexible than static typing (for example by allowing programs to generate types based on run-time data), since static type checkers may conservatively reject programs that actually have acceptable run-time behaviour.The cost of this additional flexibility is fewer a priori guarantees, since static type checking ensures that type errors will not occur in any possible execution of a program.

Dynamically-typed language systems, compared to their statically-typed cousins, make fewer “compile-time” checks on the source code (but will check, for example, that the program is syntactically correct). Run-time checks can potentially be more sophisticated, since they can use dynamic information as well as any information that was present during compilation. On the other hand, runtime checks only assert that conditions hold in a particular execution of the program, and these checks are repeated for every execution of the program. Static type checkers evaluate only the type information that can be determined at compile time, but are able to verify that the checked conditions hold for all possible executions of the program, which eliminates the need to repeat type checks every time the program is executed.

Development in dynamically-typed languages is often supported by programming practices such as unit testing. Testing is a key practice in professional software development, and is particularly important in dynamically-typed languages. In practice, the testing done to ensure correct program operation can detect a much wider range of errors than static type-checking, but conversely cannot search as comprehensively for the errors that both testing and static type checking are able to detect. Testing can be incorporated into the software build cycle, in which case it can be thought of as a “compile-time” check, in that the program user will not have to manually run such tests.

Static and dynamic type checking in practice

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently-typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.[2]

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically-typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically-typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically-typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and C#3.0), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible (however, the typing within that evaluated code might remain static). Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing). Recent enhancements to statically typed languages (e.g. Haskell Generalized algebraic data types) have allowed eval functions to be written in a type-safe way.[3]

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++
templates are typically more cumbersome to write than the equivalent Ruby or Python code. More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically-typed languages.

Static typing expands the possibilities for programmatic refactoring. For example, in a statically typed language, analysis of the source code can reveal all callers of a method, and hence a tool can consistently rename the method throughout all of its uses. In dynamic languages, this kind of analysis is either impossible or more difficult because the reference of a name (e.g. a method name) cannot surely be determined until runtime.

It is hard to say which one of the “types” scores more than the other without considering the business context where they will be applied. Much of my development experiences are on large scale enterprise applications, mainly for the finance and telecoms industry. I understand that it is not because of languages, such as JAVA, are statically type that they will end up having fewer bugs. These are part of the reason behind frameworks such as JUnit and Test Driven Development methodologies. When developing critical applications such as online banking system, it is important to rid of minor errors during compilation time then having to write a unit test for that purpose. Unit tests should be focused on application and business logic’s functions test. An example of testing would be to make sure that a customer shall not be able to transfer funds if his accounts balance is less than the amount being transferred.
Dynamic type has its advantages. Let’s take JavaScript as an example, if all you needed was to develop a mortgage calculator program for the web application, then writing it in dynamic language would make perfect sense. This type of application would take less time to write (in terms of line of code) by an experienced Ruby/ PHP developer than, let’s say, in JAVA. Also for the pure fact that JAVA has the abilities of integrating various scripting languages makes a perfect fit for enterprise development. With JRuby, a JAVA developer can integrate Ruby with JAVA by leveraging their current technology investment.
I will a give a thumb-up to JAVA against Ruby. The compiler’s check on object types saves me time on not writing my own type-check. Compiling increases application performances but avoiding checking for types during runtime but the possibilities of getting some type exceptions still exists such as downcasting errors. Overall, JAVA has matured much faster and became a standard in its own. The language specification is constantly being ameliorated and the features implemented are almost second to none compared to Ruby and PHP.

In part2, I will discuss developer productivity and application scalability (+security).