Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures

Home

Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips

Books

Submit News
Search the site here...
Search...
 

Swing Chapter 21. (Advanced topics) Pluggable Look & Feel. Easy for reading, Click here!

Custom Search
Swing Chapter 21. (Advanced topics) Pluggable Look & Feel. Easy for reading, Click here!

[ Return to Swing (Book) ]

Page: 1/5 



Next Page (2/5) Next Page

Chapter 21. Pluggable Look &Feel

Subpages: 1. Pluggable Look & Feel overview
2. Custom L&F: part I - Using custom resources
3. Custom L&F: part II - Creating custom UI delegates
4. L&F for custom components: part I - Implementing L&F support
5. L&F for custom components: part II - Third party L&F support

In this chapter:

  •          Pluggable Look & Feel overview
  •          Custom L&F: part I - Using custom resources
  •          Custom L&F: part II - Creating custom UI delegates
  •          L&F for custom components: part I - Implementing L&F support
  •          L&F for custom components: part II - Third party L&F support

21.1  Pluggable Look & Feel overview

The pluggable look-and-feel architecture is one of Swing's greatest milestones. It allows seamless changes in the appearance of an application and the way an application interacts with the user. This can occur without modification or recompilation of the application, and can be invoked programmatically during any single JVM session. In this chapter we'll discuss how L&F works, how custom L&F can be implemented for standard Swing components, and how L&F support (both existing and custom) can be added to custom components.

Note: In chapter 1 we introduced the basic concepts behind L&F and UI delegates, and it may be helpful to review this material before moving on.

In examining Swing component source code, you will quickly notice that these classes do not contain any code for sophisticated rendering. All this drawing code is stored somewhere else. As we learned in chapter 1, this code is defined within various UI delegates, which act as both a component's view and controller. (In chapter 6 we learned how to customize a tabbed pane and its UI delegate. This was only a small taste of the flexibility offered by pluggable look-and-feel that we will be discussing here.) Before jumping into the examples we need to discuss how the most significant L&F-related classes and interfaces function and interact in more detail.

21.1.1  LookAndFeel

abstract class javax.swing.LookAndFeel

This abstract class serves as the superclass of the central class of any pluggable look-and-feel implementation. The getDefaults() method returns an instance of UIDefaults (see 21.1.2). The getDescription() method returns a one-to-two sentence description of the L&F. getID()[1] returns a simple, unique string that identifies an L&F. getName() returns a short string representing the name of that L&F, such as "Malachite," or "Windows."

The isNativeLookAndFeel() method querie's the System class to determine whether the given LookAndFeel corresponds to that which emulates the operating system platform the running VM is designed for. The isSupportedLookAndFeel() method is used to determine whether the given LookAndFeel is supported by the operating system the running VM is designed for. Due to legal issues, some LookAndFeels will not be supported by certain operating systems, even though they have the ability to function perfectly fine.

Note: We will not go into the details of how to work around this imposed limitation (although it is relatively easy), specifically because of the legal issues involved.

The initialize() and uninitialize() methods are called when a LookAndFeel is installed and uninstalled, respectively. The toString() method is defined to return the description returned by getDescription(), as well as the fully qualified class name.

Several convenient static methods are also provided for assigning and unassigning borders, colors, and fonts to components: installBorder(), installColors(), installColorsAndFont(), and uninstallBorder(). LookAndFeel implements these so that the specified properties only change if the current property value of the given component is a UIResource (see 21.1.4) or null. Static methods makeKeyBindings() and makeIcon() are convenience methods for building a list of text component key bindings, and creating a UIDefaults.LazyValue (see 21.1.2) which can create an ImageIcon UIResource.

21.1.2  UIDefaults

class javax.swing.UIDefaults

This class extends Hashtable and manages a collection of custom resources (objects, primitives, etc) used in this L&F. Methods put(Object key, Object value) and putDefaults(Object[] keyValueList) can be used to store data (in the latter case they must be placed in a one-dimensional array in the order: key1, value1, key2, value2, etc.). Method get(Object key) can be used to retrieve a stored resource.

UIDefaults also defines two inner classes: LazyValue and ActiveValue. A LazyValue is an entry in the UIDefaults hashtable that is not instantiated until it is looked up with its associated key name. Large objects that take a long time to instantiate, and are rarely used, can benefit from being implemented as LazyValues. An ActiveValue is one that is instantiated each time it is looked up with its associated key name. Those resources that must be unique in each place they are used are often implemented as ActiveValues.

