E-voting system

CHAPTER 1: INTRODUCTION

Introduction

Motivation

Objectives

The aim of this project is to design an e-voting system that makes use of Java and Bluetooth technologies. The specific objectives of this project are:

• To create voting software that using Java 2 Micro Edition (J2ME) that can run on any mobile devices which will act as server and clients.
• To develop Java 2 Micro Edition (J2ME) based voting system that able to fully utilize the functionality of Bluetooth technologies by transferring data (voter database, voting records, etc.), between two mobile devices.
• To build a low cost and reliable client-server based voting system.

Outline of Thesis

The content of this thesis is organized according to the chapter. Chapter 1 is mainly about the brief introduction of the project done with some motivation and objectives. Chapter 2 is generally about the literature review of Java 2 Micro Edition (J2ME), Bluetooth and JSR-82 technologies, and also overview about the BVote itself. Next, Chapter 3 is about the methodology and details of the design whereas Chapter 4 is about the implementation of program through simulator and hardware devices since it is the output of the work done on Chapter 3. Chapter 5 is in relation to the presentation of data of the program with some program module hierarchy and classes used for Java programming. Then, Chapter 6 is concerning the discussion about the program outcome and its limitation. Finally, Chapter 7 is the final part of any reports or thesis which is the conclusion and some recommendations for future research.

CHAPTER 2: LITERATURE REVIEW

Overview of Java Micro Edition (Java ME)

Introduction

Java is a programming language originally developed by James Gosling at Sun Microsystems, which is now a subsidiary of Oracle Corporation. It was released in 1995 as a core component of Sun Microsystems’ Java platform. Java is general-purpose, concurrent, class-based, and object-oriented, and is specifically designed to have as few implementation dependencies as possible. It is intended to let application developers “write once, run anywhere”.

Recognizing that “one size doesn’t fit all”, Sun has defined and supports four editions of Java aiming different application environments and segmented many of its APIs so that they belong to one of the platforms. The platforms are:

• Java Card – aimed for smartcards.
• Java Platform, Micro Edition (Java ME) – aimed at small and memory constrained devices by means of environments with limited resources.
• Java Platform, Standard Edition (Java SE) – aimed at standard desktop and workstation environments.
• Java Platform, Enterprise Edition (Java EE) – aimed at heavy duty server systems, large distributed enterprise or Internet environments.

Java ME was formerly known as Java 2 Platform Micro Edition (J2ME), is a Java platform designed for mobile devices and embedded systems. Java ME technology was originally created in order to deal with the constraints associated with building applications for small devices with as little as 128KB of RAM and with processors a lot less powerful than those used on typical desktop and server machines. Thus, Sun defined the basics for Java ME technology to fit such a limited environment and make it possible to create Java applications running on small devices with limited memory, display and power capacity.

There are three core concepts in the Java ME technology:

• Configuration – provides the most basic set of libraries and virtual machine capabilities for a broad range of devices.
• Profile – set of APIs that support a narrower range of devices.
• Optional package – set of APIs in support of additional, common behaviours that don’t really belong in one specific configuration or profile

J2ME consists of a set of profiles. Each profile is defined for a particular type of device and consists of a minimum set of class libraries required for the particular type of device and a specification of a Java virtual machine required to support the device. A profile itself does not do anything; it just defines the specification. Since profiles are subsets of configurations, profiles are implemented with a configuration. Ultimately, Java ME platform has been divided into two base configurations which is Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC).

Java ME was designed to use profiles and configurations to enables devices of varying ability to able to run Java ME applications on the Kilobytes Virtual Machine (KVM), which is the micro version of Java Virtual Machine (JVM). Figure 1 illustrates how the CDC and the CLDC together make Java ME. The diagram also shows an overview of the components of Java ME architecture, and how it fits in the overall Java model.

Configurations

Configuration is a preliminary Java platform for devices with similar requirements with respect to total memory, processing speed, power and display constraints. Specifically, a configuration consists of Java language features, JVM features and a limited set of generalized APIs. Configurations are closely linked with JVM. In fact, configuration is a term identifying Java language features as a set of APIs and a specific JVM for that particular configuration. The dividing line as to what configuration applies to a device is for the most part, dependent on the memory, processing power, network connectivity and display constraints of a device.

Connected Limited Device Configuration (CLDC).

The Connected Limited Device Configuration (CLDC) is a fundamental part of the architecture of the Java ME that targeting resource-constraint devices like mobile phones. It is specifically designed to meet the needs for a Java platform to run on devices with limited memory, processing power and graphical capabilities. CLDC contains a strict subset of the Java-class libraries, and is the minimum amount needed for a Java virtual machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration. When coupled with one or more profiles, the CLDC gives developers a solid Java platform for creating applications for consumer and embedded devices.

CLDC is designed to bring the many advantages of the Java platform to network-connected devices that have limited processing power, memory, and graphical capability. Target devices typically have the following capabilities:

• A 16-bit or 32-bit processor with a clock speed of 16MHz or higher.
• At least 160 KB of non-volatile memory.
• At least 192 KB of total memory available for the Java platform.
• Low power consumption, often operating on battery power.
• Connectivity to some kind of network, often with a wireless, intermittent connection and limited bandwidth.

On top of the different configurations Java ME platform also specifies a number of profiles defining a set of higher-level APIs that further define the application. A widely adopted example is to combine the CLDC with the Mobile Information Device Profile (MIDP) to provide a complete Java application environment for mobile phones and other devices with similar capabilities.

