db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <pmue...@yahoo.com>
Subject Re: JSR169 support
Date Fri, 01 Oct 2004 12:54:17 GMT
Daniel John Debrunner wrote:

> I'm going to look into completing JSR169 support for Derby.
> JSR169 support is a subset of JDBC 3.0 for J2ME/CDC/Foundation and OSGi
> ee.minimum platforms. J2ME/CDC/Foundation is the larger of the two main
> Java 2 Micro Edition environments. OSGi ee.minimum is a subset of
> J2ME/CDC/Foundation that does support the required classes for JSR169.
> The current code does have some of the initial work.
> The changes are basically to support additional JVM settings like the
> support for JDK 1.3 and JDK 1.4 and in those environments, remove
> dependency on J2SE classes or methods that do not exist.
> Some of the issues I know about are
>  - no java.math.BigDecimal - what to do about DECIMAL?
>  - no java.sql.DriverManager (only DataSource api supported in JSR169)
>  - no java.util.Observer & Observable
>  - no java.text.MessageFormat
>  - no java.util.Stack

You might be interested in taking a look at Eclipse SWT, as they  have 
similiar issues supporting J2SE and J2ME.  One of their tactics is to 
create a utility class which has two implementations, one for J2SE, one 
for J2ME.  The methods in the class are the ones which require different 
implementations across the base class libraries.  They actually build 
the jar with one of the two implementations.

I've done something similiar in the past, but made the decision at 
runtime instead of build time.  The J2ME profiles tend to require 
particular System properties being set which you can query.

If the Derby source is compilable within Eclipse (haven't tried so I 
don't know; it's a question of how the source is structured), and you 
can get your hands on a jar matching the J2ME profile you are trying to 
build against, it's fairly simple for Eclipse to tell you where you're 

Patrick Mueller

View raw message