Both interfaces require the definition of the createValue() method. The following code shows a simple LazyValue that constructs a new border.

  Object myBorderLazyValue = new UIDefaults.LazyValue() {

    public Object createValue(UIDefaults table) {

      return new BorderFactory.createLoweredBevelBorder();

    }

  };

  myUIDefaults.put("MyBorder", borderLazyValue);

Note that the createValue() method will only be called once for LazyValues, whereas with ActiveValues it will be called each time that resource is requested.

21.1.3  UIManager

public class javax.swing.UIManager

This class provides a set of static methods used to manage the current look-and-feel. The current look-and-feel is actually made up of a three-level UIDefaults hierarchy: user defaults, current look-and-feel defaults, and system defaults. Particularly important methods are getUI(JComponent target), which retrieves an instance of ComponentUI for the specified component, and getDefaults(), which retrieves a shared instance of the UIDefaults class.

21.1.4  The UIResource interface

abstract interface javax.swing.plaf.UIResource

This interface has no implementation and is used solely to mark resource objects created for a component's UI delegate. Several classes used to wrap component UI resources implement this interface. For example: InsetsUIResource, FontUIResource, IconUIResource, BorderUIResource, and ColorUIResource. These wrapper classes are used for assigning resources that will be relinquished when a component's UI delegate is changed. In other words, if we were to assign an instance of JLabel a background of Color.Yellow, this background setting would persist even through a UI delegate change. However, if we were to assign that JLabel a background of new ColorUIResource(Color.Yellow), the background would only persist until another UI delegate is installed. When the next UI delegate is installed, the label will receive a new label background based on the L&F the new UI delegate belongs to.

21.1.5  ComponentUI

abstract class javax.swing.plaf.ComponentUI

This abstract class represents a common superclass of all component UI delegate classes implemented by each different L&F packages. The createUI(JComponent c) static method creates an instance of ComponentUI for a given component. See chapter 1, section 1.4.1, for a description of each ComponentUI method.

Abstract classes in the javax.swing.plaf package extend ComponentUI to represent the base class from which each Swing component's UI should extend: ButtonUI, TreeUI, etc. Each of these classes have a concrete default implementation in the javax.swing.plaf.basic package: BasicButtonUI, BasicTreeUI, etc. In turn, these basic UI classes can be, and are intended to be, extended by other L&F implementations. For example, the classes mentioned above are extended by MetalButtonUI and MetalTreeUI defined in the javax.swing.plaf.metal package.

21.1.6  BasicLookAndFeel

class javax.swing.plaf.basic.BasicLookAndFeel

This class provides the basic implementation of javax.swing.LookAndFeel. It creates all resources used by UI classes defined in the basic package. Custom L&F classes are expected to extend this class, rather than LookAndFeel directly, to replace only those resources that need to be customized.

Note: Though we will not go into the details of each basic UI delegate implementation in this book (indeed this is a large topic and deserves a whole volume unto itself), note that the basic package contains a class called BasicGraphicsUtils which consists of several static methods used for drawing various types of rectangles most commonly used for borders. The basic package also contains several other quite useful utility-like classes, and a quick browse through the basic package API docs will reveal some of these interesting members.

21.1.7  How L&F works

Now we'll discuss how the pluggable look-and-feel mechanism works and what actually happens when a Swing component is created, painted, and when the user changes the application's L&F during a Java session.