Connected Device Configuration (CDC)

CDC is a specification of a framework for Java ME applications describing the basic set of libraries and virtual-machine features that must be present in an implementation. The targets for CDC-based technology comprise a broad range of consumer and embedded devices like smart communicators, pagers, high-end personal digital assistants (PDAs), and set-top boxes. Within this range, CDC is the basis for several standard API bundles that address the needs of developers of applications for specific categories of devices.

Devices that support CDC typically include a 32-bit microprocessor/controller and make about 2 MB of RAM and 2.5 MB of ROM available to the Java application environment. The CDC configuration was designed to bring the many advantages of the Java platform to a broad range of network-connected consumer and embedded devices.

CDC versus CLDC

The CLDC is different from, yet also a subset of the CDC. The two configurations are independent of each other, however, so they should not be used together to define a platform. The CLDC is a proper subset of the CDC. Neither the CLDC nor the CDC is a proper subset of the J2SE platform, however, because both of these configurations add new classes necessary to deliver services on their respective families of devices. Like the CDC, the CLDC specifies the level of support of the Java programming language required, the required functional support of a compliant Java VM, and the set of class libraries required. Figure 2 shows the relationship between the two configurations and the J2SE platform.

Profiles

Profiles are an extension of its underlying configuration. A profile simply is a set of APIs but unlike configurations, profiles are closer and specific to the target device capabilities. They are intended to include device specific APIs providing those functionality missing at configuration level such as user interface, persistence, etc. Profiles obtain the required foundation from configuration and hence are layered above configurations.

Currently, there are a handful profiles available and a few more are being finalized. MIDP is a profile supported by CLDC while CDC support three different profiles namely the Foundation Profile (JSR 219), Personal Basis Profile (JSR 217) and Personal Profile (JSR 216).

Foundation Profile (FP)

Foundation Profile is the most basic of the CDC family of profiles. It is a skeleton upon which a developer can create a new profile. The FP APIs, together with CDC APIs provides a complete Java ME JRE for consumer electronics and embedded devices. It is a set of Java APIs tuned for low-footprint devices that have limited resources that do not need a graphical user interface system. It provides a complete Java ME application environment for consumer products and embedded devices but without a standards-based GUI system. Version 1.1.2 is specified in JSR 219 and implements a subset of Java SE 1.4.2, including a set of security-related optional packages, such as Java Authentication and Authorization Service (JAAS), Java Secure Socket Extension (JSSE), and Java Cryptography Extension (JCE).

The Mobile Information Device Profile (MIDP)

The Mobile Information Device Profile (MIDP), combined with the Connected Limited Device Configuration (CLDC), is the Java runtime environment for today’s mobile information devices such as phones and entry level PDAs. MIDP provides the core application functionality required by mobile applications – including the user interface, network connectivity, local data storage, and application lifecycle management.

Currently, there are three version of MIDP which are MIDP 1.0, MIDP 2.0 and MIDP 3.0. With the configuration and profiles, the actual application then resides, using the different available APIs in the profile.

Following in the tradition of Java parlance, MIDP applications are called MIDlets. A MIDlet is a Java application that uses the MIDP profile and the CLDC configuration, created by a Java ME software developer, such as a game, a business application or other mobile features. These MIDlets can be written once and run on every available device conforming to the specifications for Java ME technology. The MIDlet can reside on a repository somewhere in the ecosystem and the end user can search for a specific type of application and having it downloaded over the air to another device.

Kilobyte Virtual Machine (KVM)

The Kilobyte virtual machine (KVM) is a virtual machine derived from the Java Virtual Machine (VM) specification. The VM that comes with the CLDC reference implementation is called the Kilobyte Virtual Machine (KVM) because it uses only a few kilobyte of runtime memory as opposed to megabyte. It is a reference implementation that adheres to the CLDC specification’s description of a compliant VM. It is designed for small devices as it has a small memory footprint. It supports a subset of the features of the higher end JVM.

For low-end, resource-limited products, Java ME and the KVM support minimal configurations of the Java virtual machine and Java APIs that capture just the essential capabilities of each type of device. KVM can be deployed flexibly to address a range of trade-offs between space and functionality. The KVM is engineered and specified to support the standardized, incremental deployment of the Java virtual machine features and the Java APIs included in the Java ME architecture.

Overview of Bluetooth Technology

Introduction

Bluetooth is a proprietary open wireless communication protocol for exchanging data over short distances by using short length radio waves from fixed and mobile devices, creating personal area networks (PANs). The Bluetooth wireless connectivity technology was originally envisioned in 1994 by Ericsson as a way for mobile devices to communicate with each other at short ranges — up to 30 feet, or 10 meters. While Bluetooth is positioned as a replacement for cable, infrared, and other connection media, it offers a variety of other services, and creates opportunities for new usage models. It can connect several devices, overcoming problems of synchronization and it works quietly, unconsciously, and automatically in the background.

Bluetooth has client-server architecture. In client-server architecture, the one that initiates the connection is the client, and the one who receives the connection is the server. Bluetooth is a great protocol for wireless communication because it’s capable of transmitting data at nearly 1MB/s, while consuming 1/100th of the power of Wi-Fi. In order for Bluetooth devices to communicate properly, they all need to conform to the Bluetooth specification. The Bluetooth specification, like any other specification, defines the standard that a Bluetooth device should adhere to, as well as rules that need to be enforced when communicating. The Bluetooth protocol stack and profiles together comprise the Bluetooth specification.

