Pravind's Blog

JQuery : How to add, remove and Validate rows inside a table dynamically using jQuery

2018-02-11T18:26:00.003+05:30

How to add, delete or validate that the row are already added into target html table dynamically. To accomplish this objective I wrote a jqury plugin. The name of the JQuery plugin is - table-jquery.js.

The Html sample file looks like -

<!DOCTYPE html>
<html>
<head>
<script type="text/javascript" src="jquery-3.3.1.js"></script>
<script type="text/javascript" src="table-jquery.js"></script>
<style>
.label{
font-family:Times;
font-weight:bold;
}
</style>
</head>
<body>
<div id="page_body" style="font-family: none;">

<fieldset id="mapping" style="width: 100%;">

<div id="mapping_div" class="smart-forms">

<label for="source" value="Source" class="label">Source:</label>
<select name="source" id="source">
<option value="Source One">Source One</option>
<option value="Source Two">Source Two</option>
<option value="Source Three">Source Three</option>
<option value="Source Four">Source Four</option>
<option value="Source Five">Source Five</option>
<select>

<label for="destination" value="Destination" class="label">Destination: </label>
<select name="destination" id="destination">
<option value="Destination One">Destination One</option>
<option value="Destination Two">Destination Two</option>
<option value="Destination Three">Destination Three</option>
<option value="Destination Four">Destination Four</option>
<option value="Destination Five">Destination Five</option>
</select>

<label for="calculative" value="Calculative" class="label" >Calculative: </label>
<input type="checkbox" name="calculative" id="calculative" checked="checked"> </checkbox>

<input type="button" name="addRow" value="Add Row" id="addRow" />

</div>

</fieldset>

<table id="mapped-table" style="border: 1px solid; width: 100%;">

<thead>
<tr>
<th>SNo</th>
<th>Source</th>
<th>Destination</th>
<th>Calculative</th>
</tr>

</thead>
<tbody style="text-align: center;">

</tbody>
</table>

<button name="deleteRow" value="Delete Row" id="deleteRow">Delete Row</button>
</body>
<script type="text/javascript" src="myjquery.js"></script>
<script>

$(document).ready(function() {
$("#addRow").tableOpration();
} );

</script>
</html>

This is a Jquery plugin (copy and paste it into a javascript file) -

/**
* Add, Delete and validate row using jquery
*
* @Author Pravind Kumar
*/

(function($) {
"use strict";

$.fn.tableOpration = function(element) {

/*
* The Below code is use to add a row into target table dynamically.
* When click event triggered on Add Row button.
*/
$('#addRow')
.click(
function() {
var source = $("#source").val();
var dimension = $("#destination").val();
var calculative = $("#calculative").is(":checked");

if (validate(source)) {
alert("Source attribute already available ... "
+ source);
} else {
var trow = "<tr><td><input type='checkbox' name='record'></td><td>"
+ source
+ "</td><td>"
+ dimension
+ "</td><td>"
+ calculative
+ "</td></tr>";
$("#mapped-table tbody").append(trow);
}

});
/*
* Below code is used to delete the row against the check box checked.
* While adding the row it also add a <td> </td> of checkbox .
*/
$("#deleteRow").click(
function() {
$("#mapped-table tbody").find('input[name="record"]').each(
function() {
if ($(this).is(":checked")) {
$(this).parents("tr").remove();
}
});
});

return this;
};

/*
* Below code is used to validate the row entity and send it back as true or
* false. if table has having the row with same source value then it returns
* true otherwise false.
*/
function validate(newValue) {
var matched = false;
$("#mapped-table > tbody > tr").each(function() {
$(this).find("td:eq(1)").each(function() {
var tdValue = new String($(this).text());
if (tdValue.search(newValue) > -1) {
matched = true;
return false;

}
})
});

return matched;
}

}(jQuery));

Java :: Thread, multiple threading

2013-03-28T17:42:00.000+05:30

Threads are essentially sub processes. Informally, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler. Thread behaves like tasks that belong to a program and that can run "simultaneously". The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process.

Defining, instantiating and starting a Thread –

There are two way to define a thread one is my implementing a Runnable Interface and other is extending Thread class.

1. Implementing Runnable interface –

1.1 Implement java.lang.Runnable interface.

1.2 Implements the run () method.

1.3 Runnable is actually an interface, with the single run () method that we must provide.

1.4 The simple example is as below –

