Adsense

J2ME Core Concepts

At the heart of Java 2 Micro Edition (J2ME) are three core concepts: configurations, profiles, and optional packages. You can't write a J2ME application without understanding these concepts, because they determine the features of Java that you can use, which application programming interfaces (APIs) are available, and how your applications are packaged.

Configurations

configuration is a complete Java runtime environment, consisting of three things:

  • A Java virtual machine (VM) to execute Java bytecode.
  • Native code to interface to the underlying system.
  • A set of core Java runtime classes.

To use a configuration, a device must meet certain minimum requirements as defined in the configuration's formal specification. Although a configuration does provide a complete Java environment, the set of core classes is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by configuration implementor. In particular, configurations do not define any user interface classes.

J2ME defines two configurations, the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC is for very constrained (limited) devices -- devices with small amounts of memory and/or slow processors. The VM used by the CLDC omits important features like finalization, while the set of core runtime classes is a tiny fraction of the J2SE core classes, just the basics from the java.lang,java.io and java.util packages, with a few additional classes from the new javax.microedition.iopackage. The CDC, on the other hand, includes a full Java VM and a much larger set of core classes, so it requires more memory than the CLDC and a faster processor. The CDC is in fact a superset of the CLDC. We'll discuss the configurations in detail in the next two articles in this series.

Profiles

profile adds domain-specific classes to a configuration to fill in missing functionality and to support specific uses of a device. For example, most profiles define user interface classes for building interactive applications.

To use a profile, the device must meet all the minimum requirements of the underlying configuration as well as any additional requirements mandated by the profile's formal specification.

There are several profiles in various stages of development. The first profile to be released was the Mobile Information Device Profile (MIDP), a CLDC-based profile for running applications on cellphones and interactive pagers with small screens, wireless HTTP connectivity, and limited memory. Another CLDC-based profile under development is the Personal Digital Assistant Profile (PDAP), which extends MIDP with additional classes and features for more powerful handheld devices. In terms of CDC-based profiles, the Foundation Profile (FP) extends the CDC with additional J2SE classes, the Personal Basis Profile (PBP) extends the FP with lightweight (AWT-derived) user interface classes and a new application model, and the Personal Profile extends the PBP with applet support and heavyweight UI classes. We'll also be discussing these profiles later on in this series.

Optional Packages

An optional package is a set of APIs in support of additional, common behaviors that don't really belong in one specific configuration or profile. Bluetooth support, for example, is defined as an optional package. Making it part of a profile wouldn't work, because none of the behaviors of a profile can be optional -- if a device supports a profile, it must support the entire profile -- and that would limit the profile to Bluetooth-enabled devices.

Optional packages have their own minimum requirements, of course, just like configurations and profiles. Optional packages also have specific dependencies on a particular configuration and/or one or more profiles -- they do not define a complete runtime environment, just sets of related APIs.

There are many optional packages in development, including the RMI Optional Package, which adds RMI support to CDC/FP-based profiles, the Java APIs for Bluetooth, which adds Bluetooth support to CLDC-based profiles, and the JDBC Optional Package for CDC/Foundation Profile, which defines a subset of JDBC (database access APIs) for use with CDC/FP-based profiles. Again, we'll be covering these later on in the series as the need arises.

The KVM and CVM

Two other terms you'll see mentioned in J2ME literature are KVM and CVM. These are the names of Java virtual machines for the CLDC (KVM) and the CDC (CVM), written specifically to work in the constrained environment of a handheld or embedded device and to be easily ported to different platforms. It should be noted, however, that the CLDC and CDC specifications do not require the use of the KVM or the CVM, only the use of a VM that adheres to the requirements of the specification in question. While many device manufacturers license the KVM or CVM from Sun Microsystems to serve as the core of their J2ME implementation, they are not required for J2ME compliance. It is a mistake, therefore, to consider the CLDC and KVM as synonymous, and similarly for the CDC and the CVM.

What It All Means