Bluetooth Protocol Stack

Bluetooth uses a variety of protocols. Core protocols are defined by the trade organization Bluetooth Special Interest Group (SIG). Additional protocols have been adopted from other standards bodies. The Bluetooth stack is the software or firmware component that has direct access to the Bluetooth device. The Bluetooth protocol stack is split in two parts: a “controller stack” containing the timing critical radio interface, and a “host stack” dealing with high level data. It has control over things such as device settings, communication parameters, and power levels for the Bluetooth device. The stack itself consists of layers, and each layer of the stack has a specific task in the overall functionality of the Bluetooth device. Since Bluetooth device manufacturers are not required to use all of the layers in the stack, listed below are the overview of the core protocols and those adopted protocols that are widely used and implemented in almost every Bluetooth device:

• L2CAP: The “Logical Link Controller and Adaptation Protocol” used to send packets between host and client. This layer is the multiplexer of all data passing through the unit. It receives application data and adapts it to the Bluetooth format. Qualities of Service (QoS) parameters are exchanged at this layer.
• LMP: The “Link Manager Protocol” uses the links set up by the baseband to establish connections and manage piconets. Responsibilities of the LMP also include authentication and security services, and monitoring of service quality.
• SDP: The “Service Discovery Protocol” is used to find services on remote Bluetooth devices.
• HCI: The “Host Controller Interface” is the interface between the radio and the host computer. HCI is the dividing line between software and hardware. The HCI is the driver interface for the physical bus that connects these two components.
• RFCOMM: The “Radio Frequency COMMunication” is very easy and uncomplicated. Widely known as the virtual serial port protocol, it is used to stream simple data.
• OBEX: The “Object Exchange” communication protocol is used to exchange physical data such as files, images, and so on in binary format.

Bluetooth Profiles

Bluetooth profiles are intended to ensure interoperability among Bluetooth-enabled devices and applications from different manufacturers and vendors. A Bluetooth profile is a designed set of functionality for Bluetooth devices that defines the roles and capabilities for specific types of applications. If Bluetooth-enabled devices want to interact, having the bare minimum Bluetooth stack is not enough. It also needs to conform to a particular profile. Listed are some of the Bluetooth profiles:

• The Generic Access Profile defines connection procedures, device discovery, and link management. It also defines procedures related to use of different security models and common format requirements for parameters accessible on the user interface level. At a minimum all Bluetooth devices must support this profile.
• The Service Discovery Application and Profile defines the features and procedures for an application in a Bluetooth device to discover services registered in other Bluetooth devices, and retrieves information related to the services.
• The Serial Port Profile defines the requirements for Bluetooth devices that need to set up connections that emulate serial cables and use the RFCOMM protocol.
• The LAN Access Profile defines how Bluetooth devices can access the services of a LAN using PPP, and shows how PPP mechanisms can be used to form a network consisting of Bluetooth devices.
• The Synchronization Profile defines the application requirements for Bluetooth devices that need to synchronize data on two or more devices.

Bluetooth Network Topology

Bluetooth-enabled devices are organized in groups called piconets or also known as Personal Area Network (PAN). A piconet consists of one master and up to seven active slaves. The slaves in a piconet can only link to the master. Slaves cannot directly transmit data to one another. In fact, the master acts as a switch for the piconet and all traffic must pass through the master. A master and a single slave use point-to-point communication. If there are multiple slaves; point-to-multipoint communication is used. A master unit is the device that initiates the communication. A device in one piconet can communicate to another device in another piconet, forming a scatternet. A Bluetooth unit can be a slave in two or more piconets, but only one Bluetooth can be a master. Devices that participate in two or more piconets may act as gateways, forwarding traffic from one piconet to another.Notice that a master in one piconet may be a slave in another piconet:

The basic concepts of any Bluetooth application consist of the following five components:

• Stack Initialization
• Device Management
• Device Discovery
• Service Discovery
• Communication

Bluetooth vs. Infrared

The major difference between the two methods of data transmission is that Bluetooth is based on radio technology (from 2.4GHz bands upwards), while Infrared utilizes invisible light in the 400 – 700nm wavelength. Infrared is fairly reliable and doesn’t cost much to build into devices but it does have drawbacks:

• It’s line-of-sight, so a sender must align with its receiver.
• It’s one-to-one, so a device can’t send to multiple receivers at the same time.

Infrared’s advantages are consequences of its disadvantages:

• Because it’s line-of-sight, interference is uncommon.
• Because it’s one-to-one, message delivery is reliable: each message sent goes to the intended recipient no matter how many infrared receivers are in the room.

Bluetooth vs. 802.11b

Both Bluetooth and IEEE 802.11b are wireless communication protocols and both operate in the 2.4GHz band, but they are designed to accomplish different goals. A major difference is that 802.11b was not designed for voice communications, while any Bluetooth connection can support both data and voice communications.

The 802.11b protocol is designed to connect relatively large devices with lots of power and speed, such as desktops and laptops. Devices communicate at up to 11 Mbit/sec, at greater distances (up to 300 feet, or 100 meters). By contrast, Bluetooth is designed to connect small devices like PDAs, mobile phones, and peripherals at slower speeds (1 Mbit/sec), within a shorter range (30 feet, or 10 meters), which reduces power requirements.

Overview of Java APIs for Bluetooth Technology (JSR-82)

