REST/ROA - UNIX File System

I have been trying to understand the differences between REST and ROA. It seems they are useful only when they are coupled together. Specifically, they complement each other in terms the ground rules they lay down!!

REST advocates uniform interface for the system. ROA divides the entire system into resources. Everything in the system is a resource and accessed using a similar interface.

The following idea might be a little far-fetched or I might be completely wrong in understanding ROA/REST and UNIX file system!!

REST/ROA concepts might be new to enterprise application design. However, I feel such concepts have been in use in system design; though they are not referred to by the same name.

I feel UNIX file system is a good example of application of REST/ROA principles. Everything in the file system is a file any device, hard disk, console etc. are considered as files. So in the file system, file is the resource and access/usage to this resource is consistent across. Most of the operations that can be performed with a regular file can be done with any type of file.

Variadic Macros - Quite Cool!!

For the past few days, I have been doing C/CUDA based development. A good break from the the regular Java programming.

CUDA does not support printf function in non-device emulation mode. During development we used to switch between emulation and non-emulation mode frequently. The switch was done using a compile time flag.

We needed a way to remove the all the printf calls in non-emulation mode and have them execute in the emulation mode. The solution was to use Variadic Macro (Thanks to my friend who found the existence of such a macro).

Finally our solution was:

#ifdef EMU
int log(char*msg, ...) {

    va_list args;
    va_start(args, msg);
    return vprintf(msg, args);

}
#else
#define log(msg, ...)
#endif

We used the log variadic macro in our code. Nice learning!!

Easy Mock 2.3 on J2SE 1.4

Easy Mock 2.x versions provide better API than Easy Mock 1.x versions. But the 2.x versions do not run on J2SE 1.4 versions.

My current project uses J2SE 1.4. So i had no option but to use Easy Mock 1.2 for testing. Over a weekend i decided to port Easy Mock 2.3 onto J2SE 1.4.

I have successfully ported EasyMock 2.3 onto J2SE 1.4. I have also added a new EasyMockTestCase to compensate for the lack of static imports in Java 1.4.

I have hosted the ported code on http://code.google.com/p/easymock23onjdk14/

Oracle XE "Processes" Parameter

Oracle XE is an excellent lightweight substitute for the real Oracle database during development. A good database to run on every developer machine.

One of the common issues with XE is that the connection refused exceptions generated when a project test suite consisting of significant number of database tests is run. This is also true for any database intensive, connection pool application running on Oracle XE.

This is primarily due to the XE initialization parameter "processes".

Following is the definition of this parameter as mentioned in the Oracle documentation.

Specifying the Maximum Number of Processes

The PROCESSES initialization parameter determines the maximum number of operating system processes that can be connected to Oracle Database concurrently. The value of this parameter must be a minimum of one for each background process plus one for each user process. The number of background processes will vary according the database features that you are using. For example, if you are using Advanced Queuing or the file mapping feature, you will have additional background processes. If you are using Automatic Storage Management, then add three additional processes.

In short the "processes" parameter controls the maximum number of concurrent connections to the database. By default this is set to 50. Increasing this parameter will help in resolution of the "connection refused" issue mentioned above.

Following are the steps to change the parameter.

1. Connect to the database
sqlplus sys as sysdba

2. See the value of the process parameter
show parameter processes

Sample Output

NAME                         TYPE     VALUE
------------------------------------ -----------
aq_tm_processes              integer     0
db_writer_processes          integer     1
gcs_server_processes         integer     0
job_queue_processes          integer     4
log_archive_max_processes    integer     2
processes                    integer     50

3. Change the parameter
alter system set processes=500 scope=spfile
500 is a sample value, set it to any appropriate value. spfile represents the server parameters file.

4. Shutdown the database
shutdown immediate

5. Start the database
startup

6. Look at the parameters.
show parameter processes

The processes parameter should have changed to the new value.

Now running the test suite or any database intense application would not cause the connection refused error to be generated.

try THE catch IN finally

As widely known the finally clause of Java has be implemented as a mini-subroutine. The subrountine is within the bytecodes of the method containing the finally clause.

The jsr instruction cause a local jump to the sub-routine code and ret instruction cause a return from the sub-routine.

A very interesting impact of this implementation can be seen below.

public int getNum()
{
int i=2;
 
try
{
   return i;
}
finally
{
   i=3;
}
 
}

The return value of the above method is always 2 not 3. The value change in the finally clause doesn't impact the return value.

The reason behind such a behaviour is as follows.

The finally clause is executed prior to the return statement as expected. Before jumping to the code in finally clause, the return value is popped off from the stack and stored in a local variable. The reason for this action is that in Java finally clause can to also place another return value on the stack, can be through a return statement in finally itself.

So the value of i which is 2 is popped-off the stack and stored in a local variable. During the execution of the finally clause the value of i is altered to 3. The finally clause finishes execution and the control is transferred back to the return statement.

~*~Now the return statement uses the stored value as the return value of the method. The return statement is not evaluated again, implies i is not evaluated again, so the change made to i in the finally clause is ineffective.~*~

The change can be made effective only by explicitly adding a return statement to return the value of i in the finally clause.

Java Code Quality for Programmers- Tools for the trade

Ensuring code quality is an herculean task in J2EE/Java projects today. Fortunately,a lot of tools that help in improving the quality of the Java language code are available as free and open source software. Using these set tools make the code developed conformant to the standards right from the outset of the development phase.


Following is a one such list of usage of different tools to improve the Java code quality that I use in my projects:

1. IDE customization: This constitutes the first line of defense. All the developer IDE must be configured with the same rules for Java code and documentation. Be it Eclipse, Netbeans or Rational Application Developer. This ensures that the code is formatted in similar manner across IDEs and the entire code base is coherent. Further, the IDEs provide a 'Format' option that would automatically format the whole code to the specification provided. This step removes almost all developer 'coding standard' errors.


2.CheckStyle(http://checkstyle.sourceforge.net/): Checkstyle performs a detailed check of code conformance with Java Coding Standards. The tool also points out common functional errors made by programmers. A Checkstyle configuration file customized for the current project coding standards should be created and distributed to the team. This is a better way of communicating the project coding guidelines than a verbal discourse or a huge MS Word/PDF document.Checkstyle plug-ins are available for almost all the popular IDEs. The project Checkstyle configuration can be fed to the IDE plug-in so that any non-conformance is immediately highlighted to the developer in the code. This ensures the code developed is in line with the project coding standards.

3. FindBugs(http://findbugs.sourceforge.net/): FindBugs inspects the Java byte code for bug patterns. Running FindBugs on the code developed reveals a set of issues, majority of runtime bugs, that cannot be caught by the source code analysis tools. Again plug-ins are available for popular IDEs.


Note: Checkstyle and FindBugs can be used without an IDE. The IDE integration is a just an option and left to the discretion of the developer.

Once the above steps/tools have been performed on the code by the developer. The code is ready for the review phase.

Usage of such tools by developers, provide them with a lot of learning about the standards, do's and don'ts of Java programming. These tools free the reviewers from delving into code level laborious issues like documentation, indentation etc, which are best done with automated tools. The reviewer can use the same tools or tools like PMD(http://pmd.sourceforge.net/) and JNCSS(http://www.kclee.de/clemens/java/javancss/) to determine design issues, code complexity.etc.