It should now be apparent that "J2ME application" is an ambiguous term. For what profile is the application intended? Which optional packages does it require? How much memory does it take? These are the questions you must ask yourself before you start application development, because they determine which language features and which classes your application can use. If you limit your application to CDC-based profiles, for example, you make development simpler of the many familiar J2SE APIs, but you cut out the low-end devices from your potential install base. Targeting CLDC-based profiles, on the other hand, makes your development task harder, especially when trying to shrink the size of your application to run on as many of the smaller devices as possible. These are the kinds of tradeoffs you'll have to make as you begin to work with J2ME. The information in this series will help you decide what's really important.

By Eric Giguère

[ Read More ]

What is Android?

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This beta version of the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

Features

  • Application framework enabling reuse and replacement of components
  • Dalvik virtual machine optimized for mobile devices
  • Integrated browser based on the open source WebKit engine
  • Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
  • SQLite for structured data storage
  • Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
  • GSM Telephony (hardware dependent)
  • Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
  • Camera, GPS, compass, and accelerometer (hardware dependent)
  • Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

Android Architecture

The following diagram shows the major components of the Android operating system. Each section is described in more detail below.

Applications

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.

Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

  • A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser
  • Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data
  • A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files
  • A Notification Manager that enables all applications to display custom alerts in the status bar
  • An Activity Manager that manages the life cycle of applications and provides a common navigation backstack

For more details and a walkthrough of an application, see Writing an Android Application.

Libraries

Android includes a set of C/C++ libraries used by various components of the Android system. These capabilities are exposed to developers through the Android application framework. Some of the core libraries are listed below:

  • System C library - a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices
  • Media Libraries - based on PacketVideo's OpenCORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
  • Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications
  • LibWebCore - a modern web browser engine which powers both the Android browser and an embeddable web view
  • SGL - the underlying 2D graphics engine
  • 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer
  • FreeType - bitmap and vector font rendering
  • SQLite - a powerful and lightweight relational database engine available to all applications

Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

Linux Kernel

Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.

[ Read More ]

10 Reasons Why Android Will Be Successful

I was always skeptical about the Gphone. I thought the entire idea of Google making a phone seemed silly to me. Google being a software/web company making hardware seemed too big a step. There were obvious comparisons with the iPhone and I was one of the biggest critics of Gphone for my colleagues and friends.

But a few weeks back when I first saw Google's press release about the Android, I got a little more interested. But my doubts were still there... And on 12th Nov, when I downloaded the SDK and saw the presentation videos, I realized this is what programming on mobile phones will be in the near future. I try to present a developer perspective on why programming on Android will be successful. May be the handset manufacturers and operators would want to differ, but for the developers I think Google's done a great job.

  • Free & Easy Access: Its "free" as in beer as well as "free" as in freedom. Operators and manufacturers will be able to customize and install for free. Thus, it'll be cheaper to build compared to say Windows Mobile, UIQ or Symbian. Also, Google/OHA intends to provide enough support for everyone which will be free or cheaper than anything else in the market.
  • Promise of JavaME: If you downloaded the SDK, you know that its like JavaME and programmed on Eclipse. JavaME (earlier, J2ME) already has a huge developer base and the learning curve to develop applications for Android is going to be a small one. The porting of already developed application would be easy. You could add new functionality to old JavaME applications very easily.
  • Good interfaces: The UI parts like Layouts, AdapterViews and using XML to design the UI, make Android what J2ME interfaces should always have been. Its more like J2MEPolish if you think of it as a developer. Something like Matisse (GUI Builder/ WYSIWYG Visual Designer) should have been done by Google for faster & easier GUI design... (I don't mean adding Swing, 'coz not every mobile device would be capable enough. Only a GUI builder).... 3D/2D with the openGL system is also easy to use. Its more like JSR239, so small learning curve again!
  • Great apps: Being able to use Google's applications like Google maps, Gmail.... and WebKit (not Google's tech) within your application reduces a lot of effort for the developer and helps new innovative features. The use of the notification area across the platform is another exciting feature for developers. It feels like being able to use the system like Symbian development with Java...
  • Linux based: Being Linux based is not new. Motorola among others already have a few Linux phones. But its worth mention because with Linux you know that there are fewer bugs as its been a few years that Linux is being used for mobiles. A lot of ironing as already been done, which means its stable than anything new Google would have developed.
  • Hardware requirement: The hardware requirements with Android are not yet to be found. But the promise seems like it'll be available on most devices. If this turns out to be true then it means that our application is available to a larger audience. May be the Optional APIs like LBS (Location-based services), Media API, 3D and Low-level hardware access will be device specific, but other than that, it'll be probably common. For the developer it means you have to think less about which JSRs the device supports.
  • Eclipse & Developer love: Google's "Don't Do Evil" philosophy means that quite a lot of people love them including developers. Google's earlier tools like GWT, Google Gears are examples of excellent tools that developers love. The SDK is Eclipse and this means there are lot of developers who already know to use the IDE and platform.
  • Publicity: As developers, the added advantage of developing for the Android is the publicity you may be able to get. Being the first apps to be built for Android, its obviously gonna catch the eye of a lot of other developers and consumers.
  • Cash prize: Its part of publicity as well as getting rich. If money and fame are motivations for you as a developer, then Google has hit it right!
  • Hype: Like they say, "Any kind of publicity is good publicity". Look at Apple's iPhone and you'll know that the hype created around it helped quite a lot of sales for the product. There so much hype around Android these days. Since Android/Gphones are already so much in the news, its pretty evident that.