Java APIs for Bluetooth Wireless Technology

Bluetooth is an important emerging standard for wireless integration of small devices. The specification standardizes a set of Java APIs to allow Java-enabled devices to integrate into a Bluetooth environment. Previously, there has been no standardized way to develop Bluetooth applications until JSR 82 came into play JSR-82 is a standard defined by the Java Community Process for providing a standard to develop Bluetooth applications using the Java programming language. It is the first open and non-proprietary standard for developing Bluetooth applications. The JSR-82 API hides the complexity of the Bluetooth protocol stack behind a set of Java APIs that allow to focus on application development rather than the low-level details of Bluetooth, by exposing a simple set of Java API’s. JSR 82 is based on version 1.1 of the Bluetooth Specification.

JSR 82 consists of two optional packages: the core Bluetooth API and the Object Exchange (OBEX) API. The latter is transport-independent and can be used without the former. The Java APIs for Bluetooth do not implement the Bluetooth specification, but rather provide a set of APIs to access and control a Bluetooth-enabled device. JSR 82 concerns itself primarily with providing Bluetooth capabilities to J2ME-enabled devices. Java APIs described in the JSR-82 interface for following Bluetooth Protocols/Profiles:

• SDAP – Service Discovery Application Profile
• RFCOMM – Serial Cable Emulation Protocol
• L2CAP – Logical Link Control and Adaptation Protocol
• GOEP – Generic Object Exchange (OBEX) Profile

The API Architecture

The goal of the specification was to define an open, non-proprietary standard API that can be used by all J2ME-enabled devices. Therefore, it was designed using standard J2ME APIs and CLDC/MIDP’s Generic Connection Framework.

JSR 82 requires that the Bluetooth stack underlying a JSR 82 implementation be qualified for the Generic Access Profile, the Service Discovery Application Profile, and the Serial Port Profile. The stack must also provide access to its Service Discovery Protocol, and to the RFCOMM and L2CAP layers. The APIs are designed in such a way that developers can use the Java programming language to build new Bluetooth profiles on top of this API as long as the core layer specification does not change. JSR 82 includes APIs for OBEX and L2CAP so that future Bluetooth profiles can be implemented in Java, and these are already being used for that purpose. Figure 4 shows where the APIs defined in this specification fit in CLDC/MIDP architecture.

Capabilities of JSR-82

These are the properties and capabilities of JSR-82 in a nutshell. The JSR-82 API is intended to provide the following capabilities options:

1. Manage the Local Bluetooth Device settings.
2. Discover other Bluetooth devices in the neighbourhood.
3. Search for Bluetooth services on the discovered Bluetooth devices.
4. Connect to any of those Bluetooth services and communicate with it.
5. Register a Bluetooth service on the Local Bluetooth Device, so that other Bluetooth devices can connect to it.
6. Establish RFCOMM, L2CAP, and OBEX connections between devices
7. Manage and control the communication connections.
8. Provide the security to all of the above options.

Reasons on Using Java Platform Micro Edition (Java ME)

Java ME has significant advantages over other languages and environments that make it suitable for Bluetooth Voting System (BVote). The advantages of Java are as follows:

• Most of mobile devices nowadays are compatible and supports Java ME application development. Java ME has a particularly high market penetration. According to Morales and Nelson, approximately 68% of mobile phones are Java ME capable, which equates to more than 350 million Java ME capable mobile devices worldwide.
• Java ME is an open source and free. There are no licensing expenses needed for the SDK.
• Java ME is platform-independent. Java has the ability to move easily from one computer system to another.Java is a platform-independent at both the source and binary levels. It can run on any operating system without modification
• Simplicity and ease-of-use. Java was designed to be easy to use and is therefore easy to write, compile, debug, and learn than other programming languages. Java uses automatic memory allocation and garbage collection. In addition, the I/O and network library is very easy to use.
• Java ME is robust. Java compilers are able to detect many problems that would first show up during execution time in other languages.
• Java ME is interpreted. An interpreter is needed in order to run Java programs. With Java, the program need only be compiled once, and the bytecode generated by the Java compiler can run on any platform.

Reasons on Using Bluetooth Technology

There are various reasons to use a Bluetooth technology. These reasons are mainly based on the advantages of the Bluetooth technology itself that it offers to users.

• Availability of Bluetooth connectivity wireless technology in mobile devices. Bluetooth has already become a standard inclusion and important feature on most mobile phones nowadays.
• No cost per transmission. As an alternative for the current Short Message Services (SMS) that would be charge per transmission, Bluetooth cost no charge for its communication.
• Low energy consumption as Bluetooth uses low power signals. Thus, the technology requires little energy and hence uses less battery or electrical power.
• Standardize technology. Since Bluetooth is a standardized wireless specification, a high level of compatibility among devices is guaranteed. In addition, Bluetooth is a universal, world-wide, wireless standard.
• Ability to keep information private. In order to make a transfer or allow someone to access the files in the phone, it will need to give the access by accepting or rejecting the request through the phone. Therefore, authentication will prevent unauthorized access to important data and make it very difficult to listen in.
• Signals are omni-directional and can pass through walls. Communicating devices do not need to be aligned and do not need an unobstructed line of sight. Besides, Bluetooth uses frequency hopping. Its spread spectrum approach greatly reduces the risk that communications will be intercepted.

Overview on Bluetooth Voting System (BVote)