All Swing component constructors call the updateUI() method inherited from JComponent. This method also may be called with the SwingUtilities.updateComponentTreeUI() helper method. The latter method recursively updates the UI delegate of each child of the specified component (we've already seen how this is used in chapters 1 and 16).

The updateUI() method overridden by most Swing components typically has an implementation similar to the following:

    setUI((MenuUI)UIManager.getUI(this));

This invokes the static UIManager.getUI() method and passes a this component reference as parameter. This method, in turn, triggers a call to getUI() on the shared UIDefaults instance retrieved with the getDefaults() method.

The UIDefaults.getUI() method actually creates the ComponentUI object for a given JComponent. First it calls getUIClassID() on that component to discover the unique string ID associated with that class. For example, the JTree.getUIClassID() call returns the string: "TreeUI."

Prior to the process described above, the UIDefaults instance (which extends Hashtable) is initialized by the sub-class of LookAndFeel which is currently in charge. For instance, the Java look-and-feel (also referred to as "Metal") is defined by javax.swing.plaf.metal.MetalLookAndFeel. This class fills that look-and-feel's shared UIDefaults instance with key-value pairs. For each component which has a corresponding UI delegate implementation in the current L&F, a component ID String and a fully qualified UI delegate class name is added as a key/value pair to UIDefaults. For instance, the "TreeUI" ID key corresponds to the "javax.swing.plaf.metal.MetalTreeUI" value in MetalLookAndFeel's L&F UIDefaults. If a particular LookAndFeel implementation does not specify a UI delegate for some component, a value from the parent javax.swing.plaf.BasicLookAndFeel class is used.

Using these key/value pairs, the UIDefaults.getUI() method determines the fully qualified class name and calls the createUI() method on that class using the Java reflection API. This static method returns an instance of the proper UI delegate, for instance, MetalTreeUI.

Back to the updateUI() method, the retrieved ComponentUI object is passed to the setUI() method and stored into protected variable, ComponentUI ui, inherited from the JComponent base class. This completes the creation of a UI delegate.

Recall that UI delegates are normally in charge of performing the associated component's rendering, as well as processing user input directed to that component. The update() method of a UI delegate is normally responsible for painting a component's background, if it is opaque, and then calling paint(). A UI delegate's paint() method is what actually paints a component's content, and is the method we most often override when building our own delegates.

Now let's review this process from a higher level perspective:

1. The currently installed look-and-feel provides an application with information about UI delegates to be used for all Swing components instantiated in that application.

2. Using this information, an instance of a UI delegate class can be instantiated on demand for a given component.

3. This UI delegate is passed to the component and generally takes responsibility for providing the complete user interface (view and controller).

4. The UI delegate can be easily replaced with another one at run-time without affecting the underlying component or its data (e.g. its model).

21.1.8  Selecting an L&F

The Swing API shipped with Java 2 includes three standard L&Fs: Metal, Motif, and Windows (available only for Microsoft Windows users). The first one is not associated with any existing platform and is considered the "Java L&F." This look-and-feel is the default, and will be used automatically unless we directly change L&Fs in our app.

Reference: Apple provides the MacOS look-and-feel available for download at http://www.apple.com/macos/java/text/download.html.

Note: Swing also provides a Multiplexing look-and-feel which allows more than one UI delegate to be associated with a component at the same time. This L&F is intended for, but not limited to, use with accessible technologies.

To select a particular L&F we call the UIManager.setLookAndFeel() method and specify the fully qualified class name of a subclass of javax.swing.LookAndFeel which defines the desired L&F. The following code shows how to force an application to use the Motif L&F:

    try {

      UIManager.setLookAndFeel(

        "com.sun.java.swing.plaf.motif.MotifLookAndFeel");

    }

    catch (Exception e) {

      System.out.println ("Couldn't load Motif L&F " + e);

    }

Note that this should be called before we instantiate any components. Alternatively we can call this method and then use the SwingUtilities updateComponentTree() method to change the current L&F of a container and all its children, as discussed previously.

UI Guideline : Design Balance is affected by Look & Feel Selection

Beware! Although it is technically possible to update Look & Feel on-the-fly, this may often be visually undesirable. Different L&Fs use different graphical weights for each component e.g. bezel thickness on buttons. Therefore, a display which is designed to look good in a particular Look and Feel may be visually unbalanced and inelegant when switched to another L&F. This could be due to the change in White Space which balances against the graphical weight of elements such as bezels or it may be a change in alignment. For example, the "Malachite" L&F is visually heavy, as a rough guide, more white space will be required compared to Metal L&F for a well balanced effect.

21.1.9  Creating a custom LookAndFeel implementation

Swing provides the complete flexibility of implementing our own custom L&F, and distributing it with our application. This task usually involves overriding the rendering functionality of all Swing components supported by our L&F (default implementations are then used for each remaining component we are not interested in customizing). In general this is not a simple project, and will almost always require referencing Swing plaf source code.

The first step is to establish a basic idea of how we will provide consistent UI delegate appearances. This includes some thought as to what colors and icons will be used for each component, and whether or not these choices fit well together.

Then we move on to the most significant step in creating a custom look-and-feel, which is the implementation of a javax.swing.LookAndFeel sub-class. The following five abstract methods are the minimum that must be defined:

String getID(): returns the string ID of this L&F (e.g. "Motif").

String getName(): returns a short string describing this L&F (e.g. "CDE/Motif").

String getDescription(): returns a one line string description of this L&F.

boolean isNativeLookAndFeel(): returns true if the L&F corresponds to the current underlying native platform.

boolean isSupportedLookAndFeel(): returns true if the the current underlying native platform supports and/or permits this L&F.

UIDefaults getDefaults(): returns the L&F-specific Hashtable of resources (discussed above). This is the most important method of any LookAndFeel implementation.

However, to make implementation simpler, it is normally expected that we extend javax.swing.plaf.basic.BasicLookAndFeel instead of javax.swing.LookAndFeel directly. In this case we override some of the following BasicLookAndFeel methods (along with a few LookAndFeel methods above):

void initClassDefaults(UIDefaults table): fills a given UIDefaults instance with key/value pairs specifying IDs and fully qualified class names of UI delegates for each component supported by this L&F.

void initComponentDefaults(UIDefaults table): fills a given UIDefaults instance with key/value pairs using information (typically drawing resources, e.g. colors, images, borders, etc.) specific to this L&F.

void initSystemColorDefaults(UIDefaults table): fills a given UIDefaults instance with color information specific to this L&F.

void loadSystemColors(UIDefaults table, String[] systemColors, boolean useNative): fills a given UIDefaults instance with color information specific to the underlying platform.

The first two methods are the most significant, and we will discuss them in a bit more detail here.

21.1.10            Defining default component resources

The following code shows how to override the initComponentDefaults() method to store custom resources in a given UIDefaults instance. These resources will be used to construct a JButton UI delegate corresponding to this L&F (an imaginary implementation for now):

    protected void initComponentDefaults(UIDefaults table) {

      super.initComponentDefaults(table);

      Object[] defaults = {

        "Button.font", new FontUIResource("Arial", Font.BOLD, 12 ),

        "Button.background", new ColorUIResource(4, 108, 2),

        "Button.foreground", new ColorUIResource(236, 236, 0),

        "Button.margin", new InsetsUIResource(8, 8, 8, 8)

      };

      table.putDefaults( defaults );

    }

Note that the super-class initComponentDefaults() method is called before putting our custom information in the table, since we only want to override button UI resources. Also note that the resource objects are encapsulated in special wrapper classes defined in javax.swing.plaf package (Font instances are placed in FontUIResources, Colors in ColorUIResources, etc.). This is necessary to correctly load and unload resources when the current L&F is changed.

Note: Resources keys start with the component name, minus the "J" prefix. So "Button.font" defines the font resource for JButtons, while "RadioButton.font" defines the font resource for JRadioButtons. Unfortunately these standard resource keys are not documented, but they can all be found directly in Swing L&F source code. For example, see MetalLookAndFeel.java in package javax.swing.plaf.metal.

21.1.11            Defining class defaults

Providing custom resources, such as colors and fonts, is the simplest way to create a custom L&F. However, to provide more powerful customizations we need to develop custom extensions of ComponentUI classes for specific components. We also need to provide a means of locating our custom UI delegate classes so that UIManager can successfully switch a component's L&F on demand.

The following code overrides the initClassDefaults() method to store information about our imaginary myLF.MyLFButtonUI class (a member of the imaginary myLF look-and-feel package), which extends javax.swing.plaf.ButtonUI, and will be used to provide a custom L&F for JButton:

  protected void initClassDefaults(UIDefaults table) {

    super.initClassDefaults(table);

    try {

        String className = "myLF.MyLFButtonUI";

        Class buttonClass = Class.forName(className);

        table.put("ButtonUI", className);

        table.put(className, buttonClass);

    }

    catch (Exception ex) {

        ex.printStackTrace();

    }

  }

The initClassDefaults() implementation of the super-class is called before (not after) we populate the table with our custom information. This is because we don't intend to override all UI class mappings for all components. Instead we use the default settings for all but "ButtonUI." (We did a similar thing above in initComponentDefaults().) Also note that we place both the fully qualified class name of the delegate, as well as the Class instance itself, in the table.

Note: Placing only the class name in the defaults table does not provide correct functionality. As of Java 2 FCS, without a corresponding Class instance in the table as well, getUI() will not be able to retrieve instances of custom L&F delegates. We will see that this is the case in the examples below.

21.1.12            Creating custom UI delegates

Now it's time to show a simple pseudo-code implemention of our imaginary myLF.MyLFButtonUI class we've been relating our discussion to:

package myLF;

public class MyLFButtonUI extends  BasicButtonUI {

  private final static MyLFButtonUI m_buttonUI =

    new MyLFButtonUI();

  protected Color  m_backgroundNormal = null;

  // Declare variables for other resources.

  public static ComponentUI createUI( JComponent c ) {

    return m_buttonUI;

  }

  public void installUI(JComponent c) {

    super.installUI(c);

    m_backgroundNormal = UIManager.getColor(

      "Button.background");

    // Retrieve other resources and store them

    // as instance variables.

    // Add listeners. These might be registered to receive

    // events from a component's model or the component itself.

  }

  public void uninstallUI(JComponent c) {

    super.uninstallUI(c);

    // Provide cleanup.

    // Remove listeners.

  }

  public void update(Graphics g, JComponent c) {

    // Provide custom background painting if the component is

    // opaque, then call paint().

  }

  public void paint(Graphics g, JComponent c) {

    // Provide custom rendering for the given component.

  }

  // Provide implementation for listeners.

}

This class extends javax.swing.plaf.basic.BasicButtonUI to override some of its functionality and relies on basic L&F defaults for the rest. The shared instance, MyLFButtonUI m_buttonUI, is created once and retrieved using the createUI() method. Thus, only one instance of this delegate will exist, and it will act as the view and controller for all JButton instances with the myLF look-and-feel.

The installUI() method retrieves myLF-specific resources corresponding to JButton (refer back to our discussion of initComponentDefaults() above). We might also use this method to add mouse and key listeners to provide L&F-specific functionality. For instance, we might design our button UI such that an associated JButton's text changes color each time the mouse cursor rolls over it. An advantage of this approach is that we don't need to modify our application--we can still use normal JButtons. Once myLF is installed, this functionality will automatically appear.

The uninstallUI() method performs all necessary cleanup, including the removal of any listeners that this delegate might have attached to the component or its model.

The update() method will paint the given component's background if it is opaque, and then immediately call paint() (do not confuse this method with JComponent's paint() method).