public class ThreadRunnable implements Runnable{

@Override

public void run() {

System.out.println("Thread from Runnable interface.");

}

1.5 The following code would then create a thread and start it running:

ThreadRunnable threadRunnable = new ThreadRunnable ();

new Thread(threadRunnable).start();

2. Extending Thread class –

2.1 Extends java.lang.Thread class.

2.2 Override the run () method.

2.3 The simple example is as below –

public class ThreadFromThread extends Thread{

@Override

public void run() {

System.out.println("Thread from Thread class.");

}

2.4 The following code would then create a thread and start it running-

ThreadFromThread threadFromThread = new ThreadFromThread();

threadFromThread.start();

Every thread has a name for identification purposes. More than one thread may have the same name. If a name is not specified when a thread is created, a new name is generated for it. Some points those should be noted here are –

1. A new thread of execution starts (with a new call stack).

2. The thread moves from the new state to the runnable state.

3. When the thread gets a chance to execute, its target run () method will run.

4. Be sure here that we can start Thread not Runnable.

5. We can call run () method on java.lang.Thread class, but the meaning of this method is that it will use same call stack, instead of creating a new call stack. So the code is valid but the effect is nothing. The meaning of this it will not create a new thread.

Thread life cycle –

Thread has many different states throughout its life. A brief details about that is as below –

1. Newborn state

2. Runnable state

3. Running state

4. Blocked state

5. Dead state

Thread should be in any one state of above and it can be move from one state to another by different methods and ways.

1. Newborn state - When we create a thread it will be in Newborn State. The thread is just created still it is not running. We can move it to running mode by invoking the start () method and it can be killed by using stop () method.

2. Runnable State - It means that thread is now ready for running and its waiting to give control. We can move control to another thread by yield () method.

3. Running State - It means thread is in its execution mode because the control of CPU is given to that particular thread.

4. Blocked State - A thread is called in Blocked State when it is not allowed to entering in Runnable State or Running State. It happens when thread is in waiting mode, suspended or in sleeping mode.

5. Dead State - When a thread is completed executing its run () method the life cycle of that particular thread is end. We can kill thread by invoking stop () method for that particular threads and sends it to be in Dead State.

Java - Way to create an Object

2013-03-28T14:27:00.000+05:30

There are not so many ways in java to create an Object. There are only four way so there is no need to get hectic. The article what deals is a developer point of view. Below are the ways –

1. Using “new” java operator.

2. Using clone () method, that comes with Object class.

3. Using De-serialization (verities about “new” operator).

4. Using “forName ()” (respect with newInstance() and ClassLoder).

Now going details about the object creation way –

1. Using “new” java operator – this is the most commonly way to create an object, I think it’s 95 to 99% of time to use to create an object. Like other operator “new” is a java operator that is used to create an object. This is an operator that requires a constructor operand that is used to initialize a new created instance. This operator is used to allocate the memory space and initialize the fields with their default values and then execute the only operand constructor and execute its instructions and if requires then re-write the instance variables values. For instance –

2. Using clone() method - Clone is a Greek word meaning “branch”, referring to the process whereby a new plant can be created from a twig. In biology it is about copying the DNAs. In java, though clone is ‘intended’ to produce a copy of the same object it is not guaranteed. Clone comes with lots of its and buts. Cloning does not call the “new” operator internally. Objet class’s clone method is a native method which translates into instructions for allocating the memory and copying the data. As I said that clone does not call “new” operator that means there would be some differences between them. As we know that “new” operator does three tasks - allocating the memory, initializing the fields with default values, and calling the specified constructor. But in case of cloning the allocated memory is not initialized with default values and also no constructor is called in this case only a data copy instruction executes which copies the data from the original object to the cloned object. One more thing that I want to say here that even if we override the clone() method either to implement deep cloning or to make the clone method as public 'public' but then also we keep the line super.clone() inside the overridden definition which ultimately calls Object.clone() method only. There are two terms in cloning one is Shallow and deep cloning.

3. Using De-serialization (verities about “new” operator) – this is another way to create an object in java. This internally uses the “new” operator to create an object. Now a question comes in mind that if it calls internally “new” operator then what is the difference from approach 1st? It does use the 'new' operator internally and always calls the default constructor. But two noticeable differences between the two approaches are: - In case of an explicit 'new' call we may specify any constructor which is not the case here. It'll always invoke the default constructor. Another difference is that in this case the newly created object is initialized (or better to say re-written as the implicit 'new' call with default constructor would have already initialized the object first with the default value and then with the specified value in the default constructor) with the data from the Input Stream fetched usually from a persistent medium. This step is obviously not involved in an explicit 'new' call.

4. Using “forName ()” (respect with newInstance() and ClassLoder) - A class can be dynamically loaded using the Class.forName() method. This method has two variants -

1. Class.forName(“ClassName”);

2. Class.forName(“className”, initialize, classLoader);

First one which accepts only a String type parameter which is the qualifies name of the class to be loaded and the other variant expects three parameters - the String type qualifies class name, boolean type flag to specify if the class should be initialized, and the ClassLoader name which should be used to load the class. But the former type also internally calls the three-parameter variant only by assuming the boolean flag as 'true' and the ClassLoader as returned by the getClassLoader() method. That means 'Class.forName("qualified.ClassName")' is internally translated into 'Class.forName("qualifies.ClassName", true, this.getClass().getClassLoader())'. Once the class has been loaded then a call of the method newInstance() on the loaded Class object will first check if the Class object is initialized or not and if not then it will initialize the Class object and create a new object as if the “new” operator has been called with the default constructor of the class under consideration. Again a question round in mind how this is different from an explicit “new” call and it won't take much of an effort to identify the most obvious difference between the two as the inability of this approach to call any other constructor except the default constructor. Another difference is that the newInstance() call may throw a SecurityException as well because it checks if a Security Manager is installed or not and if it finds a security manager then it checks for access to the class as wellas to the package (if any package specified in the qualified name). Either of two checks may throw a SecurityException. This step is obviously not involved with an explicit 'new' call. Another slightly different way of object creation is by using the loadClass() method of the ClassLoader class which returns a Class object of the specified class and then on the returned Class object we may call newInstance() method to create a new object. I've not put this as a completely separate way because I think Class.forName() method also internally calls this method only - either for the explcitly supplied ClassLoader or for the implcitily obtained ClassLoader as discussed above. What's the difference between the two approaches then? The only difference which I can see is that the former checks for the access to the class (and package) and hence it may throw SecurityException if a Security Manager is installed. But the latter doesn't do these checks and hence doesn't throw SecurityException. It's normally advised not to call the loadClass() method directly as almost always you can call Class.forName() by supplying the particular ClassLoader reference.

Java Code Review Techniques

2012-05-11T23:28:00.002+05:30

Code review is a multi steps process that does systematic examination of computer source code. The purpose of this process is to find-fix the short fall of source code and improving the quality of software. The process comes in existing after completing of coding phase in SDLC. But this is not a fix rule it may comes at any time after completing the system. The purpose of code review is –

1. Make system better.

2. Improve developer skill.

3. Easy maintenance.

4. Push system to onwards perfection.

5. Make system error and bug free.

In general term code review is an act that comes after a lot of practice. These days it emerges as a professional domain. And the professionals those are serving for this art is getting a huge amount as his perk.

Code review steps –

1. Preparation step – In this step determines the inspection/review target, inspector role or roles. Reading technique and reading technique specified also included at this stage.

2. Inspection step – in this step inspector looks around the source code with multi perspective view and find out the improvement places and corners according to his/her assigned role. He/she may include some tools to find the defect of code. During the looking process he/she also looks for compilation warning.

3. Rework steps – in inspection step, the work is actually producing output that is input for this step. When inspection steps list out the improvement places and corners actually it prepares the task for rework steps. Rework steps includes –

a. Changing concepts for better performance and maintenance. If the current approach is fine then it may go with this approach, but need to convince to inspector.

b. Methodology improvement.

c. Rework on file arrangement.

d. Make generic concepts in term of system.

4. Follow up – correction verified and reviewer makes sure that new bugs have not been introduced from current change.

Code review roles –

As introduced that code review is an art that comes after a huge practice. On the basis of persons expertise they may assign some roles to complete the code review cycle. The code review roles are –

1. Readers/presenter – the reader explain the product being inspected/reviewed on behalf of business system analyst. The actual flow of the system.

2. Organizer – the organizer develops a plan for development and review. Organizer also defines the time schedule for the complete work. Actually organizer a person who is capable to estimate the time according to its task.

3. Author – is a developer who wrote the code is being reviewed and inspected. In rework phase it is author responsibility to correct the code according to inspector and reviewer. Even, developer thinks the current approach is better than the advised approach he/she may communicate with inspector concerning current and advised approach. Communication must flow with both directions.

4. Recorder – the person is responsible to document the issue and summarize the defects as well the improvement list. He/she also responsible to elaborate the suggestion, the back end technique why he/she is advising such steps.

5. Moderator – the moderator is responsible for leading the review team or group and keeping them focused on their goals. Moderator setups the environment and regulate the discussion to keep review focused. They also manage the time regarding assigned inspector role and task. The responsibility of resource management is also under the moderator.

6. Reviewer/inspector – all members in code review team assumes under this role. The goal to identify the defects and improvement space.

Communication among reviewer team –

Communication should flow in both directions like xylem and phloem. Communication makes the system sound and perfect. So, all team members keep in mind that there should not be any hurdle in the way of communication. But also keep in mind that communication should be relevant, irrelevant communication never be appreciated.

Considerable facts during review process –

1. High level architecture (Recommendation) –

1.1 Modular application – at current time whatever I got the system is high coupled, and I think this is not right approach for development. If possible then we should try to minimize the coupling and optimize the code as a separate module. For instance there is a login module – we should try to make all login related files inside a login module. There is possibility that some common methods, we shall try to make this method generics and keep in common utility package. The best example of modular application is LINUX operating system. The benefits of this approach is –

a. Code becomes good from ugly.

b. Make distribution development.

c. Give developers more flexibility and maintainability.

d. This approach provides the approach to manage the complexity.

e. It increases software quality.

1.2 Upgrade front end framework – at current time it is using struts 1.1 data type definition and 1.0 configuration architecture. Is it possible to update to struts 1.2. If it is possible then we can protect ourselves to carry huge java scripts. We also get some better response time using tiles.

2. Code review dimensions – at current time code review process will focus on some limited dimension. The dimension will cover two angles those are coding and performance (will cover in next blog under the Heading Java performance tuning). Coding will cover all aspect in such a ratio so that it produces better maintainability.

2.1 Coding: - To write everything about the coding standards are possible here. But some common coding guidelines those are must be followed during the code. The best practice for coding are as follows –

2.1.1 Always use java coding standards.

2.1.2 The standard size of java class file should not larger than 1000 lines while a function size should not larger than 400 lines.

2.1.3 The naming convention should camel case, on everywhere. Everywhere means, starting from Html components to java property declaration.

2.1.4 Don’t write extra white space or return (Enter) space on .java files.

2.1.5 Must implements standard logging concepts inside your code.

2.1.6 Must write a standard (according to computer screen size) with of code instruction so that it can viewed at one go. Supposed a screen size is 100^th character wide, then code line should be less than the size, and this process will go all nested instructions.

2.1.7 Never use confusing property or function name, it should be specific to it’s intend task.

2.1.8 Try to write generic function instead of writing duplicate function.

2.1.9 Till not necessary, always avoid synchronized function, block, object, declaration or uses. For example to use Array list is better preferable rather than vector.

2.1.10 Using branching is more preferable then non-branching. Even if single line of control must have a scope with opening and closing braces.

2.1.11 To get details about the java coding convention click here – Java Coding Standards.

2.1.12 During the coding also strictly consider the following points –

OBJECTIVES
DEVIATION
R#	Considering points
R#	Considering points
1.	Does the application follow any design pattern?
2.	Does the code completely follow that/those design pattern?
3.	Is every parameter of any method passing appropriate value or reference?
4.	Does every method return the correct value at every method return point?
5.	If an expression will not fit on a single line then, break it according to the principles in Sun standard.
6.	Does each line contain at most one simple statement?
OMMISSION
7.	Does the code completely implement the design?
8.	Are there any requirements of design that were not implemented?
DEFECT
Class/Interface declaration
9.	Does each class have an appropriate constructor?
10.	Is class name is noun? (it is good to limit the class name max 32 char )
11.	Do any subclasses have common members that should be in the super class?
12.	Does each java source file having one public class or interface?
13.	Does java source have the following ordering: Package and Import statements, beginning comments, Class and Interface declarations?
14.	Can the class inheritance hierarchy be simplified?
Variables and constant declaration
15.	Are descriptive variable and constant names used in accord with naming conventions?
16.	Is every variable correctly typed?
17.	Is every variable properly initialized?
18.	Are all for-loop control variables declared in the loop header?
19.	Are all for-loop moving forward or backward direction?
20.	Are there variables that should be constants?
21.	Are there any unnecessary variable declared inside any scope?
22.	Is instance variables declared publicly?
23.	Is instance variable initialized?
24.	Are arrays should be declared with their brackets next to the type?
25.	Variables should be initialized where they are declared and scope should be smallest. Ensure it?
26.	Are there attributes that should be local variables?
27.	Is variable declaration adherence the java type safe feature?
28.	Do all attributes have appropriate access modifiers (private, protected, public)?
29.	Are there static attributes that should be non-static or vice-versa?
Method declaration/definition
30.	Are descriptive method names used in accord with naming conventions?
31.	Do all methods have appropriate access modifiers (private, protected, public)?
32.	Is every method parameter value checked before being used?
33.	Is exception handled generically inside method?
34.	Is there any open resource?
35.	Is public or protected method document following java doc convention?
36.	Are all scope used object nullify?
37.	Is every method is single task oriented?
38.	Are there static methods that should be non-static or vice-versa?
Data Reference
39.	For every array reference: Is each subscript value within the defined bounds?
40.	For every object or array reference: Is the value certain to be non-null?
Computation/Numeric
41.	Are there any computations with mixed data types?
42.	Is overflow or underflow possible during a computation?
43.	For each expression with more than one operator: Are the assumptions about order of evaluation and precedence correct?
44.	Are parentheses used to avoid ambiguity?
45.	Does the code systematically prevent rounding errors?
46.	Does the code avoid additions and subtractions on numbers with greatly different magnitudes?
47.	Are divisors tested for zero or noise?
Comparison/Relational
48.	Has each Boolean expression been simplified by driving negations inward?
49.	For every Boolean test: Is the correct condition checked?
50.	Are there any comparisons between variables of inconsistent types?
51.	Are the comparison operators correct?
52.	Is each Boolean expression correct?
53.	Are there improper and unnoticed side-effects of a comparison?
54.	Has an "&" inadvertently been interchanged with a "&&" or a "\|" for a "\|\|"?
55.	Does the code avoid comparing floating-point numbers for equality?
56.	Is every three-way branch (less, equal, greater) covered?
Control Flow
57.	For each loop: Is the best choice of looping constructs used?
58.	Will all loops terminate?
59.	When there are multiple exits from a loop, is each exit necessary and handled properly?
60.	Does each switch statement have a default case?
61.	Are missing switch case break statements correct and marked with a comment?
62.	Is the nesting of loops and branches too deep, and is it correct?
63.	Can any nested if statements be converted into a switch statement?
64.	Are null bodied control structures correct and marked with braces or comments?
65.	Does every method terminate?
66.	Are all exceptions handled appropriately?
67.	Do named break statements send control to the right place?
Input/output
68.	Have all files been opened before use?
69.	Are the attributes of the open statement consistent with the use of the file?
70.	Have all files been closed after use?
71.	Is buffered data flushed?
72.	Are there spelling or grammatical errors in any text printed or displayed?
73.	Are error conditions checked?
74.	Are files checked for existence before attempting to access them?
75.	Are all I/O exceptions handled in a reasonable way?
Module Interface
76.	Are the number, order, types, and values of parameters in every method call in agreement with the called method's declaration?
77.	Do the values in units agree (e.g., inches versus yards)?
78.	If an object or array is passed, does it get changed, and changed correctly by the called method?
Comment
79.	Does every method, class, and file have an appropriate header comment?
80.	Does every attribute, variable or constant declaration have a comment?
81.	Is the underlying behavior of each method and class expressed in plain language?
82.	Is the header comment for each method and class consistent with the behavior of the method or class?
83.	Are all comments consistent with the code?
84.	Do the comments help in understanding the code?
85.	Are there enough comments in the code?
86.	Are there too many comments in the code?
Layout and Packing
87.	Is a standard indentation and layout format used consistently?
88.	For each method: Is it no more than about 60 lines long?
89.	For each compile module: Is no more than about 600 lines long?
Modularity
90.	Is there a low level of coupling between modules (methods and classes)?
91.	Is there a high level of cohesion within each module (methods or class)?
92.	Is there repetitive code that could be replaced by a call to a method that provides the behavior of the repetitive code?
93.	Are the Java class libraries used where and when appropriate?
Storage Usage
94.	Are arrays large enough?
95.	Are object and array references set to null once the object or array is no longer needed?
Performance
96.	Can better data structures or more efficient algorithms be used?
97.	Are logical tests arranged such that the often successful and inexpensive tests precede the more pensive and less frequently successful tests?
98.	Can the cost of re-computing a value be reduced by computing it once and storing the results?
99.	Is every result that is computed and stored actually used?
100.	Can a computation be moved outside a loop?
101.	Are there tests within a loop that do not need to be done?
102.	Can a short loop be unrolled?
103.	Are there two loops operating on the same data that can be combined into one?
104.	Are frequently used variables declared register?
105.	Are short and commonly called methods declared inline?
106.	Are timeouts or error traps used for external device accesses?
INCONSISTENCY
Performance
107.	Are there any code implement in inconsistent way?
AMBIGUITY
Variable and Constant Declaration
108.	Are there variables with confusingly similar names?
109.	Are all variables properly defined with meaningful, consistent, and clear names?
Performance
110.	Are any modules excessively complex and should be restructured or split into multiple routines?
REDUNDANCY
Variables
111.	Are there any redundant or unused variables or attributes?
112.	Could any non-local variables be made local?
Method Definition
113.	Are there any uncalled or unneeded methods?
Performance
114.	Can any code be replaced by calls to external reusable objects?
115.	Are there any blocks of repeated code that could be condensed into a single method?
116.	Are there any leftover stubs or test routines in the code?
SIDE-EFFECT
Method Definition
117.	After changing of prototype of method, Have class which calls it considered yet?
Data Base
118.	Do Upgrading and Migration process follow up changing of structures or contents of a project’s data base?

Object Oriented Programming (OOPs)

2012-05-02T18:38:00.001+05:30

Object Oriented Programming (OOPs). –

The basis and foremost discussing topic is - Object Oriented Programming (OOPs). Now a day this concept is getting very popular and bit confusing too. Almost all high level and 4^th generation languages support OOPs. Therefore it becomes mandatory to deal OOPs before switching onto OOPs pillars.

Object Oriented Programming is an abstract concept or programming approach that identifies all physical entity as a basic element of the system i.e. class. In real world if we want to understand the behavior of a system then it becomes mandatory to breakdown that entity on the level of its basic unit. Once the breaking process reaches on the level of atom or basic unit level then sudden a click comes around how anyone can identify this atom or basic unit? An atom is a basic unit of all physical entity that do well individually and holds all it nature properties and behaviors. When more than an atom sits together then it produces an element and when more than one element sit together then it makes compound element … and finally it fulfill the necessity of human life and make it easy. The meaning of these sentence is if want to make a versatile system or even a system then it becomes mandatory to understand its basic element. Similar format is used by the Object Oriented Programming. Here atom is nothing actually it is a specific class that does well individually and by joining other class make a module and by joining multiple module makes a system and in similar way it can produce a large system. If look closely to above paragraph then can say Object Oriented Programming is a programming approach that implements itself in Bottom-up fashion. So to understand Object Oriented programming it is good to see the Bottom-up approach.

Bottom-up - In a bottom-up approach, the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small, but eventually grow in complexity and completeness. It's worth emphasizing that bottom-up design doesn't mean just writing the same program in a different order. When work on bottom-up, it usually ends up with a different program. Instead of a single, monolithic program, it will get a larger language with more abstract operators, and a smaller program written in it.

Bottom-up approach yields programs which are smaller and more agile. A shorter program doesn't have to be divided into so many components, and fewer components means programs which are easier to read or modify. Fewer components also mean fewer connections between components, and thus less chance for errors there. This approach also promotes code re-use. When talk about to write two or more programs, many of the utilities written for the first program will also be useful in the succeeding ones. Because it causes always to be on the lookout for patterns in the code, working bottom-up helps to clarify the ideas about the design of the program.

Hence Object Oriented Programming follows the bottom-up approach so it inherits all the features from. In a single word OOPs is Object Oriented Programming approach that oriented around object and its basic element class. In essential an Object Oriented Programming is a programming if it must supports abstraction (classes and objects), inheritance and polymorphism. It may support other features, but encapsulation, inheritance and polymorphism are the bare minimum. This is the opinion of the man who invented the term. In addition, Bjarne Stroustrup (who designed and implemented the C++ programming language), provides this broad definition of the term "Object Oriented" in section 3 of his paper called Why C++ is not just an Object Oriented Programming Language:

A language or technique is object-oriented if and only if it directly supports:

1. Abstraction - providing some form of classes and objects.

2. Inheritance - providing the ability to build new abstractions out of existing ones.

3. Runtime polymorphism - providing some form of runtime binding.

Later versions of various OO languages have added more features but these features are not the deciding feature which decide if a language is OO or not. It would be like saying that a car is not a car unless it has climate control and satNav. Those are optional extras, not the distinguishing features, and not using them does not make code not OO. It would also be incorrect to say that a car is a car because it has wheels. Having wheels does not make something a car - a pram has wheels, but that does not make it a car, so having wheels is not a distinguishing feature. At this point I want to say that such features like "modularity", "reusability" and "messaging" are not features which distinguish an OO language from a non-OO language, but these features make more clarity for Object Oriented Programming approach. Because java fulfills the Basic and all enhance features of OOPs so it is sound to say that java is a complete Object Oriented Programming language.

Now it is time to understand class and object and after that description will continue on Object Orient pillars.

Class – these are some definition of class –

A class can be defined as template/blue print that describes the behaviors/states that object of its type support.

A class can have member functions, member data, member constants, and member types.

A class is the primary mechanism for representing concepts in java. A class is also called “user defined data type”.

According to sun micro system a class is the blueprint from which individual objects are created.

A class is a collection of fields (data) and methods (procedure or function) that operate on that data.

A class is a group or set (of things or entities) with common characteristics, attributes, qualities or traits and even behaviors. A class is a noun and classes don’t hold any information. A simple example of class in java –

[Accessible modifier] class Shape {

Properties (list of instance variables)

Behaviors (to manage above properties)

}

Object – when a class is created actually it creates a new data type but when object is created for that data type that mean it get physical existence of that class. An object is contiguous region of memory holding a value and state of some type. At run time, when the Java Virtual Machine (JVM) encounters the new keyword, it will use the appropriate class to make an object which is an instance of that class. That object will have its own state, and access to all of the behaviors defined by its class. Each object (instance of a class) will have its own unique set of instance variables as defined in the class. Collectively, the values assigned to an object's instance variables make up the object's state. An object is an instance of a class. A class holds all the properties and functions, while object uses them.

In a brief class is an abstract data type that does not exist physically while object is a real representation of a class that lives physically and present actual visibility of a class.

Now it is time to elaborate the Object Oriented Programming pillars –

According to above description the basic OOPs pillars are –

Abstraction (providing some form of classes and objects) – the ability to represent concepts directly in a program and hide incidental details behind well defined interfaces – is the key to every flexible and comprehensible system of any significant size. In typical words – to retain only information that is relevant for a particular purpose. For example when a car user changes the gear of his/her vehicle is user really concern about the inner details of the vehicle engine? No, but what matter is that gear must get changed that’s it! This is abstraction; show only the details which matter to the user. So abstraction says expose only the details which are concern with the user (client) of object. So the client who is using the class needs not to be aware of the inner details like how class does the operations? User needs to know just few details. This certainly helps in re-usability of the code. Let try to understand this concept in java program, suppose there is a class that interact with database and implements the database Data Manipulation Language (DML) operations like – insert, update, delete etc. Now this is not required to other developer of system to know how it interact to Database and how it manages the DML operations, just extends the class and if required then add some enhancement and performs the message call. Here the systems other developer just know like the car user, only the required information like which parameter is to pass and what will be return value. To get a complete view about abstraction in java look in the following example –

In above example there are two java classes one is a Parts (vehicle) and another is an abstract class name is Vehicle. Vehicle class a top most class for any type of vehicle, and vehicle must have compressor piston and various more parts but for example I am taking here only two parts. As we know abstract class cannot be initialized so to get these hidden implementation need a concrete class. As in following example there is a class HondaCity that is extending Vehicle. This class will return the compressor and piston as its company uses. In similar way every type of company or its brand has its own properties and value. So in abstract class it tried to hide the unnecessary code from developer or end user. This is just an example to understand. For any more clarification please put your query.

At last, abstraction is not hiding the data, its hiding the unnecessary work from the end user.

Encapsulation (providing some form of classes and objects) –

Encapsulation means shielding the Object data inside a class. Shielding means it hides the data from view outside of the object definition. It means only the object’s own methods can directly inspect or manipulate its field. In other words – encapsulation is the concept that insulates data and its operable function inside a single unit (class), by using this technique keeps data safe from outside interfaces and misuse. This is a protective wrapper that prevents the code and data from being arbitrarily accessed by other code defined outside of wrapper. Encapsulation protects data inconsistency and increase robustness by allowing the developer to limit the inter dependencies between software components.

If we want maintainability, flexibility and extensibility then it becomes mandatory to follow the encapsulation features. A java class can call fully encapsulated if it follow these rules –

1. All instance variables must be private (in case of inheritance it can be protected).

2. To play on data, there will be public access method and it forces to call these accessor methods rather than directly accessing the instance variable.

3. For accessor method coding convention must follow the Java Bean naming convention.

The benefit (maintainability, flexibility and extensibility) of encapsulation does not come automatically, to get these features we need to design the code accordingly. This is an example of encapsulation –

Abstraction Vs Encapsulation –

These two concepts are not intercepting any one at any point, I think both are complementary and encapsulation is the next step of abstraction or I can say it makes the abstraction on concrete level. In abstraction often it is called that is hide the unnecessary implementation while encapsulation hide the data as well as implantation (if any changes occurs in implemented section of code, then there is no any side effect found under dependent code – SCJP Exam 310-055 by Kathy Sierra). Abstraction is a steps or process it is act of identifying the relevant qualities and behavior of an object and an object does possess it, this ensure by the encapsulation. for example a user click on menu to save a file, does the user know how it will perform – no; so this is encapsulation hiding the data and implementation from user. Here, Abstraction provides access to a specific part of data while encapsulation hides the data. In short both concepts make OOPs stronger by complementing each other.

Polymorphism –
Polymorphism is the ability of one type ‘A’ to appear as and be used like another type ‘B’. More precisely, it is the ability for different objects to respond to the same message in different ways. Polymorphism types –
1. Overloading polymorphism (dynamic binding)
2. Inclusion polymorphism

Inheritance –
Inheritance is a feature to acquire the characteristics from its parent. The class whose members are inherited is called parent/base class and the class that inherits is called child or derived class. Inheritance is a static binding. Inheritance demonstrate IS-A relation.

Relations –
1.   IS-A Relation (Inheritance)
2.   HAS-A Relations (uses)
3.   Generalization
4.   Composition
      - Association (Has –A)
        - Aggregation

Java Coding Standards

2011-07-04T22:29:00.000+05:30

1. Introduction

The major objective of this document is to provide standards and guidelines for application developers and designers to develop systems that are maintainable, testable, readable and adaptable to changes in the infrastructure. A system depends on its maintenance instead of development, so it becomes mandatory to write code clean and well packaged. Following are some importance reasons to convey the coding standards during coding phase of project life cycle…

1. 80% of the lifetime cost of a piece of software goes to maintenance

2. Hardly any software is maintained for its whole life by the original author.

3. Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

4. If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

1.1 Purpose

This white paper describes a collection of standards, conventions, and guidelines for writing solid Java code. They are based on sound, proven software engineering principles that lead to code that is easy to understand, to maintain, and to enhance. Furthermore, by following these coding standards our productivity as a Java developer should increase remarkably – Experience shows that by taking the time to write high-quality code right from the start we will have a much easier time modifying it during the development process. Finally, following a common set of coding standards leads to greater consistency, making teams of developers significantly more productive.

1.2 Why Coding Standards are Important?

Coding standards for Java are important because they lead to greater consistency within our code and the code of our teammates. It increases code robustness. Greater consistency leads to code that is easier to understand, which in turn means it is easier to develop and to maintain. This reduces the overall cost of the applications that you create.

We have to remember that our Java code will exist for a long time, long after we have moved on to other projects. An important goal during development is to ensure that we can transition our work to another developer, or to another team of developers, so that they can continue to maintain and enhance our work without having to invest an unreasonable effort to understand our code. Code that is difficult to understand runs the risk of being scrapped and rewritten – We wouldn’t be proud of the fact that our code needed to be rewritten? If everyone is doing their own thing then it makes it very difficult to share code between developers, raising the cost of development and maintenance.

New developers, and cowboys who do not know any better, will often fight having to follow standards. They claim they can code faster if they do it their own way. They MIGHT be able to get code out the door faster, but I doubt it. Cowboy programmers get hung up during testing when several difficult-to-find bugs crop up, and when their code needs to be enhanced it often leads to a major rewrite by them because they’re the only ones who understand their code. Is this the way that we want to operate? I think I certainly do not.

1.3 The Prime Directive

No standard is perfect and no standard is applicable to all situations: sometimes we find ourselves in a situation where one or more standards do not apply. This leads me to introduce what I consider to be the prime directive of standards:

When we go against a standard, we must document it. All standards, except for this one, can be broken. If we do so, we must document why we broke the standard, the potential implications of breaking the standard, and any conditions that may/must occur before the standard can be applied to this situation.

The bottom line is that we need to understand each standard, understand when to apply them, and just as importantly when not to apply them.

2. Documentation and Comments

Most ordinary comments within Java code explain the implementation details of that code. In contrast, the Java language specification defines a special type of comment known as a doc comment that serves to document the API of your code. A doc comment is an ordinary multiline comment that begins with /** (instead of the usual /*) and ends with */. A doc comment appears immediately before a class, interface, method, or field definition and contains documentation for that class, interface, method, or field. The documentation can include simple HTML formatting tags and other special keywords that provide additional information. Doc comments are ignored by the compiler, but they can be extracted and automatically turned into online HTML documentation by the javadoc program.

2.1 Good Documentation

We ensure that our code should follow some basics facts about good documentations, these basics facts are –

1. Comments should add to the clarity of the code.

2. If the program isn’t worth documenting, it probably isn’t worth running.

3. Take care about comments - Avoid decoration, i.e. do not use banner-like comments.

4. Comments must be simple.

5. Always prefer to write the documentation before you write the code.

6. Document why something is being done, not just what.

2.2 Types of Comments

Java programs can have two kinds of comments: implementation comments and documentation comments. Implementation comments are those found in C++, which are delimited by /*...*/, and //. Documentation comments (known as "doc comments") are Java-only, and are delimited by /**...*/. Doc comments can be extracted to HTML files using the javadoc tool.

2.2.1 Implantation Comment

Program can have following type of implementation comments –

1. Block

2. Single line

3. Trailing

4. End-of-line

2.2.1.1 Block Comments:-

Block comments are used to provide descriptions of files, methods, data structures and algorithms. Block comments may be used at the beginning of each file and before each method. They can also be used in other places, such as within methods. Block comments inside a function or method should be indented to the same level as the code they describe.

A block comment should be preceded by a blank line to set it apart from the rest of the code.

* Here is a block comment.

Block comments can start with /*-, which is recognized by indent(1) as the beginning of a block comment that should not be reformatted. Example:

/*-

* Here is a block comment with some very special

* formatting that I want indent(1) to ignore.

* one

* two

* three

Note: If we don't use indent(1), we don't have to use /*- in our code or make any other concessions to the possibility that someone else might run indent(1) on our code.

2.2.1.2 Single-Line Comments:-

Short comments can appear on a single line indented to the level of the code that follows. If a comment can't be written in a single line, it should follow the block comment format. A single-line comment should be preceded by a blank line. Here's an example of a single-line comment in Java code:

if (condition) {

/* Handle the condition. */

...

}

2.2.1.3 Trailing Comments :-

Very short comments can appear on the same line as the code they describe, but should be shifted far enough to separate them from the statements. If more than one short comment appears in a chunk of code, they should all be indented to the same tab setting.

Here's an example of a trailing comment in Java code:

if (a == 2) {

return TRUE; /* special case */

} else {

return isPrime(a); /* works only for odd a */

}

2.2.1.4 End-Of-Line Comments:-

The // comment delimiter can comment out a complete line or only a partial line. It shouldn't be used on consecutive multiple lines for text comments; however, it can be used in consecutive multiple lines for commenting out sections of code. Examples of all three styles follow:

if (foo > 1) {

// Do a double-flip.

...

}

else {

return false; // Explain why here.

}

//if (bar > 1) {

// // Do a triple-flip.

// ...

//}

//else {

// return false;

//}

2.2.2 Documentation Comments

Doc comments describe Java classes, interfaces, constructors, methods, and fields. Each doc comment is set inside the comment delimiters /**...*/, with one comment per class, interface, or member. This comment should appear just before the declaration:

/**

* The Example class provides ...

public class Example { ...

Notice that top-level classes and interfaces are not indented, while their members are. The first line of doc comment (/**) for classes and interfaces is not indented; subsequent doc comment lines each have 1 space of indentation (to vertically align the asterisks). Members, including constructors, have 4 spaces for the first doc comment line and 5 spaces thereafter.

If you need to give information about a class, interface, variable, or method that isn't appropriate for documentation, use an implementation block comment or single-line comment immediately after the declaration. For example, details about the implementation of a class should go in such an implementation block comment following the class statement, not in the class doc comment.

Doc comments should not be positioned inside a method or constructor definition block, because Java associates documentation comments with the first declaration after the comment.

2.3 Java Doc Quick Overview

Included in Sun’s Java Development Kit (JDK) is a program called javadoc that processes Java code files and produces external documentation, in the form of HTML files, for your Java programs. I think that javadoc is a great utility, but at the time of this writing it does have its limitations. First, it supports a limited number of tags, reserved words that mark the beginning of a documentation section. The existing tags are a very good start but I feel are not sufficient for adequately documenting your code. I’ll expand upon this statement later. For now, I present a brief overview of the current javadoc tags in the chart below, and will refer you to the JDK javadoc documentation for further details.

Tag	Used for	Purpose
@author name	Interfaces, Classes	Indicates the author(s) of a given piece of code. One tag per author should be used.
@deprecated	Interfaces, Classes, Member Functions.	Indicates that the API for class… has been deprecated and therefore should not be used any more.
@exception name description	Member Functions	Describe the exceptions that a member function throws. We should use one tag per exception and give the full class name for the exception.
@param name description	Member Functions	Used to describe a parameter passed to a member function, including its type/class and its usage. Should use one tag per parameter.
@return description	Member Functions	Describe the return value, if any, of a member function. We should indicate the type/class and the potential use(s) of the return value.
@since	Interfaces, Classes, Member Functions	Indicates how long the item existed, i.e. since Java Development Kit (JDK) 1.1
@see ClassName	Interfaces, Classes, Member Functions, Fields	Generate a Hypertext link in the documentation to the specified class. We can and probably should use a fully qualified class name.
@see ClassName#memberFunctionName	Interfaces, Classes, Member Functions, Fields	Generate a hypertext link in the documentation to the specified member function. We can, and should probably use a fully qualified class name.
@version text	Interfaces, Classes	Indicates the version information for a given piece of code.

The way that we document our code has a huge impact both on our own productivity and on the productivity of everyone else that later maintains and enhances it. By documenting our code early in the development process we become more productive because it forces we to think through our logic before we commit it to code. Furthermore, when we revisit code that we wrote days or weeks earlier we can easily determine what we were thinking when we wrote it – it is documented for we already.

3. Naming Convention

I’m a firm believer in maximizing the productivity of systems professionals. Because I also recognize that an application spends the majority of its existence being maintained, not developed, I am very interested in anything that can help to make my code easier to maintain and to enhance, as well as to develop. Never forget that the code that we write today may still be in use many years from now and will likely be maintained and enhanced by somebody other than I. We must strive to make our code as “clean” and understandable as possible, because these factors make it easier to maintain and to enhance. We will understand naming convention step-by-step in following pattern (this is not mandatory for all sub-heading) …

v Naming conventions

v Visibility

v Documentation conventions

v Techniques for writing clean Java code

3.1 Naming Member Functions

Member Functions should be named using a full English description, using mixed case with the first letter of any non-initial word capitalized. It is good practice to name a method according to its work. It is also common practice for the first word of a member function name to be a strong, active verb. For instance

Ø openMail();

Ø closeMail();

Ø saveMail();

Ø deleteMail();

This convention results in member functions whose purpose can often be determined just by looking at its name. Although this convention results in a little extra typing by the developer, because it often results in longer names, this is more than made up for by the increased understandability of our code.

3.1.1 Naming Accessor Member Functions

We will discuss accessors, member functions that get and set the values of fields (fields/properties). The naming conventions for accessors, however, are summarized below.

3.1.1.1 Getter:-

Getters are member functions that return the value of a field. We should prefix the word ‘get’ to the name of the field, unless it is a boolean field and then we prefix ‘is’ to the name of the field instead of ‘get.’ For Example –

Ø getFirstName();

Ø getAccountNumber();

Ø isPersistent();

By following this naming convention we make it obvious that a member function returns a field of an object, and for boolean getters we make it obvious that it returns true or false. Another advantage of this standard is that it follows the naming conventions used by the beans development kit (BDK) for getter member functions. The main disadvantage is that ‘get’ is superfluous, requiring extra typing.

Alternative Naming Convention for Getters – Has and Can

A viable alternative, based on proper English conventions, is to use the prefix ‘has’ or ‘can’ instead of ‘is’ for boolean getters. For example, getter names such as hasDependents() and canPrint() make a lot of sense when we are reading the code. The problem with this approach is that the BDK will not pick up on this naming strategy (yet).

3.1.1.2 Setters:-

Setters, also known as mutators, are member functions that modify the values of a field. We should prefix the word ‘set’ to the name of the field, regardless of the field type. For example

Ø setFirstName(String name);

Ø setAccount(int accountNumber);

Ø setPersistent(boolean persist);

Following this naming convention we make it obvious that a member function sets the value of a field of an object. Another advantage of this standard is that it follows the naming conventions used by the beans development kit (BDK) for setter member functions. The main disadvantage is that ‘set’ is superfluous, requiring extra typing.

3.1.2 Naming Constructor

Constructors are member functions that perform any necessary initialization when an object is first created. Constructors are always given the same name as their class. For example, a constructor for the class Customer would be Customer(). Note that the same case is used. For instance –

Ø Customer();

Ø Account();

This naming convention is set by Sun and must be strictly adhered to.

3.1.3 Member Function Visibility

For a good design where we minimize the coupling between classes, the general rule of thumb is to be as restrictive as possible when setting the visibility of a member function. If member function doesn’t have to be public then make it protected, and if it doesn’t have to be protected then make it private.

Visibility	Description	Proper Usage
public	A public member function can be invoked by any other member function in any other object or class.	When the member function must be accessible by objects and classes outside of the class hierarchy in which the member function is defined.
protected	A protected member function can be invoked by any member function in the class in which it is defined or any subclasses of that class.	When the member function provides behavior that is needed internally within the class hierarchy but not externally.
private	A private member function can only be invoked by other member functions in the class in which it is defined, but not in the subclasses.	When the member function provides behavior that is specific to the class. Private member functions are often the result of refactoring, also known as reorganizing, the behavior of other member functions within the class to encapsulate one specific behavior.
	No visibility is indicated. This is called default or package visibility, and is sometimes referred to as friendly visibility. The member function is effectively public to all other classes within the same package, but private to classes external to the package.	This is an interesting feature, but be careful with its use. I use it when I’m building domain components, collections of classes that implement a cohesive business concept such as “Customer”, to restrict access to only the classes within the component/package.

3.2 Naming Fields (Attributes/Properties)

Throughout this white paper I will use the term field to refer to an attribute, which the Beans Development Kit (BDK) calls a property. A field is a piece of data that describes an object or class. Fields may be a base data type like a string or a float, or may be an object such as a customer or bank account. To adhere following important lines when declaring fields –

1. Use a full English descriptor for field names: - we should use a full English descriptor to name fields to make it obvious what the field represents. Fields that are collections, such as arrays or vector, should be given names that are plural to indicate that they represents multiple values. For example

Ø employeeName;

Ø employeeId;

2. Acronym should be lower case – if the name of the field begins with an acronym, such as sqlDatabase, then the acronym should be lowercase. For example – sqlDatabase should not write this sQLDatabase.

3. All fields name should be meaningful, and shows that what type of value it will hold.

4. Always avoid abbreviation format for naming a field.

5. Always avoid using java key words as field name.

6. Naming Constant - In Java, constants, values that do not change, are typically implemented as static final fields of classes. The recognized convention is to use full English words, all in uppercase, with underscores between the words. Examples are -

Ø MINIMUM_BALANCE

Ø MAX_VALUE

Ø DEFAULT_START_DATE

The main advantage of this convention is that it helps to distinguish constants from variables. We will see later in the document that we can greatly increase the flexibility and maintainability of our code by not defining constants, instead we should define getter member functions that return the value of constants.

7. Familiar Names – we should use the words that exist in the terminology of the target domain. If our users refer to their clients as customer, then use the name “Customer” for the class not “Client”.

8. Avoid excessively long names – name should be meaningful and descriptive but not excessively long. Max size for this should be up to 25 characters

9. Use descriptive name and do not attempt to shorten names by removing vowels.

10. Don’t use name that differ only in case.

11. Naming Collection – A collection, such as an array or a vector, should be given a pluralized name representing the types of objects stored by an array. The name should be a full English descriptor with the first letter of all non-initial words capitalized. For example –

Ø customers;

Ø orderItems;

The main advantage of this convention is that it helps to distinguish fields that represent multiple values (collections) from those that represent single values (non-collections).

3.3 Naming Local Variables

A local variable is an object or data item that is defined within the scope of a block, often a member function. The scope of a local variable is the block in which it is defined. The important coding standards for local variables focus on:

Ø Naming conventions

In general, local variables are named following the same conventions as used for fields, in other words use full English descriptors with the first letter of any non-initial word in uppercase. For the sake of convenience, however, this naming convention is relaxed for several specific types of local variable:

Ø Streams

Ø Loop counters

Ø Exceptions

3.3.1 Naming Streams

When there is a single input and/or output stream being opened, used, and then closed within a member function the common convention is to use in and out for the names of these streams, respectively. For a stream used for both input and output, the implication is to use the name inOut. A common alternative to this naming convention is to use the names inputStream, outputStream, and ioStream instead of in, out, and inOut respectively. To tell you the truth I like this alternative better, but the fact remains that the names in and out are what Sun suggests, so that’s what you should probably stick with.

3.3.2 Naming Loop Counters

Because loop counters are a very common use for local variables, and because it was acceptable in C/C++, in Java programming the use of i, j, or k, is acceptable for loop counters. If we use these names for loop counters, use them consistently. A common alternative is to use names like loopCounter or simply counter, but the problem with this approach is that we often find names like counter1 and counter2 in member functions that require more than one counter. The bottom line is that i, j, k work as counters, they’re quick to type in, and they’re generally accepted.

A major disadvantage of using single letter names for counters, or for anything, is that when we try to search for its use within a code file we will obtain many false hits – consider the ease of searching for loopCounter over the letter i.

3.3.3 Naming Exception Objects

Because exception handling is also very common in Java coding the use of the letter e for a generic exception is considered acceptable.

3.4 Naming Parameters (Arguments) To Member Functions

The standards that are important for parameters/arguments to member functions focus on how they are named and how they are documented. Throughout this white paper I will use the term parameter to refer to a member function argument.

Parameters should be named following the exact same conventions as for local variables. As with local variables, name hiding is an issue (if you aren’t using accessors). Some examples are –

Ø customer

Ø inventoryItem

Ø in

Ø e

3.4.1 Name Parameters the Same as their Corresponding Fields (if any)

An alternative is to name parameters that align to an existing field with the same name as the existing field. For example, if Account has an attribute called balance and we needed to pass a parameter representing a new value for it the parameter would be called balance. The field would be referred to as this.balance in the code and the parameter would be referred to as balance (we could also invoke the appropriate accessor method). The disadvantage of this approach is name hiding problem and it is easy to forget to use “this” object. But I my view it is good approach, if developer shows own maturity.

3.5 Naming Classes, Interfaces, Packages, and Compilation Units

This unit concentrates on standards and guidelines for classes, interfaces, packages, and compilation units. A class is a template from which objects are instantiated (created). Classes contain the declaration of fields and member functions. Interfaces are the definition of a common signature, including both member functions and fields, which a class that implements an interface must support. A package is a collection of related classes. Finally, a compilation unit is a source code file in which classes and interfaces are declared. Because Java allows compilation units to be stored in a database, an individual compilation unit may not directly relate to a physical source code file.

3.5.1 Standards for Classes

The standards that are important for classes are based on:

3.5.1.1 Naming convention: –

The standard Java convention is to use a full English descriptor starting with the first letter capitalized using mixed case for the rest of the name. It is good practice to use noun when naming a class. Examples are –

Ø AddressDetails;

Ø Customer

Ø String

3.5.1.2 Class visibility: –

Classes may have one of two visibilities: public or package (default). Public visibility is indicated with the keyword public and package visibility is not indicated (there is no keyword). Public classes are visible to all other classes whereas classes with package visibility are visible only to classes within the same package.

1. Use package visibility for classes internal to a component. With package visibility you hide classes within the package, effectively encapsulating them within our component.

2. Use public visibility for the facades of components. Components are encapsulated by façade classes, classes that implement the interface of the component and that route messages to classes internal to the component.

3.5.1.3 Documentation Convention: –

The following information should appear in the documentation comments immediately preceding the definition of a class:

Ø The purpose of the class. Developers need to know the general purpose of a class so they can determine whether or not it meets their needs. I also make it a habit to document any good things to know about a class, for example is it part of a pattern or are there any interesting limitations to using it.

Ø Known bugs8. If there are any outstanding problems with a class they should be documented so that other developers understand the weaknesses/difficulties with the class. Furthermore, the reason for not fixing the bug should also be documented. Note that if a bug is specific to a single member function then it should be directly associated with the member function instead.

Ø The development/maintenance history of the class. It is common practice to include a history table listing dates, authors, and summaries of changes made to a class. The purpose of this is to provide maintenance programmers insight into the modifications made to a class in the past, as well as to document who has done what to a class. As with member functions, this information is better contained in a configuration management system, not the source files itself.

Ø Document applicable invariants. An invariant is a set of assertions about an instance or class that must be true at all "stable" times, where a stable time is defined as the period before a member function is invoked on the object/class and immediately after a member function is invoked. By documenting the invariants of a class you provide valuable insight to other developers as to how a class can be used.

Ø The concurrency strategy. Any class that implements the interface Runnable should have its concurrency strategy fully described. Concurrent programming is a complex topic that is new for many programmers; therefore you need to invest the extra time to ensure that people can understand your work. It is important to document your concurrency strategy and why you chose that strategy over others. Common concurrency strategies include the following: Synchronized objects, balking objects, guarded objects, versioned objects, concurrency policy controllers, and acceptors.

3.5.1.4 Declaration convention: –

There are two things that must be considering during the declaration of a class

1. Apply the “final” key words sensibly.

2. Always maintain the order among the member function and fields. The order of member of a class differs from architecture to architecture. But, according to my opinion,

Ø Static fields (private, protected, public)

Ø Private fields

Ø Protected fields

Ø Public fields

Ø Constructor()

Ø Finalize()

Ø Static or instance block{}

Ø Static function (private, protected, public)()

Ø Private function()

Ø Protected function()

Ø Public function()

Note – once the sequence decided, then all members should stick on that format.

3.5.2 Standards for Interfaces

The standards that are important for interfaces are based on:

3.5.2.1 Naming Interfaces: -

The Java convention is to name interfaces using mixed case with the first letter of each word capitalized. The preferred Java convention for the name of an interface is to use a descriptive adjective, such as Runnable or Cloneable, although descriptive nouns, such as Singleton or DataInput, are also common.

3.5.2.2 Documenting Interfaces

The following information should appear in the documentation comments immediately preceding the definition of an interface:

1. The purpose. Before other developers will use an interface, they need to understand the concept that it encapsulates. In other words, they need to know its purpose. A really good test of whether or not you need to define an interface is whether or not you can easily describe its purpose. If you have difficulties describing it, then chances are pretty good you do not need the interface to begin with. Because the concept of interfaces is new to Java, people are not yet experienced in their appropriate use and they are likely to overuse them because they are new. Just like the concept of inheritance, and in particular multiple inheritance, was greatly abused by developers new to object-orientation, I suspect that interfaces will also be greatly abused at first by programmers new to Java.

How it should and shouldn’t be used. Developers need to know both how an interface is to be used, as well as how it shouldn’t be used. Because the signature for member functions is defined in an interface, for each member function signature you should follow the member function documentation conventions discussed in section 3.1.1.

3.5.3 Standards for Packages

The standards that are important for packages are based on:

3.5.3.1 Naming Packages

There are several rules associated with the naming of packages. In order, these rules are:

1. Identifiers are separated by periods. To make package names more readable, Sun suggests that the identifiers in package names be separated by periods. For example, the package name java.awt is comprised of two identifiers, java and awt.

2. The standard java distribution packages from Sun begin with the identifier ‘java’ or ‘javax’. Sun has reserved this right so that the standard java packages are named in a consistent manner regardless of the vendor of your Java development environment.

3. Local package names begin with an identifier that is not all upper case. Local packages are ones that are used internally within your organization and that will not be distributed to other organizations. Examples of these package names include persistence.mapping.relational and interface.screen.

4. Global package names begin with the reversed Internet domain name for your organization. A package that is to be distributed to multiple organizations should include the name of the originating organization’s domain name, with the top-level domain type in lower case. For example, to distribute the previous packages, I would name them com.greensoft.persistence.mapping.relational and com.greensoft.interface.screens. The prefix (.com) should be lower case and should be one of the standard Internet top-level domain names (currently com, edu, gov, mil, net, org).

5. Package names should be singular. The common convention is to use singular names for package names, such as interface.screen, and not a plural, such as interface.screens.

3.5.3.2 Documenting a Package

We should maintain one or more external documents that describe the purpose of the packages developed by our organization. For each package we should document:

1. The rationale for the package. Other developers need to know what a package is all about so that they can determine whether or not they want to use it, and if it is a shared package whether or not they want to enhance or extend it.

2. The classes in the package. Include a list of the classes and interfaces in the package with a brief, online description of each so that other developers know what the package contains. Oracle-Sun suggests creating an HTML file called index.html for each package, putting the file into the appropriate directory for the package. A better name would be the fully qualified name of the package, postfixed with .html, so that we do not have to worry about accidentally overwriting one package documentation file with another.

3.5.4 Standards for compilation units

The standards and guidelines for compilation units are based on:

3.5.4.1 Naming a Compilation Unit:-

A compilation unit, in this case a source code file, should be given the name of the primary class or interface that is declared within it. Use the same name for the package/class for the file name, using the same case. The extension .java should be postfixed to the file name. Examples are –

Ø Customer.java

Ø Singleton.java

Ø AddressDetails.java

3.5.4.2 Documenting a Compilation Unit

Although we should strive to have only one class or interface declaration per file, it sometimes makes sense to define several classes (or interfaces) in the same file. My general rule of thumb is that if the sole purpose of class B is to encapsulate functionality that is needed only by class A then it makes sense that class B appear in the same source code file as class A. As a result, I have separated the following documentation conventions that apply to a source code file, and not specifically to a class:

1. For files with several classes, list each class. If a file contains more than one class we should provide a list of the classes and a brief description for each.

2. [OPTIONAL] The file name and/or identifying information. The name of the file should be included at the top of it. The advantage is that if the code is printed we know what the source file for the code is. The disadvantage is that if we change the source file name we also need to update our documentation, therefore if we have a sophisticated source control system (and if we don’t then get one) we might want to not include the source file name.

3. Copyright information. If applicable we should indicate any copyright information for the file. It is common to indicate the year of the copyright and the name of the individual/organization that holds the copyright. Note that the code author may not be the holder of the copyright.

3.6 Techniques for Writing Clean Code

In this section we will cover several techniques that help to separate the professional developers from the hack coders. These techniques are:

1. Document the code.

2. Paragraph the code.

3. Paragraph and punctuate multiline statements.

4. Use whitespace.

5. Specify the order of message sends.

6. Write short, single command lines.

7. Organize Code Sensibly.

8. Always place Constants on the Left Side of Comparisons.

3.7 Fields Visibility

The Sun Microsystems suggests that fields not be declared public for reasons of encapsulation, but I would go further to state that all fields should be declared private. When fields are declared protected there is the possibility of member functions in subclasses to directly access them, effectively increasing the coupling within a class hierarchy. This makes our classes more difficult to maintain and to enhance, therefore it should be avoided. Fields should never be accessed directly; instead accessor member functions (see below) should be used.

Visibility	Description	Proper Usage
public	A public field can be accessed by any other member function in any other object or class.	Do not make fields public.
protected	A protected field can be accessed by any member function in the class in which it is declared or by any member functions defined in subclasses of that class.	Do not make fields protected.
private	A private field can only be accessed by member functions in the class in which it is declared, but not in the subclasses.	All fields should be private and be accessed by getter and setter member functions (accessors).

For fields that are not persistent (they will not be saved to permanent storage) you should mark them as either static or transient. This makes them conform to the conventions of the BDK.

4. The Secrets of Productive Code

I’d like to share several techniques with all developers from Building Object Applications That Work that, in addition to following standards, lead to greater productivity:

1. Program for people, not the machine. The primary goal of our development efforts should be that our code is easy for other people to understand. If no one else can figure it out, then it isn’t any good. We should always obey to naming conventions, documentation of our code, to paragraph it.

2. Design first, then code. Have we ever been in a situation where some of the code that program relies on needs to be changed? Perhaps a new parameter needs to be passed to a member function, or perhaps a class needs to be broken up into several classes. How much extra work did we have to do to make sure that our code works with the reconfigured version of the modified code? Did we ask ourselves why somebody didn’t stop and think about it first when he or she originally wrote the code so that this didn’t need to happen? That they should have DESIGNED it first? Of course we did. If we take the time to figure out how we are going to write our code before we actually start coding we’ll probably spend less time writing it. Furthermore, we’ll potentially reduce the impact of future changes on our code simply by thinking about them up front.

3. Develop in small steps. I have always found that developing in small steps, writing a few member functions, testing them, and then writing a few more member functions is often far more effective than writing a whole bunch of code all at once and then trying to fix it. It is much easier to test and fix ten lines of code than 100, in fact, I would safely say that you could program, test, and fix 100 lines of code in ten 10-line increments in less than half the time than you could write a single one-hundred line block of code that did the same work. The reason for this is simple. Whenever you are testing your code and you find a bug you almost always find the bug in the new code that you just wrote, assuming of course that the rest of the code was pretty solid to begin with. You can hunt down a bug a lot faster in a small section of code than in a big one. By developing in small incremental steps you reduce the average time that it takes to find a bug, which in turn reduces your overall development time.

4. Read, read, read. This industry moves far too quickly for anyone to sit on their laurels. In fact, friends of mine within Sun estimate that it’s a full time job for two to three people just to keep up with what’s happening with Java, let alone what’s happening in the object-orientation field or even development in general. That says to me that you need to invest at least some time trying to keep up. To make things easier for you, I’ve created an online reading list indicating what I consider to be the key development books that you should consider reading.

5. Work closely with your users. Good developers work closely with their users. Users know the business. Users are the reason why developers create systems, to support the work of users. Users pay the bills, including the salaries of developers. You simply can’t develop a successful system if you do not understand the needs of your users, and the only way that you can understand their needs is if you work closely with them.

6. Keep your code simple. Complex code might be intellectually satisfying to write but if other people can’t understand it then it isn’t any good. The first time that someone, perhaps even you, is asked to modify a piece of complex code to either fix a bug or to enhance it chances are pretty good that the code will get rewritten. In fact, you’ve probably even had to rewrite somebody else’s code because it was too hard to understand. What did you think of the original developer when you rewrote their code, did you think that person was a genius or a jerk? Writing code that needs to be rewritten later is nothing to be proud of, so follow the KISS rule: Keep it simple, stupid.

7. Learn common patterns, antipatterns, and idioms. There is a wealth of analysis, design, and process patterns and antipatterns, as well as programming idioms, available to guide you in increasing your development productivity. My experience is that patterns provide the opportunity for very high levels of reuse within your software development projects.

ANT (Another Neat Tool)

2011-05-10T11:56:00.005+05:30

Introduction

Ant is a Java-base builds tool. According to James Duncan Davidson (ANT author) ANT is an Another Neat Tool. Later the term ANT synchronized with real ant (nature creature ant) to see ant’s capability and strength. An ant can carry a weight dozens of times of its own. Thus we can understand that ant is a java base building tool that works multiple times more to its real power. ANT works just the “make” tool that works for C and C++. Using ANT we can make a numerous tasks without any customization. This document contains explanation on each task in more details step-by-step when it requires. To understand this document, I shall go step-by-step, starting from installation of ANT binary.

ANT Installation

This document is prepared under this assumption that the reader of this document has knowledge about system variables, environment variables and installation and configuration of software. Steps for ANT installation is –

To get up and running with the binary edition of Ant quickly, follow these steps:

1. Make sure you have a Java environment installed. To get latest JAVA click hit this link - http://www.oracle.com/technetwork/java/javase/downloads/index.html. If JDK is not present, only the JRE runtime, then many tasks will not work. Ant 1.8.* works with JDK 1.4 but strongly recommended JDK 1.5. So first be sure that machine must have JDK 1.5 or later environment.

2. Download Ant – visit this link - http://ant.apache.org/bindownload.cgi

3. Uncompress the downloaded file into a directory.

4. Set environmental variables JAVA_HOME to your Java environment, ANT_HOME to the directory you uncompressed Ant to, and add ${ANT_HOME}/bin (in UNIX environment) or %ANT_HOME%/bin (Windows) to your PATH.

5. Optionally, from the ANT_HOME directory run ant -f fetch.xml -Ddest=system to get the library dependencies of most of the Ant tasks that require them. If you don't do this, many of the dependent Ant tasks will not be available.

Once you completed above steps, then open command prompt and run the following commands –
C:\>set path=”c:apache-ant-1.8.1\bin”; %path%
C :\> ant -version

If both command run properly that means you have configured Another Neat Tool (ANT). And to seeing this screen means your installation phase has over.

Note: Ant 1.8.* works with jdk1.4 and higher, Ant 1.7.* works with JDK.3 and higher, Ant 1.6.* works with JDK 1.2 and higher, Ant 1.2 to Ant 1.5.* work with JDK 1.1 and higher.

ANT Basics

After successful installation of ANT version 1.8.1, now I move on to some core or basics of ant. An ant build file comes in the form of an XML documents, all that is required is a simple text editor to edit the build file(s). An editor that provides XML syntax supportive utility is more suitable and preferable. The ant installation comes with a JAXP-compliant XML parser, this means that the installation of an external XML parser is not necessary. Details about “build.xml” file … Following build.xml are well formatted xml file that comprised of several target entities. There a lot to explain about the following build.xml file.

First Line of the build.xml is –

xml version="1.0"?>

Since Ant build files are XML files the document begins with an XML declaration which specifies which version of XML is in use, this is to allow for the possibility of automatic version recognition should it become necessary. Next lien of this document is project element.

Project Element

Every build file must have least project and target (default) elements. Above build file has also a project element. Project element has an optionally a description for the project can be provided as a top-level element. Each project defines one or more targets. A target is a set of tasks you want to be executed. When starting Ant, you can select which target(s) you want to have executed. When no target is given, the project's default is used. In following table describe the attribute of project element –

Attribute	Description	Required
name	the name of the project.	No
default	the default target to use when no target is supplied.	No; however, since Ant 1.6.0, every project includes an implicit target that contains any and all top-level tasks and/or types. This target will always be executed as part of the project's initialization, even when Ant is run with the -projecthelp option.
basedir	the base directory from which all path calculations are done. This attribute might be overridden by setting the "basedir" property beforehand. When this is done, it must be omitted in the project tag. If neither the attribute nor the property has been set, the parent directory of the buildfile will be used.	No

Target Element

Next element of this file is target –

The target element is used as a wrapper for sequences of actions. A target has a name, so that it can be referenced from elsewhere, either externally from the command line, or internally via the depends keyword, or through a direct call. The target in the example is called "init" (initiate), it makes a directory using the mkdir element with the name specified by the build property defined in three. The target element has a number of possible attributes, unless otherwise specified, these are optional:

Attribute	Description	Required
name	The name of the target is used to reference it from elsewhere, it is subject to the constraints of XML well formed-ness.	Yes
depends	This is a comma separated list of all the targets on which this target depends, for example, immediate next block illustrates how compile depends on init, in other words, depends contains the list of the targets that must be executed prior to executing this target.	No
if	This is a useful attribute which allows one to add a conditional attribute to a target based on the value of a property for example, if="gui-ready" could be used to only execute the encapsulating target's instructions if the property gui-ready was is (to any value).	No
unless	This is the converse of if, for example, unless="gui-ready" could be used to conditionally execute the contents of the encapsulating target. The targets' contents will be executed unless the the property gui-ready is set (to any value).	No
description	This is a short description of the target.	No
extensionOf	Adds the current target to the depend list of the named extension-point. Since Ant 1.8.0.	No
onMissingExtensionPoint	What to do if this target tries to extend a missing extension-point. ("fail", "warn", "ignore"). Since Ant 1.8.2.	No. Not allowed unless `extensionOf` is present. Defaults to `fail`.

Target element has a attribute name depends, following example are concerning this attribute –

As explained in above block, depends allows one to specify other targets that must be executed prior to the execution of this target. In the listing above depends="init" is used to indicate that the compile target requires that the target named init be executed prior to executing the body of compile. For more details about target just visit this link http://ant.apache.org/manual/targets.html.

Property Element

In given example build file there is an element name property. For example you may see the following snippet of build.xml file –

name=”builddir” value=”build” />

Properties are an important way to customize a build process or to just provide shortcuts for strings that are used repeatedly inside a build file.
In its most simple form properties are defined in the build file (for example by the property task) or might be set outside Ant. A property has a name and a value; the name is case-sensitive. Properties may be used in the value of task attributes or in the nested text of tasks that support them. This is done by placing the property name between "${" and "}" in the attribute value. For example, if there is a "builddir" property with the value "build", then this could be used in an attribute like this: ${builddir}/classes. This is resolved at run-time as build/classes.
Normally property values cannot be changed, once a property is set, most tasks will not allow its value to be modified. In general properties are of global scope, i.e. once they have been defined they are available for any task or target invoked subsequently - it is not possible to set a property in a child build process created via the ant, antcall or subant tasks and make it available to the calling build process, though, with Ant 1.8.0 property expansion has become much more powerful than simple key value pairs, more details can be found from here http://ant.apache.org/manual/properties.html. Ant provides access to all system properties as if they had been defined using a task. For example, ${os.name} expands to the name of the operating system. Some built-in properties are –

Built-in properties	Description
basedir	The absolute path of the project's basedir (as set with the basedir attribute of ).
ant.file	The absolute path of the buildfile.
ant.version	The version of Ant.
ant.project.name	The name of the project that is currently executing; it is set in the name attribute of .
ant.project.default-target	The name of the currently executing project's default target; it is set via the default attribute of .
ant.project.invoked-targets	A comma separated list of the targets that have been specified on the command line (the IDE, an task ...) when invoking the current project.
ant.java.version	The JVM version Ant detected; currently it can hold the values "1.2", "1.3", "1.4", “1.5" and "1.6".
ant.core.lib	The absolute path of the `ant.jar` file.

Task Element

A task is a piece of code that can be executed. A task can have multiple attributes (or arguments, if we prefer). The value of an attribute might contain references to a property. These references will be resolved before the task is executed. Tasks have a common structure:

<name attribute1="value1" attribute2="value2" ... />

Where name is the name of the task, attributeN is the attribute name, and valueN is the value for this attribute. All tasks share a task name attribute. The value of this attribute will be used in the logging messages generated by Ant. Tasks can be assigned an id attribute:

<taskname id="taskID" ... />

Where taskname is the name of the task, and taskID is a unique identifier for this task. For understanding I am giving the snippet code from given example –

The javac element, as used above, is a task, tasks are performed in the body of a target, in this case, the source directory is specified by referencing the src property and the destination directory is specified by referencing the build property. The example above causes javac to be executed, compiling all the .java files in the directory specified by the src property and placing the resultant .class files in the directory specified by the build property.

These are a set of built-in tasks, but it is also very easy to write your own. To write your own task visits this link - http://ant.apache.org/manual/develop.html

Tasks	Description
ant	Used to execute another ant process from within the current one.
copydir	Used to copy an entire directory.
copyfile	Used to copy a single file.
cvs	Handles packages/modules retrieved from a CVS repository.
delete	Deletes either a single file or all files in a specified directory and its sub-directories.
deltree	Deletes a directory with all its files and subdirectories.
exec	Executes a system command. When the os attribute is specified, then the command is only executed when Ant is run on one of the specified operating systems.
get	Gets a file from an URL.
jar	Jars a set of files.
java	Executes a Java class within the running (Ant) VM or forks another VM if specified.
javac	Compiles a source tree within the running (Ant) VM.
javadoc/javadoc2	Generates code documentation using the javadoc tool.
mkdir	Makes a directory.
property	Sets a property (by name and value), or set of properties (from file or resource) in the project.
rmic	Runs the rmic compiler for a certain class.
tstamp	Sets the DSTAMP, TSTAMP, and TODAY properties in the current project.
style	Processes a set of documents via XSLT.

These are the some basic elements about ant build.xml file. You can learn in depth by visiting this link - http://ant.apache.org/manual/index.html. Now I am going to make a sample project using build.xml…

A Typical project as an Example

The purpose of this section is to make a project using ant and its build.xml file. Steps that I shall follow are –

1. 1. Preparing directory structure.

2. 2.Creating source file in standard directory location (recommended by ant)

3. 3. Building build.xml file.

4. 4. Execute ant command.

1. Preparing directory structure -

It is good idea to adhere the ant recommendation because we will use the ant as a building tool. According to ant recommendation we shall create a root directory inside this we will create following directory structure:

1.1 src: For project source files.

1.2 build: For compiled/output files produced (by Ant).

1.3 lib : For class libraries and dependency files.

Create an “Application” directory and from within this, create the three directories described above. A simple Java program will be used to illustrate the use of Ant.

2. Source File inside directory src -

Copy following code and paste in java compatible editor, this is not mandatory you may even a simple editor also. Save this file inside src folder using same package hierarchy which is mention as package statements with name “HelloWorld.java”.

package com.greensoft.ant.example;

/**

* @author Pravind Kumar

public class HelloWorld {

/**

* Default Constructor

public HelloWorld() {

}

/**

* @param args

public static void main(String[] args) {

System.out.println("Hello World By Pravind Kumar");

}

3. Building build.xml -

This is a standard build.xml file, just copy and pastes it in an editor and saves as “build.xml” in parallel to src folder.

Inside this build.xml file I used some tasks like javac, jar and java. I hope every elements there is not a problem to understand this file because I have already discussed all elements whatever I used inside this file. Even then there is any issue then you are suggested that review this document once again or visit this link for a more and complete idea about build.xml file - http://ant.apache.org/manual/index.html. Now it’s time to cheers.

4. Execute ant Command -

1. Open run command with combination of window key + r.

2. Type cmd and press Enter key.

3. On command prompt type cd\ and press enter

4. Now go to your “Application” folder

5. Type ant and press enter…. WOW! Your result on you console. And look like this…

Ant File Sets

A FileSet is a filter which uses one or more patterns to specify which files are desired. A FileList is a list of desired files. FileSets use PatternSets and Patterns to define their actions.

• ? is used to match any character.

• * is used to match zero or more characters.

• ** is used to match zero or more directories.

A FileSet must specify a base directory from which all other path calculations are made; this is supplied via the dir attribute. Fileset has a various attribute; following tables dictate about fileset attribute –

Attribute	Description	Required
dir	The root of the directory tree of this FileSet.	Yes, Either dir or file must be specified
file	shortcut for specifying a single-file fileset	Yes, Either dir or file must be specified
defaultexcludes	Indicates whether default excludes should be used or not (`yes \| no`); default excludes are used when omitted.	NO
includes	Comma- or space-separated list of patterns of files that must be included; all files are included when omitted.	NO
includesfile	The name of a file; each line of this file is taken to be an include pattern.	NO
excludes	Comma- or space-separated list of patterns of files that must be excluded; no files (except default excludes) are excluded when omitted.	NO
excludesfile	The name of a file; each line of this file is taken to be an exclude pattern.	NO
casesensitive	Must the include and exclude patterns be treated in a case sensitive way? Defaults to true.	NO
followsymlinks	Shall symbolic links be followed? Defaults to true. See the note below.	NO
erroronmissingdir	Specify what happens if the base directory does not exist. If true a build error will happen, if false, the fileset will be ignored/empty. Defaults to true. Since Ant 1.7.1 (default is true for backward compatibility reasons.)	NO

Before going to depth about fileset I want to discuss about structure of fileset elements –

Or:

Since both of these FileSets contain no patterns, they match the default; every file in the base directory and all its subdirectories, recursively.

Some Basic Use of fileset –

If one desires to delete any of these default excluded files, for example, to delete all scratch files that editplus (a text editor) made, recursively, one has to set defaultexcludes="no" so that the defaults are not excluded and then one could use something like:

Removing temporary files...

Includes all files ending in the extensions "java" and "j2ee" in the base directory and all subdirectories, the pattern is applied recursively in the subdirectories.

Includes all files those contain the string "java" in the base directory and all sub directories, recursively. Excludes any files in any directory called "j2ee", whether it occurs in the current directory or any of the sub directories, recursively. Notice that the syntax is slightly different, in that, include and name are used instead of includes and exclude and name are used instead of excludes. In the context of the sentences above, the word "recursively" means that the pattern is applied to each of the subdirectories as well as the base directory hence it is then applied to the sub-directories of the sub-directories and so on. The pattern is applied to all directories under the base directory.

A Bit about PatternSet

Patterns can be grouped to sets and later be referenced by their id attribute. They are defined via a patternset element, which can appear nested into a FileSet or a directory-based task that constitutes an implicit FileSet. In addition, patternsets can be defined as a standalone element at the same level as target — i.e., as children of project as well as children of target. Patternsets may be nested within one another, adding the nested patterns to the parent patternset. A nested patternset can be inverted using the element (Since Ant 1.7.1). Patterns can be specified by nested , or elements for example –

Patterns can be specified by nested , or elements or the following attributes.

Attribute	Discription
include	Each such element defines a single pattern for files to include or exclude.
includes	Comma- or space-separated list of patterns of files that must be included. All files are included when omitted.
exclude	Each such element defines a single pattern for files to include or exclude.
excludes	Comma- or space-separated list of patterns of files that must be excluded; no files (except default excludes) are excluded when omitted.
includesfile	The name of a file; each line of this file is taken to be an include pattern. You can specify more than one include file by using a nested includesfile elements.
excludesfile	The name of a file; each line of this file is taken to be an exclude pattern. You can specify more than one exclude file by using a nested excludesfile elements.

A little bit about attributes –

Include and exclude
Include and exclude have three attributes among them name is required attribute. Two more attribute for conditional purpose these are if and unless. Following table say about this –

Attribute	Description	Required
name	The pattern to in/exclude.	YES
if	Only use this pattern if the named property is set.	NO
unless	Only use this pattern if the named property is not set	NO

Includesfile and excludesfile
if you want to list the files to include or exclude external to your build file, you should use the includesfile/excludesfile attributes or elements. Using the attribute, you can only specify a single file of each type, while the nested elements can be specified more than once - the nested elements also support if/unless attributes you can use to test the existance of a property.

Attribute	Description	Required
name	The name of the file holding the patterns to in/exclude.	YES
if	Only read this file if the named property is set	NO
unless	Only read this file if the named property is not set	NO

Ant Flow of Control

Since Ant does not contain any real control structures like if..then..else, one has to manipulate Ant's ability to call internal targets that support conditional execution to emulate the desired control structures. In ant we can do such flow using customize task. For example just look following build.xml –

Case – 1 Assuming the case where the first file, fileone, and the second file, filetwo are not available. The initial condition checks if the file fileone available, if it is, the property condition is set. Calls to the targets then and else follow. The execution of then is conditional, dictated by (if="condition"). Since the assumption is fileone is not available, condition will not be set and the body of then will not be executed. The next target, else, will be called. The execution of else is conditional, dictated by condi- (unless="tion") which means that the body will be executed unlesscondition is set. Since condition has not been set, the body of else will be executed.

Case – 2 Assuming the case where the first file, fileone, is present, and the second file, filetwo is not. The initial condition will be set because fileone is available so the call to then will be successful. The body of then contains another condition which checks for the existence of the file filetwo, if it is available, the property, inner-condition is set. Since the assumption is that filetwo is not available, the property inner-condition will not be set. Calls to the targets inner.then and inner.else follow. The execution of inner.then is conditional, dictated by (if="inner-condition") so the body of inner.then will not be executed. The execution of inner else is conditional, dictated by (unless="inner-condition") so the body of inner.else will be executed since the only thing that would stop the execution of it would be if inner-condition was set.

Case – 3 Assuming the case where the first file, fileone, and the second file, filetwo are both available. The outer condition will cause the property condition to be set because fileone is available, so when the target then is called, the body will be executed. The condition within then will cause the property inner-condition to be set because filetwo is available. This means that the call to inner.then will be successful. Upon exiting inner.then, inner.else will be called but the body will not be executed because innercondition is set. Upon exiting then, else will be called but the body will not be executed because condition is set.

ANT USING EXTERNAL LIBRARIES (log4j)

In my previous example I ran a build file and output was coming on console. But assume in case where output is required on log file or other file. I mean I want to execute a build file using external file instead of java IO API. So in this example I am going to use log4j API to write information in log file instead of standard console.

We store the external jar or library inside lib folder what we have created earlier. Here we are putting the log4j jar inside lib folder. 2^nd step would be to change the HelloWorld.java code, and now HelloWorld.java looks like –

package com.greensoft.ant.example;

import org.apache.log4j.Logger;

import org.apache.log4j.BasicConfigurator;

/**

* @author Pravind Kumar

public class HelloWorld {

private static Logger logger = Logger.getLogger(HelloWorld.class);

/**

* Default Constructor

public HelloWorld() {

}

/**

* @param args

public static void main(String[] args) {

//System.out.println("Hello World By Pravind Kumar");

BasicConfigurator.configure();

logger.info("Hello World By Pravind using Log4j api");

}

Now, it’s time to update the build.xml file accordingly so that it can find the all imported class files in class path otherwise it will show a couple of exception during compilation. In build.xml file add one more line for property inside init target like this –

value="lib"/>

After that, to compile new java file need log4j jar file. There are two ways to get log4j jar; one is to set that jar file into class path of system environment variable and another is to set path element inside build.xml file. So I think second option is better. To set the jar file in build.xml, add following line of code into init target. Path element line looks like this –

Path element is using to make a group of jar file recursively using fileset element. About fileset element see the
above block.

We had coded BasicConfigurator.configure(); which implies a simple, but hard coded configuration. More confortable would be using a property file. In the java source delete the BasicConfiguration-line from the main() method (and the related import-statement). Log4J will search then for a configuration as described in it's manual. Then create a new file src/log4j.properties. That's the default name for Log4J's configuration and using that name would make life easier - not only the framework knows what is inside, we too! So put this properties file inside src (source ) directory. Properties file is – log4j.properties

log4j.rootLogger=DEBUG, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender

log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

log4j.appender.stdout.layout.ConversionPattern=%m%n

Now according to this configuration file we need to change the compile target inside build.xml file. Thus new compile target look like this –

Also update run target after updating run target looks like –

And this is the final build.xml file and ready for execution –

Just go on command prompt and switch to your application folder and type “ant” and press enter. What’s up! Congratulation your application is configured properly and in running state.

Java: Language Or Technology

2010-07-24T11:44:00.000+05:30

Java is a technology not a language. Java language is a part of java technology. So you can see java language is sub-set of java technology. Before going into depth you must know about the following terms –
    1.    Language
    2.    Platform
    3.    Technology
First, Language is a medium, by using this medium two entity come together. Platform is a set of rules, by using this any system or any entity can in existence, while Technology is a set of platform and language. Now, I think this is clear that java is a technology not only a language; because it supports various platforms on various environments. These days no one can think any electronic equipment without java technology. In your home
there is TV set, this is different platform rather than computers this is again a system that full fill a set of rules. It completes your query and all the works. Java language cannot do alone these things, but java technology can do this. Java technology executes your query by using java language. Here java language is a medium that interacts with your hardware.

Java technology provides following platforms – J2SE (java 2 Standard Edition), J2EE (java 2 Enterprise Edition), J2ME (java 2 Micro Edition) for all type of systems. Java technology spreads all over the human life required technologies. Now java technology is changing the human life and enterprise life. Day by day java technology includes new concepts, new methodology for making life easy. Java technology is a general purpose high level software platform that is incorporate with high level java programming language. According to a survey, currently java platform powers more than 4.3 billion device including –
        • 850+ million PCs
        • 2.1 billion Mobile phones and other hand held devices
        • 3.5 billion smart cards
        • Set-top boxes, ATMs, printers, Web cams, games, car navigation systems, lottery terminals, medical devices, GPS, parking payment stations, Washing machine, Refrigerator and more.

After seeing this survey result you can understand the verstility of java Technology, thus java is set of rules, set of platform that provides a complete system and to make the system reality - it includes java language. Therefore, we can understand that java is a technology not only a language.

Career : Next Step

2010-07-20T10:01:00.000+05:30

The term Career comes from the Latin words carrera which means race. According to dictionary the meaning of career is “an individual’s course or progress through life or a distinct portion of life”. One also meaning of career called Education.

If I see above lines about career then I can say career is a race that starts with born of a creature. I think the meaning of race is a relative term. Because for some one race may be a passion, without race they cannot feel a complete while someone can take race as a horrible or tough task. So, finally I think career is a race with passion having optimistic meaning. One also meaning of career is Education, but I am not with this meaning because the person who is not educated has not career, is this true?

These days career starts with born, and we can see this on news and news paper, where we see about junior singer, dancer, actor, choreographer and many more so we cannot say that the career start after high school examination board or senior secondary examination board. I am talking about that excellence. Excellence never comes after an age; it is inborn quality inside creature so provoke your excellence that will give you a golden career.

Before discussing anything, first see the factor that affects the children to make the decision.

1. Environmental factor (activities inside surrounding environment)

2. Psychological factor

3. Situational factor

4. Physical factor

The age when children are in high school class or in senior secondary class is very charming and attractive; during this age most of the children spend most of his time in non-productive work that is not fair for their career. Mostly these are environmental factor that affects the children. But this is not the topic to discuss here. I shall continue in next blog…

After finishing high school board examination most of the students think for IIT-JEE or medical. No doubt these two fields are very attractive fields for young students but before going on that way need to elaborate some things that may be environment, situations, constraints etc. After finishing the senior secondary examination board students have the verities of scope to make their careers for example IIT-JEE, CAT, GMAT, Medical, management etc. in my view to go anywhere need to think on the following headings-

Exploring the known and unknown facts –

This is competitive age, if you think to get a spoon of water, for this you have to compete to someone or some environment factor. You cannot get anything easily so if you want to be an engineer, a doctor, a manager, all these are demands full commitment and devotion. So I am saying here to explore everything before starting. Your study strategy, study strength, study schedule, economic condition, family strength, support all these known and unknown factors. Here you can openly discuss to your teachers, parent, and friends and so on. You can also ask to me about any doubt related to your doubts. I think to see the dream is a good approach to push you near to target. Even you can give a gap year to complete your dream but in that case you must sure that you are the person who kisses the excellence, not success. Never prepare for success always prepare for excellence. And always do your study in managed way; even I think if you want to talk to your parent it should be scheduled. Your every minute should be scheduled.

Courage to go beyond books –

You cannot learn everything from books. These days every competition is changing its face; it is linking itself to day life of nature. So you cannot expect that, after making yourself as a book worm you can kiss the excellence. To be excellent person you need to open your all five sensor. I mean keep in touch with your environment, science, politics, human behavior. You must study news paper regularly, watching news (materialistic). Share your knowledge with your friends, but avoid hot and non-materialistic discussion. And forget about the debate with any one during this period. Keep in mind that you have lots of time in your life for that.

In my view book gives you the core of your study, while external activity gives you the way to present that core knowledge. If book is a Skeleton then external things make it glow. So I suggest you to keep in touch with all good external resource also.

Recognize yourself and take a complete decision –

How long and how much do you think about your career depends upon the education system of that place. Like if I talk about Indian education system then it is so oppressive, that deprives students to think about their career clearly. Most of the students in this age remain confused about their true desires and goals till the end. I have seen a student that is preparing for engineering but his internals wish is to be a singer and he enjoys the singing job. So I think he can be better singer even best too instead of engineer. So, I think before taking any decision read you, and then take decision. Once you recognize yourself, then set your target and commit to shoot that target. You may take a gap year for that but remember the fact that your aim should not go in vain. I also think if the students take a gap should encourage by his parent. Once you decide for any target hit this target with passion up to excellence mark. Don’t see other things moves towards as an eagle as a pig (pig never miss target).

Einstein said – “All our dreams can come true, if we have the courage to pursue them”. Free spirits and happy individuals make better engineer, better doctor, better Administrative, better manager and so on. Every people are searching inside you a better performer of your dream field, so why are you waiting. So decide your goal and hit them and remember one strength line e.g. "Risk and Madness towards the life and work always lead to superiority." GO A HEAD Best of Luck……

These are the basis things that motivate you to take a steps. for any specific query or suggestion you can put your question or suggestion..