The name of this project is BVote. BVote is being developed using Java 2 Micro Edition (J2ME) programming language in order to create an open source, freely available and platform-independent mobile voting platform with basic connectivity options to expedite the process of data transfer and multi-user collaboration. It consists of two parts which are server and client. The server is the one that become the administrator. The administrator is responsible to manage all the registration of the voters and set the question(s) of the voting. As for the client, it can only log in the voting system as a voter and vote for the question that is being sent.

In order to create such a program like BVote, it must meet some basic requirements before the application can be run. Firstly, as BVote is being developed using J2ME, therefore both server and client must use mobile devices as their platform. In addition, both server and client must be able to communicate with each other through Bluetooth technology. Last but not least, since BVote is voting system application software, BVote must accept processing, storing, and updating functions especially for the server part.

Research on E-Voting System

• http://en.wikipedia.org/wiki/Electronic_voting
• http://en.wikipedia.org/wiki/Electronic_voting_examples
• http://en.wikipedia.org/wiki/Indian_voting_machines
• http://www.topbits.com/e-voting.html
• http://www.howstuffworks.com/e-voting.htm
• http://avirubin.com/vote/analysis/

CHAPTER 3: DESIGN METHODLOGY AND DETAILS

This chapter addressed issues that arise when implementing and using the Java APIs for Bluetooth Wireless Technology and designing the software application using Java 2 Micro Edition (J2ME). Lastly, this section discusses issues on the hardware and technology that involved on the implementation and development of Bluetooth Voting System.

Hardware

Mobile Phone

Mobile phone is acting as the main hardware for Bluetooth Voting System, both for server and client part. Nowadays, a mobile phone in market is growing up rapidly with respectively to mobile technology. The fast growing of the mobile technology has benefited and improved the quality of life. In addition, the Bluetooth technology has become the main features in all the latest product of mobile devices available on market. With this specification, the objective to develop a low cost system has been met. As this project make the most of the Bluetooth as a connection medium for voting process, mobile phone has been fully utilized due to its ability in supporting Bluetooth.

PC or Laptop

In the development work, PC has been used as a workstation for programming and simulation process. For the simulation purpose, it had been perform in PC by using Java IDE and mobile phone emulator generated by Sun Wireless Toolkits. After the simulation work is done, a .jar executable file will be installing in mobile phones for real time hardware testing.

Software and Development Toolkit

The following software will be used:

• J2SDK1.5.0
• Eclipse 3.0.1: one of the best Java IDE 😉
• J2ME Wireless toolkit 2.2
• EclipseME 0.7: Eclipse plugin to help develop J2ME code
• ProGuard 2.1: class file shrinker and obfuscator.

Wireless Toolkit 2.5.2

The Sun Java Wireless Toolkit for CLDC (formerly known as Java 2 Platform, Micro Edition (J2ME) Wireless Toolkit) is a state-of-the-art toolbox for developing wireless applications that are based on Java ME’s Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP), and designed to run on cell phones, mainstream personal digital assistants, and other small mobile devices. The toolkit includes the emulation environments, performance optimization and tuning features, documentation, and examples that developers need to bring efficient and successful wireless applications to market quickly.

The Sun Java Wireless Toolkit can be used as a standalone development environment or with an IDE, such as the NetBeansâ„¢ Mobility Pack. IDE vendors will find that the Unified Emulator Interface simplifies the task of incorporating the Sun Java Wireless Toolkit into their own development environments.

The toolkit’s emulator complies fully with the relevant API technology compatibility kits, ensuring that all the APIs are present and will react consistently with compliant implementations. In standalone mode, users can set individual preferences, build applications, create Java Archive (JAR) and Java Application Descriptor (JAD) files, and more, using either the toolkit’s friendly KToolbar interface, or its command line. When integrated with an IDE, the toolkit’s utilities and preferences appear in the IDE’s menu selections, and also can be controlled from the IDE’s command-line interface. When used with an IDE, the toolkit supports source-level debugging.

The Sun Java Wireless Toolkit (formerly known as Java 2 Platform, Micro Edition (J2ME) Wireless Toolkit) is a state-of-the-art toolbox for developing wireless applications that are based on J2ME’s Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP), and designed to run on cell phones, mainstream personal digital assistants, and other small mobile devices. The toolkit includes the emulation environments, performance optimization and tuning features, documentation, and examples that developers need to bring efficient and successful wireless applications to market quickly

The J2ME Wireless Toolkit is a comprehensive set of tools for building MIDP applications. The toolkit can be used standalone, or incorporated into many popular integrated development environments (IDEs).

The Sun J2ME Wireless Toolkit supports the development of Java applications that run on devices such as cellular phones, two-way pagers, and palmtops.

The project was initiated by Sun Microsystems team in Sun Israel Development Center in the year 2000. The developers of the first version were Daniel Blaukopf, in charge of the internals and Amir Uval on the User Interface

Eclipse IDE

EclipseME is an Eclipse plugin to help develop J2ME MIDlets. EclipseME does the “grunt work” of connecting Wireless Toolkits to the Eclipse development environment, allowing you to focus on developing your application, rather than worrying about the special needs of J2ME development.

J2ME distributions consist of a JAR file containing the software, and a JAD file containing information for the J2ME container describing the contents of the source file.

EclipseME has a built-in JAD editor that handles the details of formatting the JAD file for you. Using the JAD editor, you can make all the required entries to allow your MIDlet to be properly supported. The information that makes up the JAD file is spread across several tabs, along the bottom of the editor window, for convenience.