Note: We always recommend to implement painting functionality in this way, but in reality the background of Swing components are more often painted directly within the paint() method (a quick skim through Swing UI delegate source code illustrates--for example, see BasicRadioButtonUI.java). If this is not the case the resulting background will be that painted by JComponent's painting routine. For this reason we often find no background rendering code at all in UI delegates.

This is a relatively minor issue. Just make sure that if you do want to take control of a component's background rendering, it is best to do so in UI delegate update() methods. This rendering should only occur if the associated component's opaque property is set to true, and it should be called before the main detail of its view is painted (update() should end with a call to paint()).

The paint() method renders a given component using the given graphical context. Note that to use an L&F successfully, the component class should not implement any rendering functionality for itself. Instead, it should allow its painting to be controlled by UI delegate classes so that all rendering is L&F-specific (refer back to chapter 2 for further discussion of painting issues).

Note: Implementing a custom L&F will make much more sense once we step through the first two examples. We suggest that you reference the above discussion often as you make your way through this chapter. Reviewing the discussion of MVC in chapter 1 may also be helpful at this point.

21.1.13            Metal themes

class javax.swing.plaf.metal.MetalTheme

Themes are sets of color and font definitions that can be dynamically plugged into MetalLookAndFeel, and immediately used by a Swing app on-the-fly if Metal is the current L&F. To create a theme we simply sub-class MetalTheme (or DefaultMetalTheme) and override a selection of its numerous getXX() methods to return a specific font or color. A quick browse through these methods shows implementations for all the colors and fonts used throughout the Metal L&F, allowing us to customize Metal appearance however we like. MetalLookAndFeel contains createDefaultTheme(), a protected method used to create the default metal theme, and provides us with the setCurrentTheme() method which allows us to plug in a new theme. The effects of plugging in a new theme are seen immediately. Themes offer a simple alternative to building a custom LookAndFeel, when all that is desired are some simple appearance changes.



