Sanjib

Java JMX tutorial

2011-01-03T23:02:00.000-08:00

Here is some sample Java source code for some JMX tests that I created recently.

First, here's the source code for a Java MBean interface named HelloMBean:

public interface HelloMBean {

public String helloService(String name);

}

A class to implement the JMX MBean interface
Next, here's the source code for a Java class named Hello that implements the HelloMBean interface we just defined:

public class Hello implements HelloMBean {

@Override
public String helloService(String name) {

System.out.println(" Called ...");
return " Hello Mbean :"+name;
}

}

A JMX example class (a JMX service)
Next up, here's the source code for a Java class named SimpleAgent that includes a main method that starts up our JMX service application:

import java.lang.management.ManagementFactory;

import javax.management.MBeanServer;
import javax.management.ObjectName;

public class SimpleAgent {

private MBeanServer mbs = null;

public SimpleAgent() {

// Get the platform MBeanServer
mbs = ManagementFactory.getPlatformMBeanServer();

// Unique identification of MBeans
Hello helloBean = new Hello();
ObjectName helloName = null;

try {
// Uniquely identify the MBeans and register them with the platform MBeanServer
helloName = new ObjectName("FOO:name=HelloBean");
mbs.registerMBean(helloBean, helloName);
} catch(Exception e) {
e.printStackTrace();
}
}
// Utility method: so that the application continues to run
private static void waitForEnterPressed() {
try {
System.out.println("Press to continue...");
System.in.read();
} catch (Exception e) {
e.printStackTrace();
}
}

public static void main(String argv[]) {
SimpleAgent agent = new SimpleAgent();
System.out.println("SimpleAgent is running...");
SimpleAgent.waitForEnterPressed();
}
}

A script to start our JMX service
And finally here's a Unix/Linux shell script named run.bat that I wrote to run this sample JMX application ("JMX service")

Run.bat
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=5555 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false SimpleAgent

As you can see from that code, my application will listen on port 5555 of whatever computer system it is run on.

Access our JMX service with JConsole
Once the application is running you can then connect to it with the jconsole application and view its JMX resources.

test your mbean by passing args.

Software Design Principles Part II

2010-12-21T23:09:00.000-08:00

Open Close Principle

Motivation

A clever application design and the code writing part should take care of the frequent changes that are done during the development and the maintaining phase of an application. Usually, many changes are involved when a new functionality is added to an application. Those changes in the existing code should be minimized, since it's assumed that the existing code is already unit tested and changes in already written code might affect the existing functionality in an unwanted manner.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.

Intent

Software entities like classes, modules and functions should be open for extension but closed for modifications.

Example

Bellow is an example which violates the Open Close Principle. It implements a graphic editor which handles the drawing of different shapes. It's obviously that it does not follow the Open Close Principle since the GraphicEditor class has to be modified for every new shape class that has to be added. There are several disadvantages:

· for each new shape added the unit testing of the GraphicEditor should be redone.

· when a new type of shape is added the time for adding it will be high since the developer who add it should understand the logic of the GraphicEditor.

· adding a new shape might affect the existing functionality in an undesired way, even if the new shape works perfectly

In order to have more dramatic effect, just imagine that the Graphic Editor is a big class, with a lot of functionality inside, written and changed by many developers, while the shape might be a class implemented only by one developer. In this case it would be great improvement to allow the adding of a new shape without changing the GraphicEditor class.

// Open-Close Principle - Bad example
 class GraphicEditor {
 
        public void drawShape(Shape s) {
               if (s.m_type==1)
                       drawRectangle(s);
               else if (s.m_type==2)
                       drawCircle(s);
        }
        public void drawCircle(Circle r) {....}
        public void drawRectangle(Rectangle r) {....}
 }
 
 class Shape {
        int m_type;
 }
 
 class Rectangle extends Shape {
        Rectangle() {
               super.m_type=1;
        }
 }
 
 class Circle extends Shape {
        Circle() {
               super.m_type=2;
        }
 }

Bellow is a example which supports the Open Close Principle. In the new design we use abstract draw() method in GraphicEditor for drawing objects, while moving the implementation in the concrete shape objects. Using the Open Close Principle the problems from the previous design are avoided, because GraphicEditor is not changed when a new shape class is added:

· no unit testing required.

· no need to understand the sourcecode from GraphicEditor.

· since the drawing code is moved to the concrete shape classes, it's a reduced risk to affect old functionallity when new functionallity is added.

/ Open-Close Principle - Good example
 class GraphicEditor {
        public void drawShape(Shape s) {
               s.draw();
        }
 }
 
 class Shape {
        abstract void draw();
 }
 
 class Rectangle extends Shape  {
        public void draw() {
               // draw the rectangle
        }
 }

Conclusion

Like every principle OCP is only a principle. Making a flexible design involves additional time and effort spent for it and it introduce new level of abstraction increasing the complexity of the code. So this principle should be applied in those area which are most likely to be changed.

There are many design patterns that help us to extend code without changing it. For instance the Decorator pattern help us to follow Open Close principle. Also the Factory Method or the Observer pattern might be used to design an application easy to change with minimum changes in the existing code.

Software Design Principles Part I

2010-12-21T22:59:00.001-08:00

Design Principles

> What are Software Design Principles?

Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

Rigidity - It is hard to change because every change affects too many other parts of the system.
Fragility - When you make a change, unexpected parts of the system break.
Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

Open Close Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.
OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you’ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing, …). This is why we have to make sure our modules follow Open Closed Principle.

When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern and Strategy Pattern.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, …) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, …) and an external module controlling the dependencies will inject the reference to the second one.

By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they don't use.
This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

Single Responsibility Principle

A class should have only one reason to change.
In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

Liskov's Substitution Principle

Derived types must be completely substitutable for their base types.
This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.

Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy

Java 5 : Extended

2010-11-17T23:54:00.001-08:00

This page describe the major new features added in Java 5.

Annotations (Metadata)

avoids need for external configuration files, allowing configuration data to be embedded in source files
avoids duplicated boilerplate code by enabling tools to generate it from annotations in source code
leads to a declarative programming style
an example of a specific annotation added in Java 5 is @Override which marks a method that overrides a superclass method
for more information, see here
Autoboxing/Unboxing

avoids need to convert between primitives and their corresponding type wrapper objects
basic example
int i = 19;
Integer iObj = i;
int j = iObj;
// i and j are equal
collections example
List list = new ArrayList(); // see "Generics"
int i = 19;
list.add(i);
int j = list.get(0);
// i and j are equal
overuse can result in performance issues
for more information, see here
Enhanced For Loop

array example
Car[] cars = new Car[](5);
// populate array of Car objects
for (Car car : cars) {
// Use the variable car inside the loop.
}
list example
List cars = new ArrayList() // see "Generics"
// populate List of Car objects
for (Car car : cars) {
// Use the variable car inside the loop.
}
for more information, see here
Enums

can create enumerated types with arbitrary fields and methods
example
enum Season { WINTER, SPRING, SUMMER, FALL }
Season season = SPRING;
for (Season season : Season.values()) {
// use season variable
}
to get the integer value of an enumerated value, invoke the ordinal method on it
for more information, see here (includes an example of adding fields and methods to enums)
Generics

most often used for type-safe collections
example
List myList = new ArrayList();
// only String objects can be added to myList.
collections of subclass objects can be passed to methods that accept collections of superclass objects (for example, an object of type List can be passed to a method that accepts List or even List)
for more information, see here
Static Import