Eclipse is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle.

Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written primarily in Java and can be used to develop applications in Java and, by means of the various plug-ins, in other languages as well, including C, C++, COBOL, Python, Perl, PHP, and others. The IDE is often called Eclipse ADT for Ada, Eclipse CDT for C, Eclipse JDT for Java and Eclipse PDT for PHP.

The initial codebase originated from VisualAge.[1] In its default form it is meant for Java developers, consisting of the Java Development Tools (JDT). Users can extend its capabilities by installing plug-ins written for the Eclipse software framework, such as development toolkits for other programming languages, and can write and contribute their own plug-in modules.

Released under the terms of the Eclipse Public License, Eclipse is free and open source software.

ProGuard version 4.4 is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes. It optimizes bytecode and removes unused instructions. It renames the remaining classes, fields, and methods using short meaningless names. Finally, it preverifies the processed code for Java 6 or for Java Micro Edition.

Some uses of ProGuard are:

• Creating more compact code, for smaller code archives, faster transfer across networks, faster loading, and smaller memory footprints.
• Making programs and libraries harder to reverse-engineer.
• Listing dead code, so it can be removed from the source code.
• Retargeting and preverifying existing class files for Java 6, to take full advantage of Java 6’s faster class loading.

ProGuard’s main advantage compared to other Java obfuscators is probably its compact template-based configuration. A few intuitive command line options or a simple configuration file are usually sufficient. For instance, the following configuration option preserves all applets in a jar:

keep public class * extends java.applet.Applet

The user manual explains all available options and shows more examples of this powerful configuration style.

ProGuard is fast. It only takes seconds to process programs and libraries of several megabytes. The results section presents actual figures for a number of applications.

ProGuard is a command-line tool with an optional graphical user interface. It also comes with plugins for Ant and for the JME Wireless Toolkit

EclipseME is a plugin to the open-source Eclipse IDE that supports Java ME development. EclipseME does the “grunt work” of connecting Wireless Toolkits to the Eclipse development environment, allowing you to focus on developing your application, rather than worrying about the special needs of Java ME development.

For instructions on downloading, installing and configuring EclipseME and other tools needed for developing Java ME applications (MIDlets) for S60, and for writing your first MIDlet, see Getting started with Java ME and the articles it links to, Installing Java ME development tools for S60 and Creating your first MIDlet using EclipseME.

The EclipseME plugin has the following features:

• Multiple wireless toolkit support
• Wireless toolkit preferences
• Platform component and definition support
• Create new J2ME Midlet Suite Project
• Create new MIDlet
• Java Application Descriptor (JAD) editor
• Automatic incremental preverification
• Eclipse launch support for Emulator
• MIDlet debugging support
• JAR and obfuscated JAR packaging
• Over the air deployment testing server
• Export Antenna build files
• Automatic MIDlet signing

EclipseME is now part of the Eclipse project under a new name: Mobile Tools for Java (MTJ). MTJ is included in the Eclipse Pulsar package. For istructions about creating your first MIDlet using this environment, see Developing MIDlets using Pulsar and Eclipse.

Retrieved from “http://wiki.forum.nokia.com/index.php/EclipseME”

Device Discovery

This section provides an overview of the device discovery capabilities of Java APIs for Bluetooth meal ordering system. An application may obtain a list of devices using either startInquiry() (nonblocking) or retrieveDevices() (blocking). startInquiry() requires the application to specify a listener; this listener is notified when new devices are found from a real inquiry. If an application does not wish to wait for an inquiry to begin, the API provides the retrieveDevices() method that returns the list of devices that were already found via a previous inquiry or devices that are classified as pre-known. Pre-known devices are those devices that are defined in the Bluetooth Control Center as devices the local device frequently contacts. This method does not perform an inquiry, but provides a quick way to get a list of devices that may be in the area. Once a device is discovered, a service search is usually initiated.

Device Discovery Classes

This section provides a brief overview of the classes that are used in device discovery. The specification of the classes and methods are found in Appendix 1-example of device discovery source code for Bluetooth meal ordering system

Interface javax.bluetooth.DiscoveryListener

This interface allows an application to specify an event listener that will respond to inquiry-related events. This interface is also used for service searching. The method deviceDiscovered() is called each time a device is found during an inquiry. When the inquiry is completed or canceled, the inquiryCompleted() method will be called. This method receives as an argument the INQUIRY_COMPLETED, INQUIRY_ERROR or INQUIRY_TERMINATED constant to differentiate between completed, error and cancelled inquiries.

Class javax.bluetooth.DiscoveryAgent

This class provides methods for service and device discovery. For device discovery, this class provides the startInquiry () method to place the local device in inquiry mode and the retrieveDevices()method to return information about devices that were found via previous inquiries performed by the local device. It also provides a way to cancel an inquiry via the cancelInquiry() method.

Service Discovery

This section describes the client API used to discover services that are available on a service discovery server. Class DiscoveryAgent provides the methods to search for services on a Bluetooth server device and to initiate device and service discovery transactions. This API does not support searching for services on the local device.

Service Discovery Classes

The following sections provide a brief overview of the classes involved in service discovery. The specification of the classes and methods are found in Appendix 1.

Class javax.bluetooth.UUID

The class UUID encapsulates unsigned integers that are 16 bits, 32 bits or 128 bits long. The class is used to represent a universally unique identifier used widely as the value for a service attribute. Only service attributes represented by UUIDs are searchable in Bluetooth SDP. The Bluetooth specification defines a few “short” (16-bit or 32-bit) UUIDs and describes how a 16-bit or 32-bit UUID is converted to a 128-bit UUID. This promotion is required for matching; normally only 128-bit UUIDs are compared.

Class javax.bluetooth.DataElement

This class contains the various data types that a Bluetooth service attribute value can take on. Valid service attribute data types have been stated below. The class also presents an interface to construct and retrieve the value of a service attribute.

• signed and unsigned integers that are one, two, four, eight or sixteen bytes long,
• String,
• Boolean,
• UUID, and
• Sequences of any one of these scalar types.

Interface javax.bluetooth.ServiceRecord

This interface defines the Bluetooth Service Record, which contains attribute ID, value pairs. A Bluetooth attribute ID is a 16-bit unsigned integer and an attribute value is a DataElement. In addition to providing the remote Bluetooth server device from which a ServiceRecord was obtained, this interface has a method populateRecord() to retrieve desired service attributes.

Class javax.bluetooth.DiscoveryAgent

The class DiscoveryAgent provides methods for service and device discovery. It supports service discovery in non-blocking mode and provides a way to cancel a service search transaction in progress.

Interface javax.bluetooth.DiscoveryListener

This interface allows an application to specify an event listener that responds to device and service discovery events. The method servicesDiscovered() is called whenever services are discovered When a service search transaction is completed or canceled, the serviceSearchCompleted() method is called.

Program Design

The “nerve centre” of the program is the aptly-named BTVoter class. The functions of the class include:

• Initializing the application upon starting – when the program starts, various methods and variables must be initialized – the RMS system must be properly opened and assigned to the right classes, the GUI components defined, etc. As such, most of these happen in the BTVoter class, specifically in the startApp() method.
• Acts as the commandListener class- since it will be too confusing and cumbersome to create a separate commandListener object, the BTVoter class implements it and thus saves me a lot of planning headaches. Because of this, any Command objects can be “hooked up” with an event listener simply by using the setCommandListener(this) method. All interactions in the program are handled by the commandListener() method in BTVoter.
• Program clean-up and garbage collection – although Java handles all garbage collection automatically (in contrast with older programming languages such as C++, which necessitates the usage of delete), nevertheless some things need to be handled manually. For instance, the RMS must be closed in order to ensure that no data corruption happens; although it is very rare, nevertheless it has been observed in program emulation. Similarly, program a thread (required when using the Bluetooth connection) needs to be terminated once it has served its purpose, and this is done in the main (BTVoter) class.

The handling of all registered voters is outlined in the Voters class, while the Issue class handles the creation of voting question and tallies up the results. The Issue class can be divided into roughly two halves; the Question (which is a String object) and the Result, consisting of three elements – choiceQty (integer), options (String array) and votes (integer array).

The Question variable is straightforward – it stores the question that is posed to the voters, and that’s the extent of its interaction. The choiceQty defines the number of options that a particular issue may have; the reason that this variable exists is because when data is going to be read, either from the RMS or via the Bluetooth network, the “raw” data is read in byte format, and as such the system have no way in knowing how many options and votes will there be.

A Java programmer might ask, “why not use Serializable?” Unfortunately, that class was not supported in J2ME, and neither does String.split(). As such, the cumbersome methods are needed to deal with the inherent constraints set by RMS.

In order to simplify the appearance of the code, the Voter and Issue object are “hidden” by an abstraction class known as the RecordInterface class. This class handles all the drudgery of opening and closing records, retrieving the current number of records, et cetera.

In addition, each of the Voter and Issue classes has its own Object-to-Byte converter (for writing the object into the RMS) and a Byte-to-Object constructor (for the reverse process).

CHAPTER 4: IMPLEMENTATIONS

Simulation

Hardware

Testing on the mobile phone was done on a few different kinds model such as Nokia, Sony Ericsson, and Motorola. As the start step, the JAR file of BTVoter program need to be uploaded to the mobile phones and the JAR file was installed to the specific folder selected by the user. All over the testing, it was found that some of the phones not well-matched to the program, thus the program installation can considered as unsuccessful. This kind of difficulty is normally caused by the build-in version of Mobile Information Device Profile (MIDP) of the mobile phones. From an implementation viewpoint, a profile is just a collection of Java APIs and class libraries residing on top of a configuration and providing domain-specific capabilities for devices.

Generally the latest manufacture of mobile phones was pre-build with the latest version of MIDP which is version 2.0. MIDP2.0 is used because it supports more than just HTTP – particularly, serial port communication (RFCOMM); also, for the future planned upgrade of BTVoter, MIDP2.0 has built-in support for security and cryptographic features such as public key infrastructure (PKI) and encryption. During the testing procedure, it was found that Nokia models with the Symbian S60 operating system are not compatible with the program. On the other hand, most of the Nokia models with Symbian S40 operating system can run the program with some minor problem. In other cases, most of Sony Ericsson mobile phones can run the application but critical requirement is still the latest version of MIDP build-in the mobiles phones respectively.

Certain devices are incompatible with BTVoter, despite it being developed in Java. We theorized that those devices’ OS have not yet been updated and capable of running MIDP 2.0; in these cases, hopefully the problem can be rectified with a soft/firmware update. This kind of complexity can considered as one of the limitation of BTVoter program.

CHAPTER 6: DISCUSSION AND FINDINGS