[ Return to Swing (Book) ]


Top 10 read Java Articles
 Get free "1000 Java Tips eBook"

 Java Calendar and Date: good to know facts and code examples

 Array vs ArrayList vs LinkedList vs Vector: an excellent overview and examples

 How can I convert any Java Object into byte array? And byte array to file object

 The Java Lesson 1: What is Java?

 How do I compare two dates and times, date between dates, time between times and

 Maven vs Ant or Ant vs Maven?

 How to open, read, write, close file(s) in Java? Examples on move, rename and de

 Java Array

 Java: JLabel font and color


[ More in News Section ]
Java Lessons

The Java Lesson 1:
What is Java?
The Java Lesson 2:
Anatomy of a simple Java program
The Java Lesson 3:
Identifiers and primitive data types
The Java Lesson 4:
Variables, constants, and literals
The Java Lesson 5:
Arithmetic operations, conversions, and casts
The Java Lesson 6:
Boolean expressions and operations
The Java Lesson 7:
Bitwise operations
The Java Lesson 8:
Flow control with if and else
The Java Lesson 9:
switch statements
The Java Lesson 10:
for, while, and do-while statements
The Java Lesson 11:
Using break and continue
The Java Lesson 12:
Class methods and how they are called
The Java Lesson 13:
Using the Math class
The Java Lesson 14:
Creating and calling custom class methods
The Java Lesson 15:
Overloading class methods
The Java Lesson 16:
An introduction to objects and object references
The Java Lesson 17:
The String class
The Java Lesson 18:
The StringBuffer class
The Java Lesson 19:
Initializing and processing arrays of primitives
The Java Lesson 20:
Initializing and processing arrays of objects
The Java Lesson 23:
Inheritance and overriding inherited methods
The Java Lesson 24:
abstract classes and polymorphism
The Java Lesson 25:
Interfaces, instanceof, and object conversion and casting
The Java Lesson 26:
Introduction to graphical programming and the java.awt packa
The Java Lesson 27:
The Component class
The Java Lesson 28:
Containers and simple layout managers
The Java Lesson 29:
The Color and Font classes
The Java Lesson 30:
Drawing geometric shapes
The Java Lesson 31:
Choice, List, and Checkbox controls
The Java Lesson 32:
Using the Scrollbar graphical control
The Java Lesson 33:
Menus and submenus
The Java Lesson 34:
An introduction to applets and the Applet class
The Java Lesson 35:
Essential HTML to launch an applet and pass it parameters
The Java Lesson 36:
Mouse event processing
Java Lesson 37:
Menus and submenus
Java Lesson 38:
The WindowListener interface and the WindowAdapter class
Java Lesson 39:
An introduction to GridBagLayout
Java Lesson 40:
An introduction to the Java Collections API
Java Lesson 41:
Exception handling with try, catch, and finally blocks
Java Lesson 42:
Claiming and throwing exceptions
Java Lesson 43:
Multithreading, the Thread class, and the Runnable interface
Java Lesson 44:
An introduction to I/O and the File and FileDialog classes
Java Lesson 45:
Low-level and high-level stream classes
Java Lesson 46:
Using the RandomAccessFile class
Java Lessons by
Joh Huhtala: Update

