A Look Inside JSR 360 - CLDC 8
- by Roger Brinkley
If you didn't notice during JavaOne the Java Micro Edition took a major step forward in its consolidation with Java Standard Edition when JSR 360 was proposed to the JCP community. Over the last couple of years there has been a focus to move Java ME back in line with it's big brother Java SE. We see evidence of this in JCP itself which just recently merged the ME and SE/EE Executive Committees into a single Java Executive Committee. But just before that occurred JSR 360 was proposed and approved for development on October 29. So let's take a look at what changes are now being proposed.
In a way JSR 360 is returning back to the original roots of Java ME when it was first introduced. It was indeed a subset of the JDK 4 language, but as Java progressed many of the language changes were not implemented in the Java ME. Back then the tradeoff was still a functionality, footprint trade off but the major market was feature phones. Today the market has changed and CLDC, while it will still target feature phones, will have it primary emphasis on embedded devices like wireless modules, smart meters, health care monitoring and other M2M devices. The major changes will come in three areas: language feature changes, library changes, and consolidating the Generic Connection Framework.
There have been three Java SE versions that have been implemented since JavaME was first developed so the language feature changes can be divided into changes that came in JDK 5 and those in JDK 7, which mostly consist of the project Coin changes. There were no language changes in JDK 6 but the changes from JDK 5 are:
Assertions - Assertions enable you to test
your assumptions about your program. For example, if you write a method that
calculates the speed of a particle, you might assert that the calculated speed
is less than the speed of light. In the example code below if the interval isn't between 0 and and 1,00 the an error of "Invalid value?" would be thrown.
private void setInterval(int interval) {
assert interval > 0 && interval <= 1000 : "Invalid value?"
}
Generics - Generics add stability to your code by making more of your bugs detectable at compile time. Code that uses generics has many benefits over non-generic code with:
Stronger type checks at compile time.
Elimination of casts.
Enabling programming to implement generic algorithms.
Enhanced for Loop - the enhanced for loop allows you to iterate through a collection without
having to create an Iterator or without having to calculate beginning
and end conditions for a counter variable. The enhanced for loop is the
easiest of the new features to immediately incorporate in your code. In
this tip you will see how the enhanced for loop replaces more
traditional ways of sequentially accessing elements in a collection.
void processList(Vector<string> list) {
for (String item : list) {
...
Autoboxing/Unboxing - This facility eliminates the drudgery of manual
conversion between primitive types, such as int and wrapper types, such
as Integer.
Hashtable<Integer, string=""> data = new Hashtable<>();
void add(int id, String value) {
data.put(id, value);
}
Enumeration - Prior to JDK 5 enumerations were not typesafe, had no namespace, were brittle because they were compile time constants, and provided no informative print values.
JDK 5 added support for
enumerated types as a
full-fledged class (dubbed an enum type). In addition to solving all
the problems mentioned above, it allows you to add arbitrary methods and
fields to an enum type, to implement arbitrary interfaces, and more. Enum
types provide high-quality implementations of all the Object methods.
They are Comparable and Serializable, and the serial form is
designed to withstand arbitrary changes in the enum type.
enum Season {WINTER, SPRING, SUMMER, FALL}; }
private Season season;
void setSeason(Season newSeason) {
season = newSeason;
}
Varargs - Varargs eliminates the need for manually boxing up
argument lists into an array when invoking methods that accept
variable-length argument lists. The three periods after the final parameter's type indicate that the final argument may be passed as an array or as a sequence of arguments. Varargs can be used only in the final argument position.
void warning(String format, String... parameters) {
..
for(String p : parameters) { ...process(p);... }
...
}
Static Imports -The static import construct allows unqualified access to static members
without inheriting from the type containing the static members. Instead, the program imports the members either individually or en masse. Once the static members have been imported, they may be used without
qualification. The static import declaration is analogous to the normal import declaration.
Where the normal import declaration imports classes from packages, allowing
them to be used without package qualification, the static import declaration
imports static members from classes, allowing them to be used without class
qualification.
import static data.Constants.RATIO;
...
double r = Math.cos(RATIO * theta);
Annotations - Annotations provide data about a program that is not part of
the program itself. They have no direct effect on the operation of the
code they annotate. There are a number of uses for annotations including information for the compiler, compiler-time and deployment-time processing, and run-time processing. They can be applied to a program's declarations of classes, fields, methods, and other program elements.
@Deprecated
public void clear();
The language changes from JDK 7 are little more familiar as they are mostly the changes from Project Coin:
String in switch - Hey it only took us 18 years but the String class can be used in the expression of a switch statement. Fortunately for us it won't take that long for JavaME to adopt it.
switch (arg) {
case "-data": ...
case "-out": ...
Binary integral literals and underscores in numeric literals - Largely for readability, the integral types (byte, short, int, and long) can also be expressed using the binary number system. and any number of underscore characters (_) can appear anywhere
between digits in a numerical literal.
byte flags = 0b01001111;
long mask = 0xfff0_ff08_4fff_0fffl;
Multi-catch and more precise rethrow -
A single catch block can handle more than one type of
exception. In addition, the compiler performs more precise analysis of
rethrown exceptions than earlier releases of Java SE. This enables you
to specify more specific exception types in the throws clause of a method declaration.
catch (IOException | InterruptedException ex) {
logger.log(ex);
throw ex;
}
Type Inference for Generic Instance Creation - Otherwise known as the diamond operator, the type arguments required to invoke the constructor of a generic class can be replaced with an empty set of type parameters (<>) as long as the compiler can infer the type arguments from the context.
map = new Hashtable<>();
Try-with-resource statement - The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement.
try (DataInputStream is = new DataInputStream(...)) {
return is.readDouble();
}
Simplified varargs method invocation - The Java compiler generates a warning at the declaration site of a
varargs method or constructor with a non-reifiable varargs formal
parameter. Java SE 7 introduced a compiler option -Xlint:varargs and the annotations @SafeVarargs and @SuppressWarnings({"unchecked", "varargs"}) to supress these warnings.
On the library side there are new features that will be added to satisfy the language requirements above and some to improve the currently available set of APIs. The library changes include:
Collections update - New Collection, List, Set and Map, Iterable and Iteratator as well as implementations including Hashtable and Vector. Most of the work is too support generics
String - New StringBuilder and CharSequence as well as a Stirng formatter. The javac compiler now uses the the StringBuilder instead of String Buffer. Since StringBuilder is synchronized there is a performance increase which has necessitated the wahat String constructor works.
Comparable interface - The comparable interface works with Collections, making it easier to reuse.
Try with resources - Closeable and AutoCloseable
Annotations - While support for Annotations is provided it will only be a compile time support. SuppressWarnings, Deprecated, Override
NIO - There is a subset of NIO Buffer that have been in use on the of the graphics packages and needs to be pulled in and also support for NIO File IO subset.
Platform extensibility via Service Providers (ServiceLoader) - ServiceLoader interface dos late bindings of interface to existing implementations. It helpe to package an interface and behavior of the implementation at a later point in time.Provider classes must have a zero-argument constructor so that they can be instantiated during loading. They are located and instantiated on demand and are identified via a provider-configuration file in the METAINF/services resource directory. This is a mechansim from Java SE.
import com.XYZ.ServiceA;
ServiceLoader<ServiceA> sl1= new ServiceLoader(ServiceA.class);
Resources:
META-INF/services/com.XYZ.ServiceA:
ServiceAProvider1
ServiceAProvider2
ServiceAProvider3
META-INF/services/ServiceB:
ServiceBProvider1
ServiceBProvider2
From JSR - I would rather use this list I think
The Generic Connection Framework (GCF) was previously specified in a number of different JSRs including CLDC, MIDP, CDC 1.2, and JSR 197. JSR 360 represents a rare opportunity to consolidated and reintegrate parts that were duplicated in other specifications into a single specification, upgrade the APIs as well provide new functionality. The proposal is to specify a combined GCF specification that can be used with Java ME or Java SE and be backwards compatible with previous implementations.
Because of size limitations as well as the complexity of the some features like InvokeDynamic and Unicode 6 will not be included. Additionally, any language or library changes in JDK 8 will be not be included. On the upside, with all the changes being made, backwards compatibility will still be maintained.
JSR 360 is a major step forward for Java ME in terms of platform modernization, language alignment, and embedded support. If you're interested in following the progress of this JSR see the JSR's java.net project for details of the email lists, discussions groups.