Multithreading

When listening for Bluetooth connection, a J2ME process is liable to getting deadlocked. Therefore, all but the oldest J2ME textbooks highly recommend that the object running the connection be multithreaded.

Multithreading refers to the ability to split a processing thread so that multiple instructions can be processed in parallel. Experimentation with the early versions of BTVoter have confirmed that single-threaded J2ME program does and will crash as soon as the Bluetooth connection component is turned on; as such, both components of the program (the Server and Client) are implements the Runnable class, and separate threads are created whenever a Bluetooth connection is switched on. At the end of program execution, the separate threads are destroyed via the join() method.

Graphics

The usage of graphics in this program is kept to the very minimum. The reasons are twofold – first, to reduce any processing and space requirements imposed on the mobile device. Since the usage of this program will most likely be used with the voting official at hand to aid the users if they have any trouble, I do not think that the extra burden imposed on the mobile device by integrating a lot of graphics will be worth it.

Secondly, since there are a lot of varieties of mobile device specifications (such as differing screen sizes, etc.), any graphic that looks fine on one mobile device might be distorted on another. As such, we think that it’s best if we keep graphics out entirely to preserve compatibility.

Compatibility Issues

The program BTVoter is designed to meet the specifications outlined in the Design Details section because it is meant to be able to be used in as many varieties of mobile phones as possible, it is written using J2ME (Java 2 Mobile Edition), thus in theory allowing it to be compatible with any Java-capable mobile phones. However, due to hardware quirks and various bugs (some of which can be fixed with a firmware update), not all phones’ operating system is compatible with BTVoter, although I am glad to say that a majority does in some fashion.

In order to further reduce any problems of incompatibility, the program also utilizes high-level APIs such as Form and StringItem instead of the more customizable (but also less widely-compatible) classes such as Canvas. In addition, absolutely no manufacturer-specific code is inserted within the program – it is my aim to make BTVoter capable of being used in as many mobile devices as possible, its brand notwithstanding.

Finally, due to the wide varieties of methods of storing data across different makes of devices, the Record Management System (RMS) is used; although admittedly it is extremely cumbersome and unwieldy, nevertheless it has the advantage of being the most compatible method of non-volatile IO storage.

CHAPTER 7: CONCLUSION AND RECOMMENDATIONS

REFERENCES

• J2ME Development using Eclipse. [No date]. Home page. Eclipse.org. [Online] http://eclipseme.org/ 24th March 2010
• http://en.wikipedia.org/wiki/Eclipse_(software) 24th March 2010
• http://proguard.sourceforge.net/ Main page 24th March 2010
• http://java.sun.com/products/sjwtoolkit/ Home page 24th March 2010
• http://www.bluetomorrow.com/about-bluetooth-technology/general-bluetooth-information/bluetooth-advantages.html 30th March 2010
• http://www.cs.huji.ac.il/~ssd/J2ME/J2ME.htm 31st March 2010
• What’s J2ME? by Daniel A. Tauber 03/08/2001 http://onjava.com/pub/a/onjava/2001/03/08/J2ME.html
• http://books.google.com.my/books?id=O9_xowxLNbQC&pg=PA172&lpg=PA172&dq=relation+between+cdc+and+cldc&source=bl&ots=WZCcrAdq4k&sig=AwPdmq3u9tx4pyP534VzfZ2Bl9Y&hl=en&ei=HjizS_TKG5OzrAfm-aH6Aw&sa=X&oi=book_result&ct=result&resnum=6&ved=0CCEQ6AEwBQ#v=onepage&q=relation%20between%20cdc%20and%20cldc&f=false
• Bluetooth Technology and Its Applications with JAVA and J2ME
• By C.S.R. Prabhu, A. Prathap Reddi, Prathap A. Reddi
• http://www.developer.com/ws/article.php/10927_1475521_3/article.htm
• http://www.cs.huji.ac.il/~ssd/J2ME/J2ME.htm
• http://www.webdotdev.com/nvd/content/view/1042/204/
• http://www.theallineed.com/webmasters/07072580.htm
• http://software.ivertech.com/_ivertechArticle4404_MostsignificantadvantagesofJavaLanguage.htm
• http://java.sun.com/docs/overviews/java/java-overview-1.html
• http://docs.google.com/viewer?a=v&q=cache:c0cU23TGao0J:www.cs.ru.ac.za/research/g04k1804/stuff/literature_review.pdf+literature+review+on+java&hl=en&gl=my&pid=bl&srcid=ADGEESjxrOt-wuQ27Uc8K6A9wEM3iTt6p2NrFRXqdT0Ax-yLlf2JWbzrAphSbcXUmHmRWH87yrsvKsfvI57sx71nueuOFQiese0PLFxibt_doMatlf88RYzzXGqnWhmLzvgnDmmSv4Gh&sig=AHIEtbQLSf4wVTHD6UvYcksRKwUIrutZiw
• http://www.javacoffeebreak.com/articles/inside_java/insidejava-nov99.html
• Bluetooth Application Programming with the Java APIs Essentials Edition, By Timothy J. Thompson, C Bala Kumar and Paul Kline, 304 pages, http://www.elsevierdirect.com/product.jsp?isbn=9780123743428
• Bluetooth Application Programming with the Java APIs, By C Bala Kumar, Paul Kline and Tim Thompson, 498 pages, http://www.elsevierdirect.com/product.jsp?isbn=9781558609341