Latest articles
 Java Profiler JProbe to Resolve Performance Problems Faster

 SSL with GlassFish v2, page 5

 SSL with GlassFish v2, page 4

 SSL with GlassFish v2, page 3

 SSL with GlassFish v2, page 2

 The Java Lesson 2: Anatomy of a simple Java program, page 2

 New site about Java for robots and robotics: both software and hardware.

 Exceptions -III: What's an exception and why do I care?

 Exceptions -II: What's an exception and why do I care?

 Exceptions: What's an exception and why do I care?

 Double your Java code quality in 10 minutes, here is receipt

 Murach's Java Servlets and JSP

 How to get ascii code from a char in Java?

 Can we just try without catch? Yes!

 Make Tomcat page load faster

 Make your Tomcat More secure - limit network address for certain IP addresses

 New Java book online starts now here...

 Implementing RESTful Web Services in Java

 Firefox trimming from 1 GB to 40 Mb with many tabs opened

 SSL with GlassFish v2

 My request to replublish Tech Tips

 Search JavaFAQ.nu site here

 New Advanced Installer for Java 6.0 brings XML updates and imports 3rd party MSI

 EJB programming restrictions

 Maven vs Ant or Ant vs Maven?

 Why Java does not use default value which it should?

 How to unsign signed bytes in Java - your guide is here

 The Java Lesson 3: Identifiers and primitive data types. Page 2

 The Java Lesson 7: Bitwise operations with good examples, click here! Page 4

 The Java Lesson 7: Bitwise operations with good examples, click here! Page 3


[ More in News Section ]


Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy