Creating an "Absolute Singleton"

How do you create just a single instance of a Singleton class with different class loaders? Follow the link to get the solution : http://surguy.net/articles/communication-across-classloaders.xml

Building a Common Navigator Framework Viewer

Follow the below link for CNF Framework article.

CNF Framework article

CustomFile Filter for JFileChooser

class ExtensionFileFilter extends FileFilter {

private java.util.List extensions;
private String description;


public ExtensionFileFilter(String[] exts, String desc) {
if(exts != null) {
extensions = new java.util.ArrayList();

for(String ext : exts) {
extensions.add(ext.replace(".", "").trim().toLowerCase());
}
}
description = (desc != null) ? desc.trim() : "Some description";
}


@Override
public boolean accept(File f) {
if(extensions == null) return false;
if(f.isDirectory()) return true;

for(String ext : extensions) {
if(f.getName().toLowerCase().endsWith("." + ext)) return true;
}
return false;
}


@Override
public String getDescription() {
return description;
}
}

PDF Generation using Apache FOP !!!

The user can generate a pdf file using Apache FOP.(http://xmlgraphics.apache.org/fop/)
FOP (Formatting Objects Processor) is from the apache group.It is said to be the worlds first print formatter driven by XSL formatting objects (XSL-FO) and the world's first output independent formatter. Actually it isn’t a tool specifically meant for PDF conversion or creation.FOP can be downloaded here.

FOP converts the XSL files (*.fo) to PDF format.

Following is a sample for generating a pdf.

Create a Driver instance and set the necessary inputs.
Driver driver = new Driver();
Logger logger = new ConsoleLogger(ConsoleLogger.LEVEL_DEBUG);
MessageHandler.setScreenLogger(logger);

driver.setLogger(logger);
driver.setRenderer(Driver.RENDER_PDF);// Output type
driver.setInputSource(new InputSource(new java.io.StringReader(fo)));
// fo is the xsl-fo format string which is generated after transforming the xml with xsl.
driver.setOutputStream(new FileOutputStream(outputFile));
driver.run();
driver.reset();

Using the above snippet you can generate a PDF file.:-)

Java Protected and Default Members

The protected and default access control
levels are almost identical, but with one critical difference. A default member may be accessed only if the class accessing the member belongs to the same package,
whereas a protected member can be accessed (through inheritance) by a subclass
even if the subclass is in a different package. Take a look at the following two classes:

package certification;
public class OtherClass {
void testIt() { // No modifier means method has default access
System.out.println("OtherClass");
}
}

In another source code file you have the following:

package somethingElse;
import certification.OtherClass;
class AccessClass {
static public void main(String [] args) {
OtherClass o = new OtherClass();
o.testIt();
}
}

As you can see, the testIt() method in the second file has default (think:package-level) access. Notice also that class OtherClass is in a different package from the AccessClass. Will AccessClass be able to use the method testIt()?
Will it cause a compiler error? Will Daniel ever marry Francesca? Stay tuned.

%javac AccessClass.java
AccessClass.java:5: No method matching testIt() found in class
certification.OtherClass.
o.testIt();
1 error

From the preceding results, you can see that AccessClass can’t use the OtherClass method testIt() because testIt() has default access, and AccessClass is not in the same package as OtherClass. So AccessClass can’t see it, the compiler complains, and we have no idea who Daniel and Francesca are.
Default and protected behavior differ only when we talk about subclasses. This difference is not often used in actual practice, but that doesn’t mean it won’t be on the exam! Let’s look at the distinctions between protected and default access.
If the protected keyword is used to define a member, any subclass of the class declaring the member can access it. It doesn’t matter if the superclass and subclass are in different packages, the protected superclass member is still visible to the subclass (although visible only in a very specific way as we’ll see a little later). This is in contrast to the default behavior, which doesn’t allow a subclass to access a superclass member unless the subclass is in the same package as the superclass.

Whereas default access doesn’t extend any special consideration to subclasses (you’re either in the package or you’re not), the protected modifier respects the parent-child relationship, even when the child class moves away (and joins a new package). So, when you think of default access, think package restriction. No exceptions. But when you think protected, think package + kids. A class with a protected member is marking that member as having package-level access for all
classes, but with a special exception for subclasses outside the package.
But what does it mean for a subclass-outside-the-package to have access (visibility) to a superclass (parent) member? It means the subclass inherits the member. It does not, however, mean the subclass-outside-the-package can access the member using a reference to an instance of the superclass. In other words, protected = inheritance.Protected does not mean that the subclass can treat the protected superclass member as though it were public. So if the subclass-outside-the-package gets a reference to the superclass (by, for example, creating an instance of the superclass somewhere in the subclass’ code), the subclass cannot use the dot operator on the superclass reference to access the protected member. To a subclass-outside-the-package, a
protected member might as well be default (or even private), when the subclass is using a reference to the superclass. The subclass can only see the protected member through inheritance.
Are you confused? So are we. Hang in there and it will all become clear with the next batch of code examples. (And don’t worry; we’re not actually confused. We’re just trying to make you feel better if you are. You know, like it’s OK for you to feel as though nothing makes sense, and that it isn’t your fault. Or is it? ) Let’s take a look at a protected instance variable (remember, an instance variable is a member) of a superclass.

package certification;
public class Parent {
protected int x = 9; // protected access
}

The preceding code declares the variable x as protected. This makes the variable accessible to all other classes in the certification package, as well as inheritable by any subclasses outside the package. Now let’s create a subclass in a different package, and attempt to use the variable x (that the subclass inherits).

package other; // Different package
import certification.Parent;
class Child extends Parent {
public void testIt() {
System.out.println("x is " + x); // No problem; Child inherits x
}
}

The preceding code compiles fine. Notice, though, that the Child class is accessing the protected variable through inheritance. Remember, anytime we talk about a subclass having access to a superclass member, we could be talking about the subclass inheriting the member, not simply accessing the member through a reference to an instance of the superclass (the way any other nonsubclass would access it). Watch what happens if the subclass Child (outside the superclass’ package) tries to access a protected variable using a Parent class reference.
package other;

import certification.Parent;
class Child extends Parent {
public void testIt() {
System.out.println("x is " + x); // No problem; Child inherits x
Parent p = new Parent(); // Can we access x using the p reference?
System.out.println("X in parent is " + p.x); // Compiler error!
}
}

The compiler is more than happy to show us the problem:
%javac -d . other/Child.java
other/Child.java:9: x has protected access in certification.Parent
System.out.println("X in parent is " + p.x);
^
1 error

So far we’ve established that a protected member has essentially package-level or default access to all classes except for subclasses. We’ve seen that subclasses outside the package can inherit a protected member. Finally, we’ve seen that subclasses outside the package can’t use a superclass reference to access a protected member.For a subclass outside the package, the protected member can be accessed only through inheritance.
But there’s still one more issue we haven’t looked at…what does a protected member look like to other classes trying to use the subclass-outside-the-package to get to the subclass’ inherited protected superclass member? For example, using our previous Parent/Child classes, what happens if some other class—Neighbor, say— in the same package as the Child (subclass), has a reference to a Child instance and wants to access the member variable x ? In other words, how does that protected member behave once the subclass has inherited it? Does it maintain its protected
status, such that classes in the Child’s package can see it? No! Once the subclass-outside-the-package inherits the protected member, that member (as inherited by the subclass) becomes private to any code outside the subclass. So if class Neighbor instantiates a Child object, then even if class Neighbor is in the same package as class Child, class Neighbor won’t have access to the Child’s inherited (but protected) variable x. The bottom line: when a
subclass-outside-the-package inherits a protected member, the member is essentially
private inside the subclass, such that only the subclass’ own code can access it.
Figure 2-3 illustrates the effect of protected access on classes and subclasses in the
same or different packages.
Whew! That wraps up protected, the most misunderstood modifier in Java.
Again, it’s used only in very special cases, but you can count on it showing up on
the exam. Now that we’ve covered the protected modifier, we’ll switch to default
member access, a piece of cake compared to protected.
Let’s start with the default behavior of a member in a superclass. We’ll modify
the Parent’s member x to make it default.

package certification;
public class Parent {
int x = 9; // No access modifier, means default (package) access
}

Notice we didn’t place an access modifier in front of the variable x. Remember that if you don’t type an access modifier before a class or member declaration, the access control is default, which means package level. We’ll now attempt to access the default member from the Child class that we saw earlier. When we compile the Child file, we get the following error:

%javac Child.java
Child.java:4: Undefined variable: x
System.out.println("Variable x is " + x);
1 error

The compiler gives the same error as when a member is declared as private.
The subclass Child (in a different package from the superclass Parent) can’t see or use the default superclass member x ! Now, what about default access for two classes
in the same package?

package certification;
public class Parent{
int x = 9; // default access
}

And in the second class you have the following:
package certification;

class Child extends Parent{
static public void main(String [] args) {
Parent sc = new Parent();
sc.testIt();
}
public void testIt() {
System.out.println("Variable x is " + x); // No problem;
}
}

The preceding source file compiles fine, and the class Child runs and displays the value of x. Just remember that default members are visible only to the subclasses that are in the same package as the superclass.

SWT - Standard Widget Toolkit

SWT is the UI library used by Eclipse. SWT provides some rich UI components on several platforms. The native widgets of the OS are accessed by the SWT framework via JNI. If a widget is not available on a certain platform, SWT emulates the unavailable widget.

The key components of SWT applications are the classes "Display" and "Shell". A Shell represents a window. Displays are responsible from managing event loops and controlling communication between the UI thread and other threads. Every SWT application requires at least one Display and one or more Shell instances. The main shell gets as a default parameter a Display as construtor argument.

First SWT Application :

import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.SWT;

public class HelloWorld
{
public static void main(String[] args)
{
Display display = new Display();
Shell shell = new Shell(display);
Label label = new Label(shell, SWT.CENTER);
label.setText("Hello, World");
label.setBounds(shell.getClientArea());
shell.open();
while (!shell.isDisposed())
{
if (!display.readAndDispatch())
{
display.sleep();
}
}
display.dispose();
}
}

For running the above application, you need to have swt.jar in your classpath.
You can find the swt jar in eclipse's plugin directory.
After adding swt.jar in classpath,the application can be executed successfully.

You will see a window with "Hello World" text.

Understanding the Program
These lines give you the proper imports for the class:

import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.SWT;


Most classes that use SWT import the SWT object and pieces of the swt.widgets package.

These lines create the Display object and the Shell object:

Display display = new Display();
Shell shell = new Shell(display);

At a high level, the Display object represents the underlying windowing system. The Shell object is an abstraction that represents a top-level window when created with a Display object, as this one is. A more detailed introduction to the Display and Shell classes is presented later in this chapter.

Next, you create your label widget with this code:

Label label = new Label(shell, SWT.CENTER);
label.setText("Hello, World");
label.setBounds(shell.getClientArea());

The Label object is capable of displaying either simple text, as you use it here, or an image. The widget is constructed with a reference to a Shell object, which is an indirect descendant of the Composite class. Composite classes are capable of containing other controls. When SWT encounters this line, it knows to create the underlying windowing system's implementation of the label widget on the associated Composite object.

To make your window display, you call this:

shell.open();

This indicates to the underlying system to set the current shell visible, set the focus to the default button (if one exists), and make the window associated with the shell active. This displays the window and allows it to begin receiving events from the underlying windowing system.

The main loop of your application is this:

while (!shell.isDisposed())
{
if (!display.readAndDispatch())
{
display.sleep();
}
}

You'll have a loop similar to this in each of your SWT applications. In this loop, you first check to make sure that the user hasn't closed your main window. Because the window is still open, you next check your event queue for any messages that the windowing system or other parts of your application might have generated for you. If no events are in the queue, you sleep, waiting for the next event to arrive. When the next event arrives, you repeat the loop, ensuring first that the event didn't dispose your main window.

Finally, you call:

display.dispose();

Check out more @ : SWT: The Standard Widget Toolkit—Part 2: Managing Operating System Resources.

Eclipse SWT Resources

SWT Snippets (Examples)

SWT Introduction

SWT: The Standard Widget Toolkit - PART 1: Implementation Strategy for Java™ Natives

SWT: The Standard Widget Toolkit - PART 2: Managing Operating System Resources

Understanding layout in SWT

Working with GWT

Hi folks ,I know its too late for adding a post for GWT....but dont worry I will add some useful information that will be beneficial to you people.Hope u enjoy it.

Tutorial on GWT2.0

The Google Web Toolkit (GWT) is a toolkit to develop web application with Java. The developer can develop in Java and debug the code. Once the code is finished the GWT compiler translates the Java code into Javascript. This compiler also makes sure that all the major browsers are correctly support.

GWT provides two modes :

1) Development Mode : In this mode you can debug your code via the standard Java debugger.
2)Web Mode : In this mode , a war of your application can be deployed on the webserver.

Modules & Entry Points :

GWT applcations are defined as modules.A module "module" is described by a configuraion file module.gwt.xml.
Each module can have one or more Entry Points.

Entry Points are the starting point for executing the application ,just as we have the main method as first point of execution in Java.

A module is connected to a HTML page called as host page in GWT .The GWT application runs in this HTML page only.
You can have div elements in the HTML page to which u can attach the GWT UI components.
Also you can attach the UI components to the body element.

Using CSS : You can set the style in the application by using the setStyle(String s) method in the UI widgets.
I will explore it later in the tutorial.