avoids the need to qualify static members of classes or interfaces with the class or interface name
example from JUnit 4
import static org.junit.Assert.*;
// can now use static assert methods from the Assert class
// without prefixing them with "Assert."
note that the ".*" part says to import all the static members from the Assert class (can't omit that!)
for more information, see here
Varargs

eliminates the need to put arguments into an array for the purpose of passing a variable number of arguments to a method
example
public void washCars(Car... cars) {
for (int i = 0; i < cars.length; i++) {
Car car = cars[i];
// wash the car
}
}

// call like this
washCars(car1, car2, car3);
the type of cars is Car[]

LOG4J :Best Practice

2010-11-09T21:22:00.000-08:00

I’ve seen these antipatterns over and over again, and I thought it was time to write about them to help any folks who are new to Log4J out there. Senior developers – please share this with your junior peers and save yourself the pain of refactoring later! I’m interested in common mistakes or points of confusion that you’ve seen as well.

Read on to get a quick tutorial, or reference to point your developers at…

Mistake 1: Not logging exceptions at all

Many times, developers don’t realize that there are overloaded versions of the basic log4j methods. I have seen this more times than I can count:

catch(SomeMeaningfulException e) {
LOG.error("Bad things: " + e.getMessage());
}
Why is this bad? Because you just lost the single most valuable piece of information in the exception: the stack trace! Obviously, a well-thought out exception strategy is ideal, but at the very least, do this:

LOG.error("Bad things",e);

Mistake 2: Not logging exceptions with the correct method

catch(SomeMeaningfulException e) {
LOG.error("Bad things");
LOG.error(e);
}
This is a tricky one. The single-parameter method signature for log4j will simply call toString on the object passed in. In the case of a Throwable, this means you will get the output of getMessage; thus you have exactly the same result as in #1.

Mistake 3: Not adding thread name to PatternLayout

Many, many sample log4j configuration files to be found on the net (such as this example) exclude the crucial thread name property (%t). This is absolutely required when using log4j in any kind of multi-user environment. Without it (and without smart alternative use of something like the MDC/NDC functionality), it’s impossible to trace a series of log statements to a single, consecutive, series of actions — for example, a user request in most modern web frameworks.

Make sure you include the %t conversion parameter if you’re running in any multi-user environment!

Mistake 4: Not making appropriate use of log categories

It’s very common to use the typical fully qualified class name as the name of the Category you log to:

static Logger LOG = Logger.getLogger(ThisClass.getClass());
This is all well and good, but suffers from 2 flaws:

Developers tend to copy and paste this boilerplate code from one class to another. Since the class names are often hard-coded in the static initializer, this is a pattern that is extremely vulnerable to copy-and-paste errors. Java unfortunately doesn’t allow ‘this’ in a static context, and doesn’t have an alternative way to refer to “the current Class”.
It doesn’t offer logical organization, especially for API providers. One of the brilliant things that the Hibernate team did in their use of logging is that, in addition to FQCN-named loggers, they identified a series of key “logical” logging categories that abstracted common logging use cases into simple categories (most notably logging of all SQL statements, which can happen in many different classes using the same logical category.
There are various tricks to avoid this scenario.

Checkstyle can look for common log4j antipatterns. You’re using checkstyle anyway, right?
You can create a logger factory which will look on the call stack for the current class name (as shown here).
You can use smart annotations or DI (such as is easily done with Guice) to annotate your Loggers and fill in at runtime.

Mistake 5: Not understanding how (or where) log4j is configured

It’s amazingly common for developers not to know how to configure log4j, or even know where to start to set it up. I personally have answered many, many questions from both co-workers and forum / mailing list folks who can’t figure out how to get started with log4j. Usually this is in conjunction with 3rd party libraries like Spring or Hibernate, running in a web application.

Admittedly, the log4j documentation is not super clear on this subject, and I will attempt to cover the very common scenarios that I have seen confuse developers.

If you are running in a web application, generally the log4j configuration file will go in WEB-INF/classes. If you are building in Eclipse, you can explicitly create this directory, or (in some versions of Eclipse) place it in your Java source root directory and it will go to the right place.
If you are running in a console application, the log4j configuration file must be somewhere on your CLASSPATH.
You need to have log4j configuration defined in a file called log4j.xml (using the DOMConfigurator syntax), or log4j.properties (using the PropertyConfigurator syntax).

Reference: log4j Default Initialization Procedure

Eclipse Java Autocompletion Not Working

2010-10-05T06:41:00.000-07:00

Try restoring the default options in 'Windows > Preferences > Java > Editor > Content Assist > Advanced'

Select all in the content table .

now you have done with code completion.

Java Threads : Volatile vs Synchronized

2010-08-16T22:21:00.000-07:00

This can be best understood by looking at the effects that volatile & synchronized on a method. volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords:

int i1; int geti1() {return i1;}

volatile int i2; int geti2() {return i2;}

int i3; synchronized int geti3() {return i3;}

geti1() accesses the value currently stored in i1 in the current thread. Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it’s thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a “main” memory, and this is the memory that holds the current “correct” value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the “main” memory. So in fact, it is possible for the “main” memory to have a value of 1 for i1, for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to “main” memory or other threads.

On the other hand, geti2() effectively accesses the value of i2 from “main” memory. A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in “main” memory. Effectively, a variable declared volatile must have it’s data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value. Of course, it is likely that volatile variables have a higher access and update overhead than “plain” variables, since the reason threads can have their own copy of data is for better efficiency.

Well if volatile already synchronizes data across threads, what is synchronized for? Well there are two differences. Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block, if both threads use the same monitor (effectively the same object lock). That’s the fairly well known aspect to synchronized. But synchronized also synchronizes memory. In fact synchronized synchronizes the whole of thread memory with “main” memory. So executing geti3() does the following:

The thread acquires the lock on the monitor for object this (assuming the monitor is unlocked, otherwise the thread waits until the monitor is unlocked).
The thread memory flushes all its variables, i.e. it has all of its variables effectively read from “main” memory (JVMs can use dirty sets to optimize this so that only “dirty” variables are flushed, but conceptually this is the same. See section 17.9 of the Java language specification).
The code block is executed (in this case setting the return value to the current value of i3, which may have just been reset from “main” memory).
(Any changes to variables would normally now be written out to “main” memory, but for geti3() we have no changes.)
The thread releases the lock on the monitor for object this.
So where volatile only synchronizes the value of one variable between thread memory and “main” memory, synchronized synchronizes the value of all variables between thread memory and “main” memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.

Using the volatile keyword ensures that the variable is never kept in a register. This

guarantees that the variable is truly shared between threads.

Synchronization boundaries signal to the virtual machine that it must invalidate its registers.

When the virtual machine enters a synchronized method or block, it must reload data it has cached in its local registers. Before the virtual machine exits a synchronization method or block, it must store its local registers to main memory.

Lucene: A Tutorial Introduction to Full-Text Indexing in Java

2010-01-11T20:37:00.000-08:00

Lucene is a powerful and elegant library for full-text indexing and searching in Java. In this article, we go through some Lucene basics, by adding simple yet powerful full-text index and search functions to a typical J2EE web application.
NOTE
For your convenience, all of the code for this article’s Lucene demo is included in a source.zip file.
Full-Text Searching
Nowadays, any modern web site worth its salt is considered to need a "Google-like" search function. Complex multi-criteria search screens are often perceived by users as being too complex, and are in fact rarely used. Users want to be able to just type the word(s) they’re seeking and have the computer do the rest. This explains the growing popularity of search engines such as those of Yahoo! and Google and, more recently, tools such as Google Desktop.
If you need to add this sort of rich full-text search functionality to your Java web application, look no further! Lucene is an extremely rich and powerful full-text search API written in Java. You can use Lucene to provide consistent full-text indexing across both database objects and documents in various formats (Microsoft Office documents, PDF, HTML, text, and so on).
In this article, we’ll go through the basics of using Lucene to add full-text search functionality to a fairly typical J2EE application—an online accommodation database. The main business object is the Hotel class. In this tutorial, a Hotel has a unique identifier, a name, a city, and a description.
NOTE
We won’t worry about the underlying storage mechanism (JDBC, Hibernate, EJB 3, or whatever) or the display layer technology (JSP/Struts, JFS, Tapestry, or whatever). We’ll just focus on the business layer and the indexing and search functionalities, which are largely independent of the other architectural layers.
Creating an Index
The first step in implementing full-text searching with Lucene is to build an index. This is easy—you just specify a directory and an analyzer class. The analyzer breaks text fields into indexable tokens; this is a core part of Lucene.
Several types of analyzers are provided out of the box. Table 1 shows some of the more interesting ones.
Table 1 Lucene analyzers.
Analyzer Description
StandardAnalyzer A sophisticated general-purpose analyzer.
WhitespaceAnalyzer A very simple analyzer that just separates tokens using white space.
StopAnalyzer Removes common English words that are not usually useful for indexing.
SnowballAnalyzer An interesting experimental analyzer that works on word roots (a search on rain should also return entries with raining, rained, and so on).
There are even a number of language-specific analyzers, including analyzers for German, Russian, French, Dutch, and others.
It isn’t difficult to implement your own analyzer, though the standard ones often do the job well enough. For the sake of simplicity, we’ll use the StandardAnalyzer in this tutorial.
Next, we need to create an IndexWriter object. The IndexWriter object is used to create the index and to add new index entries to this index. You can create an IndexWriter with the StandardAnalyzer analyzer as follows:
IndexWriter indexWriter = new IndexWriter("index", new StandardAnalyzer(),true);
Indexing an Object
Now you need to index your business objects. To index an object, you use the Lucene Document class, to which you add the fields that you want indexed. A Lucene Document is basically a container for a set of indexed fields. This is best illustrated by an example:
Document doc = new Document();
doc.add(new Field("description", hotel.getDescription(), Field.Store.YES, Field.Index.TOKENIZED));
To add a field to a document, you create a new instance of the Field class. A field is made up of a name and a value (the first two parameters in the class constructor). The value may take the form of a String, or a Reader if the object to be indexed is a file.
The two other parameters are used to determine how the field will be stored and indexed in the Lucene index:
• Storing the value. Does the value need to be stored in the index, or just indexed and discarded? Storing the value is useful if the value should be displayed in the search result list, for example. If the value must be stored, use Field.Store.YES. You can also use Field.Store.COMPRESS for large documents or binary value fields. If you don’t need to store the value, use Field.Store.NO.
• Indexing the value. Does the value need to be indexed? A database identified, for example, may just be stored and used later for object retrieval, but not indexed. In this case, you use Field.Index.NO. In most other cases, you’ll index the value using the token analyzer associated with the index writer. To do this, you use Field.Index.TOKENIZED. The value Field.Index.UN_TOKENIZED can be used if you need to index a value without parsing it with the analyzer; in this case, the value will be used "as is."
For our example, we just want some fairly simple full-text searching. So we add the following fields:
• The hotel identifier, so we can retrieve the object later on from the query result list.
• The hotel name, which we need to display in the query result lists.
• The hotel description, if we need to display this information in the query result lists.
• Composite text containing key fields of the Hotel object:
o Hotel name
o Hotel city
o Hotel description
We want full-text indexing on this field. We don’t need to display the indexed text in the query results, so we use Field.Store.NO to save index space.
Here’s the method that indexes a given hotel:
public static void indexHotel(Hotel hotel) throws IOException {
IndexWriter writer = (IndexWriter) getIndexWriter(false);
Document doc = new Document();
doc.add(new Field("id", hotel.getId(), Field.Store.YES,
Field.Index.NO));
doc.add(new Field("name", hotel.getName(), Field.Store.YES,
Field.Index.TOKENIZED));
doc.add(new Field("city", hotel.getCity(), Field.Store.YES,
Field.Index.UN_TOKENIZED));
doc.add(new Field("description", hotel.getDescription(),
Field.Store.YES,
Field.Index.TOKENIZED));
String fullSearchableText
= hotel.getName()
+ " " + hotel.getCity() + " " + hotel.getDescription();

doc.add(new Field("content", fullSearchableText,
Field.Store.NO,
Field.Index.TOKENIZED));
writer.addDocument(doc);
}
Once the indexing is finished, you have to close the index writer, which updates and closes the associated files on the disk. Opening and closing the index writer is time-consuming, so it’s not a good idea to do it systematically for each operation in the case of batch updates. For example, here’s a function that rebuilds the whole index:
public void rebuildIndexes() throws IOException {
//
// Erase existing index
//
getIndexWriter(true);
//
// Index all hotel entries
//
Hotel[] hotels = HotelDatabase.getHotels();
for(Hotel hotel: hotels) {
indexHotel(hotel);
}
//
// Don’t forget to close the index writer when done
//
closeIndexWriter();
}
Full-Text Searching
Now that we’ve indexed our database, we can do some searching. Full-text searching is done using the IndexSearcher and QueryParser classes. You provide an analyzer object to the QueryParser; note that this must be the same one used during the indexing. You also specify the field that you want to search, and the (user-provided) full-text query. Here’s the class that handles the search function:
public class SearchEngine {

/** Creates a new instance of SearchEngine */
public SearchEngine() {
}

public Hits performSearch(String queryString)
throws IOException, ParseException {

Analyzer analyzer = new StandardAnalyzer();
IndexSearcher is = new IndexSearcher("index");
QueryParser parser = new QueryParser("content", analyzer);
Query query = parser.parse(queryString);
Hits hits = is.search(query);
return hits;
}
}
The search() function returns a Lucene Hits object. This object contains a list of Lucene Hit objects, in order of relevance. The resulting Document objects can be obtained directly, as shown here:
Hits hits = instance.performSearch("Notre Dame");
for(int i = 0; i < hits.length(); i++) {
Document doc = hits.doc(i);
String hotelName = doc.get("name");
...
}
As in this example, once you obtain the Document object, you can use the get() method to fetch field values that have been stored during indexing.
Another possible approach is to use an Iterator, as in the following example:
public void testPerformSearch() throws Exception {
System.out.println("performSearch");
SearchEngine instance = new SearchEngine();
Hits hits = instance.performSearch("Notre Dame museum");

System.out.println("Results found: " + hits.length());
Iterator iter = hits.iterator();
while(iter.hasNext()){
Hit hit = iter.next();
Document doc = hit.getDocument();
System.out.println(doc.get("name")
+ " " + doc.get("city")
+ " (" + hit.getScore() + ")");

}
System.out.println("performSearch done");
}
In this example, you can see how the Hit object can be used not only to fetch the corresponding document, but also to fetch the relative "score"—getScore()—obtained by this document in the search. The score gives an idea of the relative pertinence of each document in the result set. For example, the unit test above produces the following output:
performSearch
Results found: 9
Hôtel Notre Dame Paris (0.5789772)
Hôtel Odeon Paris (0.40939873)
Hôtel Tonic Paris (0.34116563)
Hôtel Bellevue Paris (0.34116563)
Hôtel Marais Paris (0.34116563)
Hôtel Edouard VII Paris (0.16353565)
Hôtel Rivoli Paris (0.11563717)
Hôtel Trinité Paris (0.11563717)
Clarion Cloitre Saint Louis Hotel Avignon (0.11563717)
performSearch done

Finite State Machine for Decimals

2009-11-10T20:16:00.000-08:00

A Finite State Machine (FSM) is a model of behavior using states and state transitions. A transition is a state change triggered by an input event, i.e. transitions map some state-event pairs to other states. As indicated in the name, the set of states should be finite. Also, it is assumed that there is a finite set of distinct input events or their categories (types, classes). Subsequently, the set of transitions is finite as well.

FSMs are one of the most widely used models in computer programming in general. In particular, FSMs are ubiquitous in programming embedded systems and for describing digital circuits. Modeling by means of FSMs has been so successful that they become adopted as a part of the Unified Modeling Language standard by Object Management Group.
What
are
they?

The origin of FSMs is finite atomata. A Finite Atomaton is a more formal notion than a FSM. It is defined as a quintuple ( A, S, s, T, F ), where:

* A is a finite non empty set of symbols (input alphabet)
* S is a finite non empty set of states
* s is an initial state, an element of S
* T is the state transition function: T: S x A -> S
* F is the set of final states, which is a subset of S

Finite automata are primarily used in parsing for recorgizing languages. Input strings belonging to a given language should turn an automaton to final states and all other input strings should turn this automaton to states that are not final.

Finite automata that additionally generate output are called transducers. In order to define a transducer, an output alphabet and output function should be specified in addition to the five components outlined earlier. The output function can be a function of a state or a function of both state and input symbol. If the output function depends on a state and input symbol, then it is called a Mealy automaton. If the output function depends only on a state, then it called is a Moore automaton.

One of the most important facts about finite automata is that instances of any regular expression can be recognized by a finite automaton. It is well-known how to build the recognizing automaton for a given regular expression. Inversely, it is known how to construct a regular expression defining a language recognized by a given finite automaton.

Automata theory studies properties of automata. For instance, it investigates how to optimize automata. In addition to the finite atomata defined above and which are also called deterministic finite automata, there are non-deterministic finite automata. Automata theory also studies so-called pushdown automata. All these topics are beyond the scope of this tutorial.
Finite
automata

The notion of finite automata is mathematically rigorous. The notion of FSMs was introduced as a less rigorous and more suitable for computer science. A FSM is defined by the following:

* a finite non empty set of states
* an initial state
* a finite non empty set of distinct input events or their categories
* state transitions
* actions

As opposed to input symbols for finite automata, any sequence of event can be a FSM input. In other words, any object can be an input entity. The only restriction on input is that all possible inputs should be classified as belonging to one of a finite number of distinct input categories (types, classes). In many simpler cases, only a finite number of distinct input objects are allowed. It is assumed that input events are then processed synchronously, that is, the next event is processed only after the current event is fully consumed and a transition is executed if necessary. This may require queing events before the time comes to process them.

One other important difference between finite automata and FSMs is that actions may be related to FSMs. The role of actions is to generate output. FSMs may also communicate with other processes by means of actions. Presumably, actions do not generate input events. In other words, FSMs consume external events only. Also, actions are stateless, i.e. they cannot carry any information from one invocation to another. Actions may be associated with transitions, and if so, such FSM is called a Mealy machine. The FSMs in which actions are associated with states are called Moore machines. Since actions can be represented by virtually any program (code) and action input can be any object, the functionally of FSMs may be quite rich, going far beyond the limits of finite automata.
Definition

FSMs are most commonly represented by state diagrams, which are also called state transition diagrams. The state diagram is basically a directed graph where each vertex represents a state and each edge represents a transition between two states.

Another common representation of FSMs is state transition tables. In these tables, every column corresponds to a state, every row corresponds to an event category. Values in the table cells give the states resulting from the respective transitions. Table cells also can be used for specifying actions related to transitions.

opened closed
pass closed
coin opened
Diagrams
etc.

FSM specifications are pretty simple and 'flat'. Harel introduced hierarchical FSMs (statecharts) in which any state can be another FSM. The aim of this extension is to reduce the size of FSM specifications. In practice, the number of FSM transitions grows rapidly when the number of states grows. This happens because it is necessary to copy existing transitions for newly introduced states. The hierarchical FSMs solve this problem by bringing the possibility to encapsulate newly introduced states within a FSM that corresponds to one state of the next upper level. And the next-level transitions become applicable to the entire FSM of this lower level. Yet another extension of FSMs is introduced by allowing sequences of events to define transitions

This is a finite state machine that recognizes decimal numbers such as 123 and 0.123 and .789

It will not recognize strings such as 1.2.3 or 1a

public class Hello{

final static int A = 1;
final static int B = 2;

public static boolean fsm(String s){
int state = A;
for (int i=0;i

Finite State Machine for String Literals

A String Literal is a double quote " followed by any sequence of characters (other than a double quote) followed by a double quote.

Acceptable string literals: "one two" and ""

Unacceptable strings one and "one

public class Hello{

final static int A = 1;
final static int B = 2;
final static int C = 3;

public static boolean fsm(String s){
int state = A;
for (int i=0;i int newState = 0;
char c = s.charAt(i);
switch (state){
case A: if (c=='"') newState = B;
break;
case B: if (c!='"') newState = B;
if (c == '"') newState = C;
break;
}
state = newState;
}
return state==C;
}

public static void main(String argv[])
{
System.out.println(fsm("\"one two\""));
System.out.println(fsm("\"\""));
System.out.println(fsm("one"));
System.out.println(fsm("\"one"));
}
}

- : Mediator pattern : -

2009-09-10T22:38:00.000-07:00

Introduction

The Mediator is a behavioral design pattern that provides a central hub to guide the interactions between many objects. According to Gamma et al, the intent of the Mediator pattern is to,

"Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." (Gamma et al., 1995)

You will find on this page, a detailed, and hopefully useful, investigation into the various aspects of this relatively simple, yet powerful design pattern.

Air Traffic Controller Example

Before we explore the Mediator pattern in any depth, first consider the example of an air traffic controller, and the various aircraft it helps to guide (Bains K., Lau E., 2002).

Imagine what would happen if there were no air traffic controllers. Each and every aircraft would have to know about every other aircraft in order to avoid collisions with them. This would certainly be a cause for disaster, as it would be far too difficult for each plane to keep track of all other aircraft in the vicinity.

So, to remedy this, we have the air traffic controller. Instead of having all aircraft communicating directly with one another, they simply send the controller their flight data and the controller then decides what other aircraft need to be informed. This is clearly far more efficient, and in this case, much safer, than the alternative. This is a perfect example of the Mediator pattern in the real-world.

Structure

Expressed in UML, a Mediator pattern may be structured with a handful of simple classes and interfaces (Figure 1.).

Figure 1: Mediator Structure

So an example implementation, in the context of the air traffic controller described earlier, could also be structured in UML (Figure 2.).

Figure 2: Air Traffic Controller Example Structure

The sequence of events that may occur between the objects involved in our air traffic controller example, can be expressed using a sequence diagram (Figure 3.).

Figure 3: Air Traffic Controller Example Sequence Diagram

More or less, this is how the Mediator design pattern works. Colleagues inform the Mediator of particular events, and the Mediator then decides what other colleagues should be informed.

Participants

There are three participants in the Mediator pattern (Figure 1.):

Mediator: defines an interface for communicating with Colleague objects (Gamma et al., 1995).
ConcreteMediator: is the object that coordinates the Colleague objects and is in charge of the messages they wish to send to each other. A ConcreteMediator knows and maintains its Colleagues (Gamma et al., 1995).
Colleague classes: each Colleague class knows its Mediator object, and communicates with it whenever it would have otherwise communicated with another Colleague (Gamma et al., 1995).

Applicability

According to Gamma et al, the Mediator pattern should be used when (Gamma et al., 1995):

a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand.
reusing an object is difficult because it refers to and communicates with many other objects.
a behaviour that's distributed between several classes should be customizable without a lot of subclassing.

Consequences

As with most design patterns, there are both advantages and disadvantages to using the Mediator. The following section will briefly outline a few of these issues.

Advantages

Comprehension: Since the Mediator hides all coordination activities that it implements, the user is better able to understand the system and the interactions that that the Colleagues make.
Decoupled Colleagues: Colleagues can be added/removed/modified easier as they depend less on each other. This also goes between the Colleague and its Mediator- they can be used independently.
Ease of Protocols: The Mediator makes sure that there are only a few centralized access points. The one-to-many relationship of the Mediator is much preferred to over the many-to-many relationship among Colleagues. (Black, 2004)
Limits Subclassing: The Mediator localizes behavior. Only the Mediator needs subclassing when changing behavior; the Colleagues can remain the same.

Disadvantages

Complexity: Because the Mediator may handle a potentially large number of Colleagues, the contents of the Mediator may be very complex. Thus, it could be difficult to modify its and understand its contents.

Examples

Parliament

The House of Commons in the Parliaments of Canada, England and many more countries are also excellent real-life examples of the mediator pattern. According to protocols established hundreds of years ago, Members of Parliament (Colleagues) may never address each other directly. All comments are instead directed to the Speaker of the House (the Mediator). Further, it is a breach of protocol to refer to a member by name. All members are referred to as "The Honourable Member from [district]" or "My good friend from [district]." This is analogous to addressing Colleague classes by their "interface" and not by their actual "implementation".

Chatroom

To illustrate a possible use of the Mediator pattern, we have chosen to present an example chatroom application (Data & Object Factory, 2004) in Java. In this particular example, the Forum acts as the abstract Mediator, and the PoliticalForum is the concrete implementation of it. We then have a couple of Colleague implementations: MemberOfParliament, and PrimeMinister (PrimeMinister is actually a subclass of MemberOfParliament, so it too is a Colleague). By having each Colleague aware of the Forum they're participating in, they can send messages without actually referencing one another.

Known Uses

In the following sections, we'll discuss some real-world uses of the Mediator pattern. You'll find the Mediator in many situations where there are many components that must interact with one another in complex ways.

User Interfaces

Perhaps the most common use for the Mediator pattern we've come across, is that in graphical user interfaces (Gamma et al., 1995), where a change in one control, may change the state of other controls. Instead of having the instantiating control know about all other possible controls that may need to know about changes, we

Java Message Service

Another use for the Mediator pattern is in messaging services between remote applications. For instance, the J2EE Java Message Service (Armstrong et al., 2004) provides applications with the ability to subscribe, and publish data to other applications in an asynchronous manner. Clearly, this is a variation of the Mediator, as it incorporates the Observer pattern for providing the publish and subscribe functionality, but this is a very common variation, and is worth mentioning.

Previous Experience

Our most common encounter with the Mediator pattern thus far has surely been in writing user interfaces; a task that dictates the use of many objects that often need to communicate with one another.

As mentioned earlier, the Mediator is well suited for coordinating changes between related controls in graphical user interfaces, and we would tend to agree. Instead of placing the code that deals with 'notifying' other controls of changes within the controls themselves, we've often found ourselves creating 'notification' methods within the container class, such as notifyFontChange(), that actually execute the various methods required to update the appropriate controls. This has helped us to reduce duplication of code, made changes to the UI far less painful, and made the code itself far easier to understand.

Conclusion

It would be difficult for us to deny the sheer simplicity and usefulness of the Mediator pattern. By providing the loose coupling between Colleague objects and centralizing the interaction logic in the Mediator, changes are more easily facilitated, and code clarity is heightened.

While we haven't encountered this yet ourselves, we can easily foresee Mediator implementations becoming very large and complex when it must deal with a very large or unknown set of Colleagues. In such cases, we feel that using the Observer pattern would actually help a great deal, by placing the interaction logic back into the Colleagues. Colleagues in this case would then publish and subscribe to events that affect them, and would deal these events themselves. The Mediator would then only provide the means by which Colleagues may inform one another of such events. Such a Mediator is actually provided by the Java Message Service, as we mentioned earlier.

Java performance guidelines-Part I

2009-08-10T21:18:00.000-07:00

* Use the StringBuffer function instead of string concatenations when doing excessive string manipulations to avoid unnecessarily creating objects that eventually must undergo garbage collection.

* Avoid excessive writing to the Java console to reduce the cost of string manipulations, text formatting, and output.

* Avoid the costs of object creation and manipulation by using primitive types for variables when necessary.

* Cache frequently-used objects to reduce the amount of garbage collection needed, and avoid the need to re-create the objects.

* Group native operations to reduce the number of Java Native Interface (JNI) calls when possible.

* Use synchronized methods only when necessary to limit the multitasking in the JVM and operating system.

* Avoid invoking the garbage collector unless necessary. If you must invoke it, do so only during idle time or some noncritical phase.

* Use the int type instead of the long type whenever possible, because 32-bit operations are executed faster than 64-bit operations.

* Declare methods as final whenever possible. Final methods are handled better by the JVM.

* Use the static final key word when creating constants in order to reduce the number of times the variables need to be initialized.

* Avoid unnecessary "casts" and "instanceof" references, because casting in Java is done at run time.

* Avoid the use of vectors whenever possible when an array will suffice.

* Add and delete items from the end of the vector.

* Compile Java files with the -O option.

* Avoid allocating objects within loops.

* Use buffer I/O and tune the buffer size.

* Use connection pools and cached-prepared statements for database access.

* Use connection pools to the database and reuse connections rather than repeatedly opening and closing connections.

* Maximize and minimize thread creation and destruction cycles.

* Minimize the contention for shared resources.

* Minimize the creation of short-lived objects.

* Avoid remote method calls.

* Use callbacks to avoid blocking remote method calls.

* Avoid creating an object only used for accessing a method.

* Keep synchronized methods out of loops.

* Store string and char data as Unicode in the database.

* Reorder CLASSPATH so that the most frequently used libraries occur first.

A brief explanation of the ISO-8583 protocol

2009-06-29T04:37:00.001-07:00

The objective of this protocol is to transmit information for payment processing through a network, usually using TCP/IP sockets. An ISO8583 message can have up to 63 or 127 fields and is processed in a linear way, that is, the message can be processed as it is being read.
Message format

A simple ISO8583 is comprised of the following:

* Message type: Indicates if the message is a request or a response, and what type of transaction it is.
* Bitmap: The bitmap indicates the fields contained in the message. It is a binary string of 64 bits, in which every bit corresponds to a field, indicating which fields are included in the message.
* Fields: Fields are included after the bitmap. There are different field types and the message does not indicate the type of field; this has to be defined previously on a specification (there is a certain standard for some common fields but some implementations do not follow it, so it is very important to always review the specification for the specific implementation you will work on).

The first field is a special field and contains a secondary bitmap. If the first bit of the primary bitmap is on, then the first field after the bitmap is another bitmap, also 64 bits long, indicating additional fields from 65 to 128.
Field types

From the second field to the last one, the message contains only "normal" fields, which can have the following datatypes:

Alpha:
Can contain a fixed number of characters and digits. The length is previouly established in the spec for the particular implementation. If the contents are shorter than the field length, it must be filled with spaces to the right.
Numeric
Can contain only digits with a fixed length. The length is previously established in the spec for the particular implementation. If the number is shorter than the field length, it must be zero-filled to the left.
LLVAR
This is an alphanumeric field of variable length. It has a 2-digit field header at the beginning, indicating the length of the rest of the field, which can be 0 to 99.
LLLVAR
Also an alphanumeric field of variable length, but the field header is 3 digits long, so the rest of the field can be 0 to 999 characters long.
Date/Time
There are three different date formats: A 10-digit format MMDDHHmmss, a 4-digit format YYMM (useful for expiration dates on credit cards), another 4-digit format MMDD. The time is specified as 6 digits in format HHmmss.
Amount
This is a 12-digit numeric field expressing a currency amount in cents. For example $15.00 is expressed as 000000001500.

Message types

The most common message types are:
0200 Request for payment, credit card charge, etc.
0210 Response to payment, credit card charge, etc.
0400 Request for reversal of payment, credit card charge, etc.
0410 Response to reversal of payment, credit card charge, etc.
0600 Query
0610 Response to query
0800 Echo request
0810 Echo response
Encoding

ISO8583 messages can be encoded as ASCII or binary; ASCII is more common. In this format, the message type is 4 bytes long, because the characters for it are sent as text, ie. "0200". In binary encoding, the message type is 2 bytes long, for example message type 0200 is encoded as byte 0x02 and byte 0x00.

In ASCII encoding, the bitmap is sent using hex encoding, so it's 16 characters long; that is, every 4 bits are a hex digit. For example, if the message includes fields 1 and 3 but not 2 or 4, then the first 4 bits are 1010 which is 0xA. In binary encoding, the bitmap is sent as 8 bytes, without encoding them in any way.

Numeric and alpha fields in ASCII have the same length in bytes as they do in characters or digits; numeric fields are sent as text, for example "000012".

In binary encoding, numeric fields are encoded using BCD (Binary Coded Digits), which means taking 2 digits and encoding them as hex, that is, the number 12 is encoded as 0x12; this way, a byte can always contain 2 digits. Numbers with an odd number of digits (such as the length header for a LLLVAR field) will have a zero to the left, for example 128 is encoded as two bytes: 0x1 and 0x28.

ASCII-encoded LLVAR and LLLVAR fields will have 2 or 3 character headers.

Binary encoded LLVAR and LLLVAR fields will have 1 or 2 byte headers; LLVAR fields have their header as a 1-byte BCD number, for example if the header is 0x57 it means that the field is 57 bytes long. LLLVAR fields have 2-byte BCD headers but the first digit is always 0; for example if the header is 0x128 it means the field contents are 128 bytes long.

Date and amount fields, being numeric, are encoded as any other numeric field. For example a full date field will be 10 characters long in ASCII encoding but only 5 bytes long in binary encoding.
ISO header

In some implementations, messages must include a header before the message type. This is implementation-specific and the headers usually vary only by message type.

Additionally, it is very common to include a header with the length of the message when sending ISO8583 over a network. The header is usually 2 bytes long and is a binary unsigned integer with the length of the full message, thus making the reading on the other side easier, since the process consists of reading 2 bytes, interpreting them as a length, and then reading that many bytes. The byte order is usually most significant byte first, but it can vary in certain implementations.

Sometimes there is also a message terminator, which can be included in the length or not, depending on implementation. Message terminators are usually just 1 byte long.
Examples

Here are some examples of ISO8583 messages, along with the XML definition to parse them with the j8583 framework. ASCII encoding is being used for these.

ISO015000050

ISO015000055

ISO015000050

ISO015000055

ISO015000015

How to play Bin and CUE files

2009-06-24T23:08:00.000-07:00

If you have downloaded .bin and .cue files and you are sure that they are video content, then this article will tell you your options on how to play them.

About BIN and CUE files

BIN and CUE files make up a very popular CD Image format. Specifically, the BIN file contains all the contents that would be included on a CD, whereas the CUE file just has track information. You can view a CUE file in notepad for example for more information.

What can BIN and CUE files contain?

Anything you can find on a CD really, like games, software, VideoCD (VCD), Super VideoCD (SVCD) etc. In this article we will show you how to access that data in many different ways and provide burning instructions for BIN and CUE files. Since this is a playback guide though, it is assumed that you have either a VCD or SVCD compilation.

Easiest Solution

Download and install the VLC player. The VLC package is already capable of playing bin / cue image files directly if they are VCD or SVCD.

You can get VLC for Windows from this URL.

Click File and click the Open File option.

Now, click the Browse button next to the first white line at the top of the window with title "Open.." and navigate through your harddrive for the video you wish to watch and select it (select the CUE file). After you have selected the video, click OK and VLC will start playing the video you chose.

For other Operating Systems...

Mac: http://www.afterdawn.com/software/alternative_platforms/mac_software/vlc_for_mac.cfm

Linux: http://www.afterdawn.com/software/video_software/video_players/vlc_linux.cfm

Media Player Classic

Another easy solution is to play the files in Media Player Classic. While you are browsing for files to open with MPC, it will now automatically show bin and cue files. Instead you would have to switch File Type to "All Files". Unlike VideoLan Client, you have tom play the .bin file in this case.

Burn bin & cue files

Since .BIN/.CUE files are CD images, they are designed to be burned to blank CD media. In order to do this, follow this guide.

VCD and SVCD work in most modern DVD players.

Extract MPEG Files

Since your BIN / CUE files are most likely VCD or SVCD (if you are certain it should be video content you have), you can extract the MPEG video streams directly from the bin file. To do this, you will need IsoBuster.

IsoBuster

IsoBuster is an excellent tool for making CD images. Download Isobuster from AfterDawn and install it. On its first run, it will look like the picture beside this text if you don't have a CD in any of your drives.

In order to extract MPEG streams from bin/cue images you now need to open the CD image. To do so, click File --> Open Image File.

Browse to the folder with the bin and cue files in it and open the .CUE file.

The Image file will now open and you should be able to see the folders on the disc. Usually, if there is an MPEGAV folder, then you have a VCD, which contains MPEG-1 video streams. If you have an MPEG2 folder you definitely have an SVCD. Open the folder to find MPEG file(s) in it. Please note that sometimes (most often with VCD), there will be files with .DAT extension. These are MPEG video files despite the extension.

Extracting these files as is, is not a good idea. Instead, IsoBuster can extract them and convert them to compliant files also. To do this, right click on the AVSEQXX.MPG or AVSEQXX.DAT file(s) (XX representing the number of the file) and select Extract but FILTER only MF2F MPEG frames.

Select a target filename and directory and then the program will begin extracting the MPEG data.

Java Tool : JAR anatomy

2009-06-14T23:55:00.000-07:00

JAR files are Java's version of ZIP files. In fact, JAR uses the ZIP file format. There are two main uses for JAR files which I shall explain here. The first use is to compress (make a smaller size) a number of files into one file (archiving). The second use is to make a Java executable JAR file.

Compress Files To A Java Archive (JAR)

This is by far the most common use for JAR files: to compress multiple files into a single JAR archive. JAR files can be opened with WinZip or WinRar. In terms of Java applications, the ability to archive any number of source or class files into one single archive represents the biggest advantage - distributing one file containing hundreds of files is so much easier than distributing hundreds of files separately!

The jar utility program is run from the command line (DOS prompt or bash for example, depending on your OS). Here is how to create a compressed JAR file:

jar cf archive_name.jar files

Let's look at each part of that command line.

jar

The command to run the jar utility.

CF

Create a new archive with the file name specified. These two options are from this list of common options:

- c create new archive
- t list table of contents for archive
- x extract named (or all) files from archive
- u update existing archive
- v generate verbose output on standard output
- f specify archive file name
- m include manifest information from specified manifest file
- 0 store only; use no ZIP compression
- M do not create a manifest file for the entries
- i generate index information for the specified jar files
- C change to the specified directory and include the following file

Multiple options can be used together. They all must appear after the "jar" command with no white space separating them.

archive_name.jar

Name of the JAR file. This can only be included if you use the 'f' option.

files

Names of all the files you want to put in the jar file. This could be just one name or a list of multiple names separated by space. Names can use pattern matching characters to match multiple files.

Common Examples

Let's say I have a Java application consisting of three source files that I wish to distribute:

One.java
Two.java
Three.java

I also want to call my JAR file example.jar. To make a JAR file with just One.java:

jar CF example.jar One.java

To make a file with all three files listed separately:

jar CF example.jar One.java Two.java Three.java

To make a file with all three files using a pattern match:

jar CF example.jar *.java

It goes (almost) without saying that the source files are in the same directory you are running the jar command in.

Compress Files To An Executable Java Archive (JAR)

It is also possible to make an archive that can be executed (run) by Java and even by a double click through your OS, if you have it set up correctly. Of course, to do this you must store compiled class files in the archive, as well as or instead of Java source files, since Java source files cannot be run!

Continuing the example above, I now compile my Java source files:

javac *Java

or

javac One.java Two.java Three.java

Create An Executable JAR

All JAR files contain something called a manifest file which holds information Java wants to know. One piece of information a manifest file may contain is the name of a class that will be run if the JAR file is executed.

The first thing you must do is create a text file that lists the "main" class - the class that has the main method you want executed when the JAR is executed. Let's say that Three from the above example has the main method I want executed. I create a text file called "mainClass.txt" with the following text:

Main-Class: Three

IMPORTANT: the text file only needs the one line of text for this purpose. However, the file must end with a blank line or this will not work, ie the file has two lines in it - the second one is empty. Note too the class is called "Three" and not "Three.java" (the file containing the source code) or "Three.class" (the file containing the byte codes). If your class file is in a package hierarchy, you must use the fully qualified name of the class (eg "myPackage.MyClass").

I then run the jar utility with this command line:

jar cmf mainClass.txt example.jar *.class

With this line, I told jar to create a JAR file (option c) with modifications to the manifest file (option m) as specified within mainClass.txt, naming the JAR file (option f) as example.jar and including everything that matches the pattern *Class

Running An Executable JAR From Command Line

I can run it from the command line like this:

java -jar example.jar

Within Windows, it is also possible to set up Windows Explorer so that you can double click on the JAR file icon to execute the file (handy for GUI applications). The first thing you must do is set up the correct association with the 'javaw.exe' application that JDK for Windows will have. Click here for an older example with pictures! Open Windows Explorer and select Tools | Folder Options | File Types.

If there is no JAR file type, create it. Give it a description like

jar - Executable Jar File

to ensure it sorts under 'jar'. Create or edit the action called "open" and associate it with the following action:

"C:\Java\jdk1.4.0\bin\javaw.exe" -jar "%1"

Of course, you will replace "C:\Java\jdk1.4.0\bin\javaw.exe" with whatever path is correct on your machine.

IMPORTANT: include the double quotes to take care of names with spaces.

Some useful Tips

1. jar command can also operate on zip files. I usually run jar tvf hello.zip to quickly view its content, without starting up the WinZip program. jar xvf hello.zip should also be able to expand the target zip files. I find it hard to memorize Unix zip/unzip command line options, so I just use jar tvf/jar xvf instead. For example:

C:\tmp>jar tvf eclipse-SDK-3.2RC7-win32.zip

2. jar tvf can selectively list table of contents for archive. I used to run jar tvf j2ee.jar | grep javax/servlet/http to search for servlet classes in j2ee.jar. Replace grep with findstr on Windows. In fact, I don't need grep or findstr; I can just run this command:

jar tvf j2ee.jar javax/servlet/http

Note that the search criteria are matched against the beginning of all entries in jar file. It uses String.startsWith(what) rather than String.contains(what). So this command jar tvf j2ee.jar ejb will not return any matching entries, though jar tvf j2ee.jar javax/ejb will return all ejb classes. The search is also case-sensitive.

If you want case-insensitive search, or match by any parts (not just the beginning) of entries, you still need to use jar tvf my.jar | grep -i aNynAmE

3. You can extract selected entries from a jar file. For instance, if you only want to view the meta-inf/manifest.mf file, you can

C:\Sun\AppServer\lib>jar xvf j2ee.jar META-INF/MANIFEST.MF
inflated: META-INF/MANIFEST.MF

Or using a backslash instead of a forward slash:

C:\Sun\AppServer\lib>jar xvf j2ee.jar META-INF\MANIFEST.MF
inflated: META-INF/MANIFEST.MF

The entry names are case sensitive, and so the following will not extract anything:

C:\Sun\AppServer\lib>jar xvf j2ee.jar meta-inf/manifest.mf

Of course, you can always double-click the entry to view it in WinZip, fileroller, or other tools.

4. You can choose not to have manifest file when creating a jar file, using M option:

jar cvfM no-meta.jar A.class
adding: A.class(in = 405) (out= 279)(deflated 31%)

Note: it's upper-case M. Lower-case m has a different meaning.

5. You can specify your own manifest file when creating a jar file, using m option:

jar cvfm my-meta.jar my-meta-inf\my.mf A.class
added manifest
adding: A.class(in = 405) (out= 279)(deflated 31%)

The option used here cvfm tells the jar command that the destination file (f) will come next and then custom manifest file (m). I can also specify them in a different order:

jar cvmf my-meta-inf\my.mf my-meta.jar A.class
added manifest
adding: A.class(in = 405) (out= 279)(deflated 31%)

It's lower-case m. Upper-case M has a different meaning.

6.META-INF/MANIFEST.MF file in source files is always ignored.

jar cvf ignore.jar A.class META-INF
added manifest
adding: A.class(in = 405) (out= 279)(deflated 31%)
ignoring entry META-INF/
adding: META-INF/LICENSE.txt(in = 2657) (out= 1185)(deflated 55%)
ignoring entry META-INF/MANIFEST.MF

When it comes to manifest files for new jar file, you only have 3 options:

* Do not specify any manifest-related options and use the default MANIFEST.MF

* Use option M not to include a manifest file

* Use option m to use a custom manifest file. Inside the jar file, this file will always be named MANIFEST.MF under META-INF directory. Outside of the jar file, this custom manifest file can be anywhere and have any name.

7. If you unjar an archive, do nothing, and then jar it up again, the resulted new archive may not equal to the original one. And applications using this new archive may not work correctly because of the wrong manifest file. The original jar may have a custom manifest file, which is expaned into META-INF/MANIFEST.MF. But when you jar these files up again without using cvfm option, this custom manifest file is ignored and a default MANIFEST.MF is included.

8. jar command options can start with optional -. jar tvf a.jar is the same as jar -tvf a.jar

9. You would usually use relative paths for source files, relative to the current directory. These relative paths will be preserved inside the target jar file. For example, jar cvf \tmp\b.jar com\javahowto\test\ will create the directory tree com\javahowto\test\ inside the target jar, and include all files under \com\javahowto\test\.

If you use absolute paths for source files, jar will copy the absolute paths inside the jar file, which is not what you want. For example,

C:\tmp>jar cvf a.jar C:\tmp\A.class
added manifest
adding: C:/tmp/A.class(in = 405) (out= 279)(deflated 31%)

10. If source files are not located in the current directory, you can use -C option to tell jar command to implicitly change to another directory and then include files there. For example,

C:\ws\nb\scrap\dist>jar cvf hello-world.jar -C ..\build\classes com\javahowto\test

11. If you use -C ../build/classes option and want to include all files under ../build/classes, use . (dot) to represent all files there. Note that you can't use *, which will resolve by OS to all files to the current directory. For example,

C:\ws\nb\scrap\dist>jar cvf hello-world.jar -C ..\build\classes .

The following example (using -C and *) will ignore -C option and instead include all files in the current directory, which is not what we want:

C:\ws\nb\scrap\dist>jar cvf hello-world.jar -C ..\build\classes *
..\build\classes\com\hello-world.jar : no such file or directory
added manifest
adding: scrap.jar(in = 20487) (out= 7472)(deflated 63%)

12. There are 3 types of paths in jar command:

* path to the destination jar file, either relative or absolute path is fine. In fact, any format is ok as long as it can be correctly resolved by the OS

* path to the manifest file, if m option is present. Either relative or absolute path is fine. The same as destination file.

* multiple paths to source files. They should be relative to the current directory, unless -C option is present. In that case, all source files should be relative to the value of -C option.

If you don't like using -C option, I'd suggest you always cd into the parent directory of all source files, and then run jar command.

13. It is not possible to include source files from multiple different parent directories. But you can always first copy them into a common parent directory. Jar task in Apache Ant is more flexible and can accommodate almost all use cases.

14. In JDK 6 or newer version, you can use e option to specify an entry-point class (Main-Class in META-INF/MANIFEST.MF) for self-contained applications packaged in a jar file. See this post for details.

How to Find out the IP address assigned to eth0 and display IP only

2009-06-11T01:45:00.000-07:00

For shell script or may be for other cause you may need the IP address only. You can use ifconfig command with grep and other filters.

Default output of /sbin/ifconfig command is all interfaces:
$ /sbin/ifconfigOutput:

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:69527 errors:0 dropped:0 overruns:0 frame:0
TX packets:69527 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:41559546 (39.6 MiB) TX bytes:41559546 (39.6 MiB)

eth0 Link encap:Ethernet HWaddr 00:17:9A:0A:F6:44
inet addr:192.168.2.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::217:9aff:fe0a:f644/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:227614 errors:0 dropped:0 overruns:0 frame:0
TX packets:60421 errors:0 dropped:0 overruns:0 carrier:0
collisions:272 txqueuelen:1000
RX bytes:69661583 (66.4 MiB) TX bytes:10361043 (9.8 MiB)
Interrupt:17

ra0 Link encap:Ethernet HWaddr 00:50:56:C0:00:01
inet addr:192.168.1.2 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1024 errors:0 dropped:0 overruns:0 frame:0
TX packets:1320 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Now you just select eth0 as follows:
$ /sbin/ifconfig eth0

Now you just wanted the IP address, use grep to get the IP:
$ /sbin/ifconfig eth0| grep 'inet addr:'Output:

inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0

To get IP address from use cut command:
$ /sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2Output:

192.168.2.1 Bcast

Finally remove Bcast with awk
$ /sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}'

Implemating MEDIAWIKI

2009-05-19T21:28:00.000-07:00

MediaWiki requires much more manual work to install than MoinMoin Wiki. Unfortunately, I was unable to find a comprehensive guide detailing how to go from scratch to fully operational wiki. There is the Installation Guide which details the basic server setup. It then redirects you to two pages: one on configuration and one on administration. Most of these documents are fine but at the time of this writing the ‘configuration’ document is fairly empty and I was left wondering about many configuration options. Hence this guide which will try to tie together all the things you need in order to get up and running.

To keep things moving this guide will be written at a fairly advanced level. If you don’t feel comfortable installing server side software you may want to check out some of our other How To’s for inspiration.

These instructions are suitable for FreeBSD 5.3-RELEASE-p37 and MediaWiki 1.9.3, although you will probably find it useful regardless of the platform and MediaWiki version you use.
Basic Installation

This part is covered very well by the Installation page of MediaWiki. Here’s the super condensed FreeBSD take on installation:

To install MediaWiki in FreeBSD,

# cd /usr/ports/www/mediawiki
# make install

This will install MediaWiki into /usr/local/www/mediawiki/, by default. You will probably want to copy this installation to some other folder since MediaWiki changes files in its installation folder during use.

# cp -Rf /usr/local/www/mediawiki /www/mywiki

Then,

1. Make sure the config folder is writable by the httpd user (www usually).
2. Set up your web server to serve pages from the location.
3. Surf to your new wiki. You will be prompted to go through an installation procedure. This part is very straight forward.
4. Move config/LocalSettings.php to the root of the wiki installation. You can now delete the config folder.

Now that was the easy part. Here comes the stuff that took a little bit longer to figure out. Thanks to Playing With Wire you’ll be able to do it in minutes! :)
Additional Manual Configuration

The installer does some things but not everything. While many online applications such as WordPress come with fancy online configuration tools, MediaWiki uses more traditional configuration files which you’ll be editing by hand.

Here’s what you’ll need to do:

1. Copy AdminSettings.sample to AdminSettings.php in the base folder. Edit the new file. The config file requires you to configure a database account for maintenance scripts. Presumably you may use the same account you used for the wiki, although I didn’t run any of the maintenance scripts yet to test this.
2. Edit LocalSettings.php. This file has been created for you by the installer, so it will contain some good defaults.

LocalSettings.php is the primary configuration file of your new wiki. This file contains the actual basic settings for MediaWiki, and it overrides the defaults found in includes/DefaultSettings.php. You shouldn’t edit DefaultSettings.php directly, but it should be your first stop if you’re wondering what variables you can put in LocalSettings.php.
Linking up the Help Pages

By default MediaWiki ships without help pages. Unless you want to write them yourself you have a couple of options. The option I chose is to simply copy all Help sections from the primary MediaWiki site - they’re released into the public domain. Follow the instructions on Help:Copying to do this.

You may wish to export the following pages:

Help:Contents
Help:Navigation
Help:Searching
Help:Tracking_changes
Help:Editing_pages
Help:Starting_a_new_page
Help:Formatting
Help:Links
Help:Categories
Help:Images
Help:Templates
Help:Tables
Help:Variables
Help:Managing_files
Help:Preferences
Help:Skins
Help:Namespaces
Help:Interwiki_linking
Help:Special pages
Template:PD_Help_Page
Template:Meta
Template:Admin_tip
Template:Prettytable
Template:Hl2
Template:Hl3
Template:Thankyou
Image:Example.jpg
Image:Geographylogo.png
Help:Editing
Image:PD-icon.svg

This is the same list as found on the Help:Copying page at the time of this writing, with the addition of the two last entries.

Notice that Template:Languages isn’t included in this list, although it is referenced from Template:PD_Help_Page. You may wish to edit the PD Help Page template and remove the {{Languages}} part towards the end to get rid of this dependency.

You will have to download and upload the images separately by clicking them and finding their respective file downloads. Upload the images using the normal ‘Upload file’ link from your wiki. The .svg image probably won’t upload by default. We’ll tackle the SVG format later.
Nice URLs

At this point the installer script has probably given you URLs that look like,

http://www.yourdomain.com/index.php/My_Page

(Unless your PHP runs as a CGI script in which case things might even look worse. Don’t run as CGI.)

To make your URLs more readable, you’ll need to configure both your web server and MediaWiki to cooperate. Here’s a good resource: Using a very short URL.

Basically you will want to edit your httpd.conf, if you can do that, or an appropriate .htaccess file, if you have to. Remember that a .htaccess file is slower than httpd.conf. If you can use httpd.conf, do that and disable .htaccess support.

Here’s how to set things up within Apache’s httpd.conf. Edit your Directory entry to resemble the following:

Options Includes FollowSymLinks

AllowOverride None

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

Notice the AllowOverride None line. This is the part that turns off .htaccess support. It’ll give you a bit of a speed boost since your web server won’t have to look for a .htaccess file for every request made.

Next, add this line to LocalSettings.php:

$wgArticlePath = "$wgScriptPath/$1";
Change the Wiki Theme or Looks

MediaWiki’s term for themes is ’skins’. The default skin looks exactly like Wikipedia, so you may want to change this if you’re looking to achieve a spiffy unique look for your public wiki.

To find out what skins came with your MediaWiki installation, look in your skins/ folder. You will see something like,

# ls skins
Chick.deps.php Nostalgia.php common
Chick.php Simple.deps.php disabled
CologneBlue.php Simple.php htmldump
MonoBook.deps.php Skin.sample monobook
MonoBook.php SkinPHPTal.sample myskin
MySkin.deps.php Standard.php simple
MySkin.php chick

From this list you can infer the list of available skins. In this case it looks like we have Chick, CologneBlue, MonoBook, MySkin, Nostalgia, Simple and Standard. The folder names (the lower case names) are the skin names.

To make the change, edit your LocalSettings.php file again and alter the line that reads,

$wgDefaultSkin = ...

In our case we might put,

$wgDefaultSkin = 'cologneblue';

If you make a mistake setting the property you will get a default skin.

You can find more skins here. Each skin is accompanied by instructions for how to set it up. Normally this involves downloading a zip file and unzipping it into the skins/ folder. You may also have to edit theme files to set up proper paths.
Changing User Access Levels

If you want to disable anonymous editing, you can add something like the following to LocalSettings.php:

$wgGroupPermissions['*' ]['createaccount'] = true;
$wgGroupPermissions['*' ]['read'] = true;
$wgGroupPermissions['*' ]['edit'] = false;
$wgGroupPermissions['*' ]['createpage'] = false;
$wgGroupPermissions['*' ]['createtalk'] = true;

For other possible settings, take a look at the defaults provided in includes/DefaultSettings.php. Again, remember not to edit the defaults file: just copy the lines you want to change to LocalSettings.php and make your changes there.
Support for SVG images

The SVG image file format is very useful but turned off by default in MediaWiki. Look in include/DefaultSettings.php and locate the SVG related stuff. For my installation this is what I had to add to LocalSettings.php:

$wgSVGConverter = 'inkscape';
$wgSVGConverterPath = '';
$wgSVGMaxSize = 1024;
$wgMaxImageArea = 1.25e7;
$wgThumbnailEpoch = '20030516000000';
$wgIgnoreImageErrors = false;
$wgGenerateThumbnailOnParse = true;

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'svg' );

You will also need to install inkscape. There are options to use rsvg, ImageMagick and others instead but none of those options worked for me. Rsvg and ImageMagick didn’t render gradients right, and I was unable to install the other alternatives on FreeBSD without crashes or other problems. This is unfortunate because inkscape is positively enormous if you also consider all the pre-requirements that you normally wouldn’t have to install on a server. It is the one program that does things right though and SVG is a really nice format to have support for.

Implementing the callback pattern in Java

2009-05-14T03:05:00.000-07:00

A callback in programming is executable code that is passed as an argument to other code. The higher-level code usually starts by calling a function within the lower-level function, passing to it a pointer, or handle to another function.

When the lower-level function executes, it may call the passed-in function any number of times to perform a subtask. In another scenario, the lower-level function registers the passed-in function as a handler that is to be called asynchronously by the lower-level function later in reaction to something.

Java’s object-oriented model does not currently support method pointers, and some developers may think that Java does not permit such a comfortable mechanism. Discover the main reasons why you may want to implement the callback pattern through interfaces in Java. I also discuss alternative ways of implementing the callback pattern.
Why use callbacks at all?

You can use a callback as a simpler alternative to polymorphism and generic programming, in that the exact behavior of a function can be dynamically determined by passing different (yet compatible) function pointers or handles to the lower-level function. This can be a very powerful technique for code reuse.

To understand the motivation for using callbacks, consider the problem of performing an arbitrary operation on each item in a list. One approach is to iterate over the list, operating on each object. This is the most common solution in practice, but it is not ideal; the code to manage the iterator (for example, a for statement) must be duplicated at each point in the code where the list is traversed. Furthermore, if the list is updated by an asynchronous process (for example, if an item is added or removed), the iterator might skip over items or become corrupt during the traversal.

An alternative might be to create a new library function that performs the desired operation with appropriate synchronization. This approach still requires each new library function to contain the code to traverse the list. This solution is not acceptable for generic libraries intended for various applications; the library developer cannot anticipate what every application will need, and the application developer should not need to know the details of the library implementation.

Callbacks solve these shortcomings. One procedure is written to traverse the list, and this procedure uses application-provided code to operate on each item. There is a clear distinction between the library and the application without sacrificing flexibility. Callback has a totally different meaning in the context of security. For a secure login, you call the server and then it calls you back; this makes it harder for you to spoof being someone else.
How to use callbacks in Java

Java does not have procedure variables to implement function pointer callbacks the way C/C++ does. A callback would be used in C, for example, to pass a sin or cos function to a generic plotting program.

There are four basic techniques to fake a callback function in Java. They include the following:

* Pass a callback delegate object that implements an interface for the callback method(s). This is how it is most commonly done.
* Subclassing. Subclass the calling class with an overridden callback method. Pass “this” as a parameter.
* Delegation via subclassing. Pass a subclassed callback delegate object that knows how to invoke the callback method(s).
* Use inner classes to define an anonymous callback class, instantiate an anonymous callback delegate object, and pass it as a parameter all in one line. This technique with EventListeners tends to muddle GUI and program logic, making your GUI code non-reusable. Unless the anonymous inner classes are simple, it is generally wiser to make them free-standing named classes.

Here’s an example of how you can implement a callback using the first method. Java’s support of interfaces provides a mechanism by which you can get the equivalent of callbacks. The trick is to define a simple interface that declares the method you wish to be invoked. For example, suppose you want to receive notification when an event occurs. You can define an interface like this:

Here is an example explain

1. interface Callable
2. {
3. public void callBackMethod();
4. }
5. class Worker
6. {
7. // Worker gets a handle to the boss object via the Callable interface.
8. // There's no way this worker class can call any other method other than
9. // the one in Callable.
10. public void doSomeWork(Callable myBoss)
11. {
12. myBoss.callBackMethod();
13. // ERROR!
14. //myBoss.directMethod();
15. }
16. }
17. class Boss implements Callable
18. {
19. public Boss()
20. {
21. // Boss creates a worker object, and tells it to do some work.
22. Worker w1 = new Worker();
23. // Notice, we're passing a reference of the boss to the worker.
24. w1.doSomeWork(this);
25. }
26. public void callBackMethod()
27. {
28. System.out.println("What do you want?");
29. }
30. public void directMethod()
31. {
32. System.out.println("I'm out for coffee.");
33. }
34. }
35. public class CallBack
36. {
37. // Main driver.
38. public static void main(String[] args)
39. {
40. Boss b = new Boss();
41. b.directMethod();
42. }
43. }

Understanding User-Agent Strings

2009-04-13T07:10:00.000-07:00

Understanding the User-Agent String

When you request a Web page, your browser sends a number of headers to the server hosting the site that you are visiting. Each header contains details that help the server determine the best way to provide the information that you requested. The user-agent header identifies the application requesting the information from the server. The user-agent string can contain optional details called tokens, which must be enclosed in parentheses and vary among programs. Internet Explorer uses tokens to describe additional details about your computer system.

The following figure shows a sample user-agent string reported by Internet Explorer that highlights its tokens.

For historical reasons, Internet Explorer identifies itself as a Mozilla 4.0 browser.

The sample user-agent string contains three tokens.

The Compatibility flag ("compatible") is used by most modern browsers. It indicates that Internet Explorer is compatible with a common set of features.
The Version token identifies the browser and contains the version number. The version token in the example ("MSIE 7.0") identifies Internet Explorer 7.
The Platform token identifies your operating system and contains the version number. The platform token in the example ("Windows NT 6.0") indicates Windows Vista.

In the example, Internet Explorer is the user agent. However, other programs also provide user-agent strings when contacting servers over the Internet. For example, the Windows RSS Platform provides the following user-agent header when requesting RSS data.

MORE >>

The Nuts and Bolts of Credit Card Processing

2009-03-30T23:50:00.001-07:00

Consumers increasingly are turning to plastic over paper when they open their wallets. Credit and debit card spending exceeded $1 trillion in 1998, making it a necessary payment option for most businesses.

Yet many small businesses still don't accept credit cards. If you're one of the laggards,
the entire transaction may retain the aura of a mystic ritual — swipe a card, input some numbers, and money magically appears in the bank. In reality, though, credit card transactions involve coordination between multiple high-speed computer networks.

How the Process Works

When a merchant makes a sale and swipes a customer's credit card, the card number, the amount, and the merchant ID travel over the credit card processor's computer network. The credit card processor can either be a bank or a company that does nothing but provide credit card processing services.

From the processor's network the transaction goes to a credit card computer network. If the customer is using Visa, for example, the transaction will go to Visa's network. In turn, the electronic transaction goes to the bank that actually issued the card. The bank then checks the account and verifies the customer has adequate credit to cover the purchase. The bank then sends the merchant an authorization over the network. Now the sale is complete, but the transaction is not — no money has changed hands yet.

At the end of the business day, the merchant sends that day's charges, in a batch, to the credit card network for processing. The transactions travel via the merchant's credit card processor. Individual transactions are then stripped out and sent back to the individual cardholders' banks. Banks then debit cardholders' accounts and make appropriate payments to the merchant's credit card processor through the Federal Reserve Bank's Automated Clearing House.

The credit card processor then credits the merchant's bank account for the transaction amount, minus its fees for the transaction. Those fees also go toward paying transaction fees to the issuing bank and the credit card network. Despite the use of computers, it can take two business days before the merchant's account is credited.

Opening a Merchant Account

In order to accept credit cards, you must open a merchant account with a bank. However, many banks have gotten out of the credit card processing business, and those that remain are often skittish about servicing small businesses, particularly ones with limited operating histories.

Many small businesses must therefore go through a specialized credit card processor or an independent sales organization, commonly referred to as an "ISO." Whether you use a bank or a credit card processor, you need a merchant account to receive credit card payments.

Though businesses can contact credit card processors directly, banks unable or unwilling to process credit transactions often refer customers to an ISO to help them find a credit card processor and get the necessary equipment and training to begin accepting credit cards.

What does “> /dev/null 2>&1 in Unix mean?

2009-03-24T22:27:00.000-07:00

I remember being confused for a very long time about the trailing garbage in commands I saw in Unix systems, especially while watching compilers do their work. Nobody I asked could tell me what the funny greater-thans, ampersands and numbers after the commands meant, and search engines never turned up anything but examples of it being used without explanation. In this article I’ll explain those weird commands.

before explaining above let me begin from waht is ' /dev/null '

/dev/null

Definition: /dev/null: On UNIX, this is a virtual-file that can be written to. Data written to this file gets discarded. It is similar to the file call NUL on Windows machines. Key point: When rooting a machine, intruders will often redirect logging to /dev/null For example, the command ln -s /dev/null .bash_history will cause the system to stop logging bash commands. Culture: In the vernacular, means much the same thing as black hole. Typical usage: if you don't like what I have to say, please direct your comments to /dev/null.

There is a special device know as /dev/null to which you can redirect unwanted output. This is a null (non-existent) device represented by the file null in the directory /dev .

* Example

To carry out a conditional action:

if who | grep -s keith > /dev/null
then
echo keith is logged in
else
echo keith not available
fi

This lists who is currently logged on to the sytem and pipes the output through grep to search for the username keith.

The -s option causes grep to work silently and any error messages are directed to the file /dev/null instead of the standard output.

If the command is succesful i.e. the username keith is found in the list of users currently logged in then the message

keith is logged on

is displayed, otherwise the second message is displayed.

Here’s an example command:

wibble > /dev/null 2>&1

Output redirection

The greater-thans (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.
Standard in, out, and error

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!

How can you Store and Forward

2008-12-17T02:23:00.000-08:00

Store and forward is an application that some credit card terminals can run, that allows transactions to be taken without the terminal being connected to a phone line. The transactions are later processed when a connection is available.

Most wireless terminals have the ability to do store and forward, when there is no cellular coverage. But, there are also some land-line terminals that support store and forward. These terminals are a lot cheaper than wireless terminals, some having battery packs, making them moderately portable.

Store and forward on a land-line terminal can be a good solution for low volume mobile businesses, and can make a great backup for a wireless terminal. If you use a manual imprinter for your transactions, a store and forward battery operated terminal can be a good low cost step, without going to a wireless terminal.

What terminals work:
It’s not quite as simple as which terminals can support store and forward, because the correct terminal also has to be with the correct processing bank in order for the store and forward to be programmed correctly. Overall Lipman ‘Nurit’ terminals are the only ones that support store and forward. The wireless terminals (Nurit 3010, Nurit 8000) can be programmed with store and forward through at least Nova and FDMS, and the land-line terminals can potentially support store and forward at FDMS only.

As far as battery powered terminals go, there is the Nurit 2085U, the Nurit 3020U, and the Nurit 8320U, that have battery packs. These terminals are more difficult to obtain than the standard models, and will probably have to be special ordered, but are still much cheaper than wireless terminal.

Also, in the case of these terminals, you processor may charge extra to program these terminals with store and forward because the programming is almost always outsourced to the processing bank, who charges for it. Even if this normally wouldn’t be an issue, it is something to be aware of.

Store and forward isn’t perfect:
Store and forward creates an illusion that you are processing your customer’s cards just like normal, but this isn’t the case. No actual authorization is being made when using store and forward, so there is a chance that the card will decline when you finally go to run it. The second drawback is that if you don’t process the stored transactions quickly enough, they can all downgrade.

So, if you have an abnormally large transaction, or you have a bad feeling that the card may be no good, I recommend making a voice authorization before accepting the card. Businesses that get a lot of declined cards probably want to stay away from store and forward because all those declines will hurt your business and your time. Also, make sure to batch all of the transactions out of the terminal every day that you process to prevent downgrading.

Why is Thread.stop deprecated?

2008-11-25T06:49:00.000-08:00

Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

Couldn't I just catch the `ThreadDeath` exception and fix the damaged object?

In theory, perhaps, but it would vastly complicate the task of writing correct multithreaded code. The task would be nearly insurmountable for two reasons:

A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind.
A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.

In sum, it just isn't practical.

What about `Thread.stop(Throwable)`?

In addition to all of the problems noted above, this method may be used to generate exceptions that its target thread is unprepared to handle (including checked exceptions that the thread could not possibly throw, were it not for this method). For example, the following method is behaviorally identical to Java's throw operation, but circumvents the compiler's attempts to guarantee that the calling method has declared all of the checked exceptions that it may throw:

    static void sneakyThrow(Throwable t) {
       Thread.currentThread().stop(t);
   }

What should I use instead of `Thread.stop`?

Most uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. (This is the approach that JavaSoft's Tutorial has always recommended.) To ensure prompt communication of the stop-request, the variable must be volatile (or access to the variable must be synchronized).

For example, suppose your applet contains the following start, stop and run methods:

    private Thread blinker;

   public void start() {
       blinker = new Thread(this);
       blinker.start();
   }

   public void stop() {
       blinker.stop();  // UNSAFE!
   }

   public void run() {
       Thread thisThread = Thread.currentThread();
       while (true) {
           try {
               thisThread.sleep(interval);
           } catch (InterruptedException e){
           }
           repaint();
       }
   }

You can avoid the use of Thread.stop by replacing the applet's stop and run methods with:

    private volatile Thread blinker;

   public void stop() {
       blinker = null;
   }

   public void run() {
       Thread thisThread = Thread.currentThread();
       while (blinker == thisThread) {
           try {
               thisThread.sleep(interval);
           } catch (InterruptedException e){
           }
           repaint();
       }
   }

How do I stop a thread that waits for long periods (e.g., for input)?

That's what the Thread.interrupt method is for. The same "state based" signaling mechanism shown above can be used, but the state change (blinker = null, in the previous example) can be followed by a call to Thread.interrupt, to interrupt the wait:

    public void stop() {
       Thread moribund = waiter;
       waiter = null;
       moribund.interrupt();
   }

For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say reasserts rather than rethrows, because it is not always possible to rethrow the exception. If the method that catches the InterruptedException is not declared to throw this (checked) exception, then it should "reinterrupt itself" with the following incantation:

    Thread.currentThread().interrupt();

This ensures that the Thread will reraise the InterruptedException as soon as it is able.

What if a thread doesn't respond to `Thread.interrupt`?

In some cases, you can use application specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general. It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either. Such cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly.

Why are `Thread.suspend` and `Thread.resume` deprecated?

Thread.suspend is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes.

What should I use instead of `Thread.suspend` and `Thread.resume`?

As with Thread.stop, the prudent approach is to have the "target thread" poll a variable indicating the desired state of the thread (active or suspended). When the desired state is suspended, the thread waits using Object.wait. When the thread is resumed, the target thread is notified using Object.notify.

For example, suppose your applet contains the following mousePressed event handler, which toggles the state of a thread called blinker:

    private boolean threadSuspended;

   Public void mousePressed(MouseEvent e) {
       e.consume();

       if (threadSuspended)
           blinker.resume();
       else
           blinker.suspend();  // DEADLOCK-PRONE!

       threadSuspended = !threadSuspended;
   }

You can avoid the use of Thread.suspend and Thread.resume by replacing the event handler above with:

    public synchronized void mousePressed(MouseEvent e) {
       e.consume();

       threadSuspended = !threadSuspended;

       if (!threadSuspended)
           notify();
   }

and adding the following code to the "run loop":

                synchronized(this) {
                   while (threadSuspended)
                       wait();
               }

The wait method throws the InterruptedException, so it must be inside a try ... catch clause. It's fine to put it in the same clause as the sleep. The check should follow (rather than precede) thesleep so the window is immediately repainted when the the thread is "resumed." The resulting run method follows:

    public void run() {
       while (true) {
           try {
               Thread.currentThread().sleep(interval);

               synchronized(this) {
                   while (threadSuspended)
                       wait();
               }
           } catch (InterruptedException e){
           }
           repaint();
       }
   }

Note that the notify in the mousePressed method and the wait in the run method are inside synchronized blocks. This is required by the language, and ensures that wait and notify are properly serialized. In practical terms, this eliminates race conditions that could cause the "suspended" thread to miss a notify and remain suspended indefinitely.

While the cost of synchronization in Java is decreasing as the platform matures, it will never be free. A simple trick can be used to remove the synchronization that we've added to each iteration of the "run loop." The synchronized block that was added is replaced by a slightly more complex piece of code that enters a synchronized block only if the thread has actually been suspended:

                if (threadSuspended) {
                   synchronized(this) {
                       while (threadSuspended)
                           wait();
                   }
               }

In the absence of explicit synchronization, threadSuspended must be made volatile to ensure prompt communication of the suspend-request.

The resulting run method is:

    private boolean volatile threadSuspended;

   public void run() {
       while (true) {
           try {
               Thread.currentThread().sleep(interval);

               if (threadSuspended) {
                   synchronized(this) {
                       while (threadSuspended)
                           wait();
                   }
               }
           } catch (InterruptedException e){
           }
           repaint();
       }
   }

Can I combine the two techniques to produce a thread that may be safely "stopped" or "suspended"?

Yes; it's reasonably straightforward. The one subtlety is that the target thread may already be suspended at the time that another thread tries to stop it. If the stop method merely sets the state variable (blinker) to null, the target thread will remain suspended (waiting on the monitor), rather than exiting gracefully as it should. If the applet is restarted, multiple threads could end up waiting on the monitor at the same time, resulting in erratic behavior.

To rectify this situation, the stop method must ensure that the target thread resumes immediately if it is suspended. Once the target thread resumes, it must recognize immediately that it has been stopped, and exit gracefully. Here's how the resulting run and stop methods look:

    public void run() {
       Thread thisThread = Thread.currentThread();
       while (blinker == thisThread) {
           try {
               thisThread.sleep(interval);

               synchronized(this) {
                   while (threadSuspended && blinker==thisThread)
                       wait();
               }
           } catch (InterruptedException e){
           }
           repaint();
       }
   }

   public synchronized void stop() {
       blinker = null;
       notify();
   }

If the stop method calls Thread.interrupt, as described above, it needn't call notify as well, but it still must be synchronized. This ensures that the target thread won't miss an interrupt due to a race condition.

What about `Thread.destroy`?

Thread.destroy has never been implemented. If it were implemented, it would be deadlock-prone in the manner of Thread.suspend. (In fact, it is roughly equivalent to Thread.suspend without the possibility of a subsequent Thread.resume.) We are not implementing it at this time, but neither are we deprecating it (forestalling its implementation in future). While it would certainly be deadlock prone, it has been argued that there may be circumstances where a program is willing to risk a deadlock rather than exit outright.

Why is `Runtime.runFinalizersOnExit` deprecated?

Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to "defend against" this call, most programmers do not defend against it. They assume that an object is dead at the time that its finalizer is called.

Further, the call is not "thread-safe" in the sense that it sets a VM-global flag. This forces every class with a finalizer to defend against the finalization of live objects!

Apache Tomcat - Restrict Access By IP

2008-09-30T03:42:00.000-07:00

Normally I do not do IP based restrictions in applications I build since they almost universally need to be accessed from anywhere on the Internet. The few times I have given it much thought I pretty much settled on letting the Apache rewrite manage it and let it go at that. I am highly Apache Rewrite Dependent but that’s another story for another day.

Recently however I was tasked with building a small XML-RPC gateway for a friend. This gateway was in front some fairly sensitive workflow for a specific customer of his and thus would have a limited subset of static IP addresses connecting to it. The app itself was simple and I wanted to keep it that way, no database, straight-through XML-RPC gateway to a back-end service and, for simplicity, no Apache2 in the loop. No Apache2, no Restrict By IP(!), at least in my simple thinking.

Amazingly enough, after reading the docs, I discovered that Tomcat has the ability to restrict based on IP built in. Probably common knowledge to most Tomcat developers but in my Google Searches I never came across an answer for it so I thought I’d post it here for future Google Visitors since most of known civilization searches with Google before reading the Tomcat docs.

Basically Tomcat implements Allow/Deny IP lists as a Valve called a ‘RemoteAddrValve’ that intercepts requests.

Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1|localhost|10.0.1.123" deny=""/>

Add this to your virtualhost in server.xml and you will instantly allow only access to the IP’s listed in the allow directive. Add IP’s to the deny directive to specifically deny them. I don’t know who wins a tie, let me know if you have a chance to experiment with it.

This has been invaluable for this particular app. Its not robust enough for apps of a much larger scale (allowed/denied client wise) but for this app its Just Right and so I post it for future generations. I imagine you could easily subclass this valve and create a JDBC backed Remote IP store. Hmm, maybe a project for another day..

Apache restrict access based on IP address to selected directories

2008-09-29T23:07:00.000-07:00

Apache web server allows server access based upon various conditions. For example you just want to restrict access to url http://payroll.nixcraft.in/ (mapped to /var/www/sub/payroll directory) from 192.168.1.0/24 network (within intranet).

Apache provides access control based on client hostname, IP address, or other characteristics of the client request using mod_access module.

Open your httpd.conf file:
# vi /etc/httpd/conf/httpd.confLocate directory section (for example/var/www/sub/payroll) and set it as follows:Order allow,deny Allow from 192.168.1.0/24 Allow from 127Where,

Order allow,deny: The Order directive controls the default access state and the order in which Allow and Deny directives are evaluated. The (allow,deny) Allow directives are evaluated before the Deny directives. Access is denied by default. Any client which does not match an Allow directive or does match a Deny directive will be denied access to the server.
Allow from192.168.1.0/24: The Allow directive affects which hosts can access an area of the server (i.e. /var/www/sub/payroll/). Access is only allowed from network 192.168.1.0/24 and localhost (127.0.0.1).

Save file and restart apache web server:
# /etc/init.d/httpd restart

Eclipse Short cuts

2008-07-24T03:52:00.000-07:00

You should try to keep your hands on keyboard. The less you touch the mouse, the more code you can write. I am trying to keep the mouse laying still and control the IDE completely using keyboard. What do you think is faster: pressing ALT + C or right clicking the project, selecting Team -> Commit?

It is said, that if a function does not have a key binding, it is useless. Below you will find a set of essential keyboard shortcuts that I love. These shortcuts are set up by default, they should all work.

CTRL + D: Delete row. Try it! You no more need to grab the mouse and select the line, no more Home, Shift + End, Delete. Quick and clean.
ALT + Up/Down Arrow: Move the row (or the entire selection) up or down. Very useful when rearranging code. You can even select more rows and move them all. Notice, that it will be always correctly indented.


ALT + Left/Right Arrow: Move to the last location you edited. Imagine you just created a class Foo, and now you are working on a class Boo. Now, if you need to look at the Foo class, just press Alt+Left Arrow. Alt+Right Arrow brings you back to Boo.
CTRL+SHIFT+O: Organize imports. What happens when you first use a class you have not yet imported? You will see an error. But when you press this magical combination, all your missing classes will be imported, and the unused imports will vanish.
CTRL+1: Probably the most useful one. It activates the quick fix. Imagine you create a class, which implements some interface. You will get an error, because the inherited methods are not yet implemented. While you are on line where the error occurs, press this combination to activate the quick fix. Now, select the "Add unimplemented methods" option. You can use the quick fix at every error you ever receive.

Quick fix comes handy in other situations too. My favorite is the "Split variable declaration". Sometimes I need to broaden the scope of a variable. I activate the quick fix, split declaration, and use alt + arrow to put it where it belongs. You can find even more usages: Convert local variable to field, rename in file, Inline local variable..

You could use the "Split variable declaration" on the bar variable, and then move it with Alt+Arrows above the try block..

Or you could use the "Add unimplemented methods" fix here.

The best thing you can do if you see an error is to use the quick fix.
CTRL+SHIFT+T: Open Type. Imagine, that you need to have a look at the Foo class. But, where is the Foo class? Is it in the Boo project and in the foo.bar package? Or somewhere else? With this shortcut, you don't need to know. Just press it, type Foo and you are in.


CTRL+E: Shows you a list of all open editors.
CTRL+F6: Use to move between open editors. This is an slower alternative to Ctrl + E. Comes handy in a situation when you want to periodically switch between two editors, something, what is nearly impossible with Ctrl+E as it sorts entries quite randomly. Or you might just use Alt+Arrows..
CTRL+F7: Move between views. When in editor, press Ctrl+F7 to switch to the Package Explorer, or hold Ctrl and press F7 multiple times to switch to other views.

CTRL+F8: Move between perspectives. The same as previous.


CTRL + F11: Runs the application. What gets launched depends on your settings. It will either launch the last launched class (my preffered way) or it will launch currently selected resource (the default way). If you want to change its behavior read the previous post.
CTL + N: Open new type wizard. This is not very quick because you have to select the wizard type (weather you want to create new class, jsp, xml or something else) in the next step. Much faster way would be if you could just hit the shortcut and invoke the particular wizard. It is possible, just keep reading..
CTRL + M: Maximize or umaximize current tab.
CTRL + I: Corrects indentation.
CTRL + SHIFT + F: Formats code. You can make a beautiful looking code out of a mess with this. It requires a bit of setup, but it is well worth it. You can find its settings under Window->Preferences->Java->Code style->Formatter
CTRL + J: Incremental search. Similar to the search in firefox. It shows you results as you type. Don't be surprised, if you hit this combination, nothing happens - at the first glance. Just start typing and eclipse will move your cursor to the first ocurence.
CTRL + SHIFT + L: Shows you a list of your currently defined shortcut keys.

I don't like your shortcuts

Such is life nowadays. Remember, you can always change those bindings to match your preferences. Open Windows->Preferences->General->Keys. Now you can use the filter to find your shortcut and change its binding.

The real fun begins when you cannot find the command you are looking for. The key here, is to have the "Include unbounds commands" checkbox checked. It will show you all commands, even those, which have no keys bound.

While you are here, I recommend to add the following bindings:

CTRL+SHIFT+G: Bind this to "Generate getters and setters". This is a "must have".
ALT+C: Bind this to SVN/CVS "Commit".
ALT+U: Bind this to SVN/CVS "Update".

Now, type "new" (without quotes) in the filter text. You should see a list of all new type wizards. Choose the most frequently used and assign them a shortcut. For example, the most used wizard for me is the new class wizard. Thus I assigned it the CTRL+SHIFT+N keys.

Let me demonstrate a quick way to create new class now.

Hit CTRL + SHIFT + N (or the combination you assigned in the previous step). This should bring up new class wizard. Type in the name and press ALT+E. You can now select a class which will be a superclass for the newly created class. Hit ALT+A and select all implemented interfaces . Now hit ALT+F and your class will be generated. Eclipse will also provide the default implementation for all abstract and interface methods you inherited.

Did you notice the weird underscores everywhere in the dialog? They give you a hint about the shortcut key. Hit ALT and the underlined letter to press the button, check the checkbox or get focus for a textfield.

Did you notice the underscores?

I think that using shortcut keys is the fastest way to productivity and if not, then at least your wrists will say you a silent thanks. Now, don't wait, go on and assign keys to the features you use most.

One final tip from Andriy:

The problem is that there are so many keyboard shortcuts. I used to keep a printout with all the shortcuts I wanted to use. Finally I wrote an Eclipse plugin MouseFeed, which reminds the keyboard shortcuts for the actions called with mouse. You can even tell it to enforce some shortcuts - the action will run only if called with a keyboard shortcut.

So if you are struggling with yourself, if you want to use shortcuts, but always subconsciously touch the mouse, install the plugin and let it enforce the shortcuts - the mouse will be useless and you will be forced to use keyboard.

What shortcuts do you use?

Sanjib

Java JMX tutorial

Software Design Principles Part II

Open Close Principle

Motivation

Intent

Example

Conclusion

Software Design Principles Part I

Java 5 : Extended

LOG4J :Best Practice

Eclipse Java Autocompletion Not Working

Java Threads : Volatile vs Synchronized

Lucene: A Tutorial Introduction to Full-Text Indexing in Java

Finite State Machine for Decimals

Finite State Machine for String Literals

- : Mediator pattern : -

Introduction

Air Traffic Controller Example

Structure

Participants

Applicability

Consequences

Advantages

Disadvantages

Examples

Parliament

Chatroom

Known Uses

User Interfaces

Java Message Service

Previous Experience

Conclusion

Java performance guidelines-Part I

A brief explanation of the ISO-8583 protocol

How to play Bin and CUE files

IsoBuster

Java Tool : JAR anatomy

How to Find out the IP address assigned to eth0 and display IP only

Implemating MEDIAWIKI

Implementing the callback pattern in Java

Understanding User-Agent Strings

Understanding the User-Agent String

The Nuts and Bolts of Credit Card Processing

What does “> /dev/null 2>&1 in Unix mean?

How can you Store and Forward

Why is Thread.stop deprecated?

Couldn't I just catch the ThreadDeath exception and fix the damaged object?

What about Thread.stop(Throwable)?

What should I use instead of Thread.stop?

How do I stop a thread that waits for long periods (e.g., for input)?

What if a thread doesn't respond to Thread.interrupt?

Why are Thread.suspend and Thread.resume deprecated?

What should I use instead of Thread.suspend and Thread.resume?

Can I combine the two techniques to produce a thread that may be safely "stopped" or "suspended"?

What about Thread.destroy?

Why is Runtime.runFinalizersOnExit deprecated?

Apache Tomcat - Restrict Access By IP

Apache restrict access based on IP address to selected directories

Eclipse Short cuts

I don't like your shortcuts

Couldn't I just catch the `ThreadDeath` exception and fix the damaged object?

What about `Thread.stop(Throwable)`?

What should I use instead of `Thread.stop`?

What if a thread doesn't respond to `Thread.interrupt`?

Why are `Thread.suspend` and `Thread.resume` deprecated?

What should I use instead of `Thread.suspend` and `Thread.resume`?

What about `Thread.destroy`?

Why is `Runtime.runFinalizersOnExit` deprecated?