[ Read More ]

Running J2ME Applications on Palm-powered Devices

by Ray Rischpater

The Palm Treo platform has gained wide appeal as a communications device for mobile professionals, enjoying several launches in the enterprise over the last few months. With the wide use of Java in business and the capabilities of these devices (including a large screen and keyboard), it only makes sense to explore using theent.) It's probably best to create a Palm PRC file for your application if you're going to be distributing the J2ME file exclusively to Palm-powered handheld users, or if you want to include it as part of a larger installation package.

Regardless of how you install the J2ME applications, you will be able to execute them in two ways: either from the list of applications in the IBM Java VM's list of applications, or as icons in the Palm application launcher. Simply tapping the icon for the J2ME application in the Palm application launcher will start up the IBM WEME Java virtual machine and seamlessly launch your J2ME application just as if it were a native Palm application.

An Excellent Bridge

The IBM WEME is the most mature and stable Java runtime for Palm Powered devices, and compares favorably with the Java MIDP 2.0 runtimes available on commercially available wireless handsets from Nokia, Motorola, Samsung, and other major vendors. Whether you're a Java developer looking to bring your enterprise or consumer application to Palm Powered handhelds, or simply an owner of a Palm Powered device looking to run a specific J2ME application, it's an excellent bridge between Palm OS and Java applications. Palm Treo (or related devices including the LifeDrive) to run legacy and new Java MIDP applications. Fortunately, the IBM WebSphere Everyplace Micro Environment for Palm OS Garnet (WEME) provides a MIDP2.0/CLDC 1.1 compliant run-time with support for file and personal information manager (PIM) integration (via JSR-75) as well as Web services development with JSR-172. This article shows you how to migrate your J2ME applications to Palm OS using the WEME, assuming you have some previous experience with Java MIDP development. If you need an introduction to J2ME, see one of the many other articles on J2ME from DevX (a full list can be found here).

Setting Out with the Developer Tools
In order to run J2ME applications, a target device must have a Java runtime consisting of the Java Virtual Machine (JVM) and the libraries that implement the J2ME classes. Java on Palm-powered handhelds is not new: Sun itself released a runtime for Java in the late nineties, which later became the basis for the first J2ME runtime. However, until recently it was difficult to obtain a Java runtime for Palm-powered devices appropriate for end-user application execution—most were fraught with stability, performance, and licensing issues. The IBM WEME changed this, providing a state-of-the-art stable runtime for many Palm-powered devices, including the Treo, LifeDrive, and select Tungsten and Zire devices.

The WEME consists of several components for Palm OS, including:

  • The Java MIDP runtime itself.
  • Localization overlays for the Java MIDP runtime for languages including Spanish, French, Italian, German, and Japanese.
  • An implementation of FileConnect and PIM integration classes specified in JSR-75.
  • An implementation of the Web Services API specified in JSR-172.
  • A preferences panel for Palm OS that lets users specify the degree of access Java applications have to PIM data, and localization overlays for this preferences panel.

You can get these components from one of two sources. If you're just casually interested in running J2ME applications on your handheld—say, a Verizon Treo 650—you can simply install the handheld-required packages here. Installing these components is easy—simply use the Palm Desktop Install Tool—but time-consuming, because there are so many PRCs; if you miss installing a PRC, you won't have the functionality you need to run some Java applications. As with all such things, it's best to read the documentation that accompanies the WEME carefully.

On the other hand, if you're planning on developing J2ME applications and want to test more thoroughly during development, you should obtain these components directly from IBM here. These components are built as Windows DLLs that work in conjunction with the Palm Simulator, letting you test and run your J2ME applications on your desktop workstation.

Looking Inside a Simple ApplicationLooking Inside a Simple Application
With the wide deployment of J2ME, there are many good resources for learning about J2ME development, and if you're new to Java and want to write your own applications, I suggest you consult one of them listed in the Related Resources section at the end of this article.
With the wide deployment of J2ME, there are many good resources for learning about J2ME development, and if you're new to Java and want to write your own applications, I suggest you consult one of them listed in the Related Resources section at the end of this article.

There are, however, a few basic concepts you should understand, even if your interest in the IBM WEME is simply to run other people's J2ME applications. First, J2ME applications are distributed as two pieces: a Java archive (ending in .jar) which contains the actual bytecodes for the Java application, and a description of the Java application, contained within a file ending in .jad. This split between your application's implementation and description makes it easy for J2ME-enabled devices to discover what capabilities are required to execute an application without using precious network resources, or cause a device to run out of room downloading a J2ME application which wouldn't fit on a device because it's too big.

All J2ME applications implement the MIDLet class, as you can see in the following listing:


import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class HelloWorld extends MIDlet implements CommandListener {
private Command exitCommand;
private TextBox tbox;

public HelloWorld() {
exitCommand = new Command("Bye", Command.EXIT, 1);
tbox = new TextBox("Hello World", "Hello World!", 25, 0);
tbox.addCommand(exitCommand);
tbox.setCommandListener(this);
}

protected void startApp() {
Display.getDisplay(this).setCurrent(tbox);
}

protected void pauseApp() {}
protected void destroyApp(boolean bool) {}

public void commandAction(Command cmd, Displayable disp) {
if (cmd == exitCommand) {
destroyApp(false);
notifyDestroyed();
}
}
}

This version of Hello World contains a single class, HelloWorld, which uses a J2ME TextBox to display the message "Hello World!" on a handheld. This class has five methods:

  • The application's constructor is named after the class itself. The J2ME runtime invokes it as it creates an instance of your application, and your constructor should do all pre-execution object creation and setup necessary for your application to launch.
  • The J2ME runtime invokes your application's startApp method to launch your application.
  • The J2ME runtime requires that you provide the pauseApp method, which the runtime will invoke if it needs to pause your application (say, to permit the user to answer an incoming phone call.)
  • The J2ME runtime requires that you provide the destroyApp method, which the runtime invokes when your application exits.
  • The commandAction method, required because the HelloWorld class implements the CommandListener interface. The commandAction method simply examines the incoming command and closes the application.

A JAD file describing the HelloWorld application must accompany the application. This file is simply a carriage-return delimited set of key/value pairs describing the application:

MIDlet-Version: 1.0.0
MIDlet-Vendor: Ray Rischpater KF6GPE
MIDlet-Jar-URL: helloworld.jar
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0
MIDlet-1: HelloWorld,,HelloWorld
MIDlet-Jar-Size: 3201
MIDlet-Name: HelloWorld
As you can see from the listing, some of the fields describe the capabilities required by the application of the executing device, while others describe the application itself:

  • The MIDlet-Version field indicates the version of your application.
  • The MIDlet-Vendor field indicates the name of the application's author.
  • The MIDlet-Jar-URL field indicates the URL (fully qualified or partial) to the JAR file containing the application.
  • The MicroEdition-Configuration field indicates the version number of the J2ME configuration required by the application (the classes associated with the J2ME runtime).
  • The MicroEdition-Profile field indicates the version number of the J2ME virtual machine required by the application.
  • The MIDlet-n field indicates the class file and class to instantiate when the application is launched. It can also contain the name of an arbitrary icon to show the user in the application manager.
  • The MIDlet-Jar-Size indicates the size of the JAR file containing the application in bytes.
  • The MIDlet-Name field contains the user-readable name of the application.

Unless you're building your J2ME application from scratch, you will need to choose which development environment you will use to create your JAD file for your application. You should base this decision on the properties that you enter and the type of JAR file that will result when you build your application.

Running Your Application on a Palm-powered HandheldTo run your application on your Palm-powered device, you must deliver the JAD and JAR files to the WEME runtime. There are two ways to do this: via a network connection and by creating a Palm PRC file containing the JAD and JAR files.

My personal preference is to simply use the WEME runtime to download the JAD and JAR files over the network. If you're installing a third-party application, you can use the device's built-in Web browser to select a link to the application, or follow these steps:

  • From the application launcher, run the IBM WEME application manager by touching "IBM Java VM."
  • Press the Install Button.
  • Enter the URL to your jad file in the URL field (for example, http://www.myhost.com/j2me/helloworld.jad). You can use the various shortcuts available from the triangle menu to speed input of common URL components such as the protocol and domain bits of the URL.
  • Touch "OK."
  • The application manager may prompt you to confirm that you wish to install an application from an untrusted source. Confirm the installation if you feel you've entered the URL correctly.
  • The application manager will inform you that the application has been installed successfully.

The other way to install your application is to create a Palm PRC database from the class file and JAD file using the JarToPrc file included with the IBM WEME from IBM. This tool, described in the documentation that accompanies the IBM WEME, takes either the URL to a JAD file on the Internet or can have a JAD file dropped on its main window, and will download the associated JAR file and create a Palm PRC database you can HotSync to your Palm device. (It can also be run from the command line, letting you automate the process of creating a Palm PRC in your build environment.) It's probably best to create a Palm PRC file for your application if you're going to be distributing the J2ME file exclusively to Palm-powered handheld users, or if you want to include it as part of a larger installation package.

Regardless of how you install the J2ME applications, you will be able to execute them in two ways: either from the list of applications in the IBM Java VM's list of applications, or as icons in the Palm application launcher. Simply tapping the icon for the J2ME application in the Palm application launcher will start up the IBM WEME Java virtual machine and seamlessly launch your J2ME application just as if it were a native Palm application.

An Excellent Bridge
The IBM WEME is the most mature and stable Java runtime for Palm Powered devices, and compares favorably with the Java MIDP 2.0 runtimes available on commercially available wireless handsets from Nokia, Motorola, Samsung, and other major vendors. Whether you're a Java developer looking to bring your enterprise or consumer application to Palm Powered handhelds, or simply an owner of a Palm Powered device looking to run a specific J2ME application, it's an excellent bridge between Palm OS and Java applications.

[ Read More ]

Double Your Java Code Quality in 10 Minutes

JProfiler let's find your bugs in just 10 minutes!

It is true! Exactly 10 minutes you need to download it, run with your program and find why your program spends much memory and time in just that Java class! Find why just one-two classes try to sabotage the whole your Java project.

JProfiler enables Java developers to tune up the performance of their Java programs. It combines in a single tool the capabilities for detailed examination of VM load and applications’ work, for memory usage and CPU loading, etc.

JProfiler is an ideal choice for profiling of embedded devices and target boards, due to the highly optimized architecture and low memory consumption of the agent profiling component. JProfiler allows for both local and remote profiling. It can be used as a stand-alone tool or within the Eclipse environment.

The examination of the runtime behavior with JProfiler can be very helpful for software optimization. In a user-friendly manner, JProfiler visualizes detailed information of the profiled applications. It shows the method calls and object instantiations, byte size, and useful source code links for each object created by a method. The memory view and the CPU view are thread-based -they show the corresponding information in a tree for every thread running in the profiled JVM.

The profiler agent has very low memory consumption (less than 1 MB), which is very important while profiling devices with limited memory resources. Profiled applications do not increase their memory consumption as it does happen with other profiler agents.

JProfiler's Main Features:

  • Live profiling of a local session
  • Offline profiling
  • Live profiling of a remote session
  • Snapshot comparisons
  • Memory profiling: All objects, Recorded objects, Allocation call tree, Allocation hot spots
  • Heap walker: Classes, Allocations, References, Data, Time
  • CPU profiling
  • Thread profiling: Thread history, Thread monitor, Deadlock detection graph, Current monitor usage, Monitor usage history, Monitor usage statistics
  • VM telemetry: Heap, Objects, Garbage collector, Classes, Threads
Related Links:

Download Java Tools » Debugging, profiling » JProfiler

[ Read More ]

MVC Design Pattern

Definition

The Model/View/Controller(MVC) is an architecture design pattern. Model means data, View means representation and Controller works on data and representation. MVC focuses on decouple the triad relationships among data, representation and controller.

Where to use & benefits

  • Application architecture design.
  • Any data related design, including non-visual application.
  • Decouple complex object to improve maintainability.
  • Increase object reusability.
  • Achieve design flexibility.
  • Related patterns include
       - Almost all patterns can be used with MVC.

History

The Model/View/Controller(MVC) originates from Smalltalk, an OO programming language.

Core issue

MVC consists of three kind of objects. The Model is an internal representation of the data, the View is the screen presentation of GUI, and the Controller coordinates changes between the Model and View.

SCJD project design

To achieve the MVC architecture in your project, you have to decouple View and Model by Controller. Your GUI as View should be designed as a module. It can be launched separately. Your data related classes as Model should be treated as a module too. Your controller classes should response to any data change on the GUI. Such design will increase reusability and flexibility.

Try to visualize that the user reacts with the GUI, a DataManager(Controller) listens to the GUI's call. If the user needs to load data, such request is sent to the DataManager, the DataManager starts loading, searching and extracting the requested data from the server and sends it back to the GUI. GUI is responsible to display data.

Here the server acts as Model, the DataManager acts as Controller and GUI acts as View. The DataManager can be used for both remote and local modes (design two constructors for both modes), the GUI can be replaced with any design and the data related classes can be packaged together and put on local and server sides. All of the three objects can be reused for other projects with little code alteration.

If you grasp such concept and skill, you will save a lot of time in designing and developing your projects in the future. This is the so-called OOA/OOD.

[ Read More ]

Make Tomcat Page Load Faster

If you use Tomcat server to serve remote clients over the Internet you can significantly improve page loading time by enabling content compression. A content become compressed when it transports over the Internet. All modern browsers support HTTP/1.1 GZIP compression and if your server also enables it, the page load time decreases dramatically. They just popping out in a browser, like if they were served from a local server.

Enable compression In Tomcat for certain file types

Enable compression by adding compression="on" or compression="force". Please notice that MIME type of content type to be compressed is defined in compressableMimeType variable. Those variables are optional for Tomcat Connector and are defined in server.xml file. This file is the part of Tomcat configuration files and situated in conf directory under Tomcat home directory.

Two more useful parameters are, example:

compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"

Skip compression for small files in Tomcat

Compression minimal size is good to skip compressing too small files - the compression overhead will take away all benefits and can result in even bigger file.

Look at the next example below:


<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="5" maxSpareThreads="25"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml" />

[ Read More ]

Try without catch?

Many people believe that if they use try block then they are obligated to continue with catch block, catch some Exception and do something with it. It is not quite right opinion.

You can use try block with following final block without catch, like this:


try {
int i = 10;
//....
// do smth. here
} finally {
int i = -10
//....
// finalize smth here
}

avoiding catch block. Maybe you do need it at all, you simply do not mind about it. It is a fact that many programmers have no code in catch block So, why bother about it all. If you do not have a strategy for error handling do not do it all! Just continue.

Someone still may ask: so why we need try if we do not catch? Is not it simpler to run just plain code without any blocks. Please do not forget that we use try to try something, if it does not go we can continue anyway. Plain code just will stop and cause runtime error, which will break your program flow.


[ Read More ]