You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@debrunners.com> on 2004/09/30 17:04:50 UTC
JSR169 support
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
I'll first try and come up a complete list of classes and methods that
Derby depends on that are not in each environment. Removing the
dependency on each should be fairly independent tasks, so others could
get involved.
Another issue is that I haven't been able to find a JSR169 api library
(jar file) to download. Downloading this would be required to build
Derby once these changes were made. Obviously any dependency on JSR169
jar file would not be committed until that jar file could be downloaded.
And if anyone has any concerns with Derby supporting JSR169, please
speak up.
Reference links
JDBC Optional Package for CDC/Foundation Profile (JSR169)
http://java.sun.com/products/jdbc/download.html#cdcfp
J2ME/CDC/Foundation
http://java.sun.com/products/cdc/index.jsp
http://java.sun.com/products/foundation/index.jsp
OSGi ee.minimum
www.osgi.org
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBXCCSIv0S4qsbfuQRApaoAKDgmppHPhZEnsYjGgadG5EcPeBktgCguTty
1/NcrXeHzxypieikkPifW6A=
=RanZ
-----END PGP SIGNATURE-----
Re: JSR169 support
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Sep 30, 2004, at 8:04 AM, Daniel John Debrunner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> 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
>
> I'll first try and come up a complete list of classes and methods that
> Derby depends on that are not in each environment. Removing the
> dependency on each should be fairly independent tasks, so others could
> get involved.
>
> Another issue is that I haven't been able to find a JSR169 api library
> (jar file) to download. Downloading this would be required to build
> Derby once these changes were made. Obviously any dependency on JSR169
> jar file would not be committed until that jar file could be
> downloaded.
>
> And if anyone has any concerns with Derby supporting JSR169, please
> speak up.
We'll need to get the TCK for 169 and certify, as that is what I'm
guessing the obligation of the spec license is.
I'll be happy to get started with that.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: JSR169 support
Posted by Jeremy Boynes <jb...@gluecode.com>.
Daniel John Debrunner wrote:
>
> Java functions and procedures that use SQL through server side JDBC
> Can not support, the standard mechanism to get the JDBC connection in
> a procedure or function, uses the
> DriverManager.getConnection("jdbc:default:connection"). JSR 169 does not
> support the DriverManager class. Note that this standard default
> connection URL is specified by the SQL standard Part 13 and not by JDBC.
>
> Derby system procedures that use server side SQL
> Probably need to support, since they are internal they could use a
> private, non-standard mechanism to get the server side JDBC connection.
>
How about a server-side DataSource? as in
ServerDataSource ds = new ServerDataSource();
Connection c = ds.getConnection();
which is no more proprietary than anything else that constructs a
DataSource.
As an aside (and probably not SQL/JRT compliant) a potentially neat
feature would be to support a singleton multi-threaded class rather than
using static methods for prodecures. Then, when the instance is created,
a DataSource could be injected by the DB; this would allow any class
implemented this way to be independent of the actual database as all
they would see is an instance of the DataSource interface.
--
Jeremy
Re: JSR169 support
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Hlavaty wrote:
> Daniel John Debrunner wrote:
>
>>Daniel John Debrunner wrote:
>>Classes missing causing compile errors
>>
>>java.math.BigDecimal
>
>
>>DECIMAL datatype
>> I think this datatype needs to be supported under JSR169 though how,
>>is less clear.
>
>
> We could pack standalone version of BigDecimal, like this:
>
>
http://oss.software.ibm.com/cvs/icu4j/icu4j/src/com/ibm/icu/math/?only_with_tag=HEAD
I think that's the general approach but we need to go further. That
class depends on java.math.BigInteger which is in CDC/Foundation but is
not in OSGi ee.minimum. I think we can take advantage of the fact that
Derby limits DECIMAL to 31 precision to implement a simpler
"BigDecimal". The real BigDecimal has to handle precision up to max int.
Also Derby does not need to support all the methods of BigDecimal.
It may turn out that a specialized implementation would be faster than
Derby's current use of BigDecimal, since BigDecimal is immutable and
each BigDecial requires three object creations. E.g. for a query like
select price * tax from items where ...
there will be a lot of object creation in the current Derby implementation.
I've been messing with some initial ideas on using long primitive to
perform the operations, that just handles up to around DECIMAL(20),
while still storing in the format defined by BigDecimal/BigInteger. If I
can hack it into Derby I might try to run some performance tests. Any
initial hack I'm doing might ignore tricky issues like over/under flow
and division. I just want to get an idea to see if the performance
benefit is worth it for J2SE. Or maybe there is other code out there
that performs fixed point arithmetic using one or two longs internally.
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBZs2KIv0S4qsbfuQRAskJAKCCIn4HaL5hHrdQ9K9MjqTkgb+/8ACgq2G9
3eXRvCyZR4zW+kbVtNKsFwM=
=Md06
-----END PGP SIGNATURE-----
Re: JSR169 support
Posted by Jan Hlavaty <hl...@code.cz>.
Daniel John Debrunner wrote:
> Daniel John Debrunner wrote:
> Classes missing causing compile errors
>
> java.math.BigDecimal
> DECIMAL datatype
> I think this datatype needs to be supported under JSR169 though how,
> is less clear.
We could pack standalone version of BigDecimal, like this:
http://oss.software.ibm.com/cvs/icu4j/icu4j/src/com/ibm/icu/math/?only_with_tag=HEAD
Jan
Re: JSR169 support
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've attached a functional spec and my design notes for JSR169 support
to Derby-97.
http://nagoya.apache.org/jira/browse/DERBY-97
I'd appreciate comments, please send reply to this thread on derby-dev.
I'll summarise any comments in Jira comments and/or by updating those
documents.
Thanks,
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBwHy+Iv0S4qsbfuQRArBUAJ9RMibxATzwp7Y2m1ZT1O/grZTLSwCg0U6H
z9q8EMtJQpXmyN30hne8rgA=
=2EyB
-----END PGP SIGNATURE-----
Re: JSR169 support
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel John Debrunner wrote:
>
> I'm going to look into completing JSR169 support for Derby.
At this time I'm just looking at getting the embedded engine running on
CDC/Foundation 1.0 & JSR 169. More investigation is needed to make the
network server, ij and dblook run in that configuration. Support for
OSGi ee.minimum is additional work on top of this.
Setting compile.classpath to use CDC/Foundation 1.0 & JSR 169.
[ Any ant build.xml files that use compile.classpath for the engine are
code areas that need to compile & run under JSR169. Classes that only
need to run in JDBC 2.0 or JDBC 3.0 use java13compile.classpath or
java14compile.classpath. ]
Classes missing causing compile errors
java.math.BigDecimal
java.sql.DriverManager
java.sql.DriverPropertyInfo
java.sql.Array
java.sql.Ref
Methods missing causing compile errors
java.sql.ResultSet.getUnicodeStream
These missing classes have an impact of supported SQL functionality when
running under JSR169.
DECIMAL datatype
I think this datatype needs to be supported under JSR169 though how,
is less clear.
Java functions and procedures that use SQL through server side JDBC
Can not support, the standard mechanism to get the JDBC connection in
a procedure or function, uses the
DriverManager.getConnection("jdbc:default:connection"). JSR 169 does not
support the DriverManager class. Note that this standard default
connection URL is specified by the SQL standard Part 13 and not by JDBC.
Derby system procedures that use server side SQL
Probably need to support, since they are internal they could use a
private, non-standard mechanism to get the server side JDBC connection.
Diagnostic virtual tables (lock table etc.)
Probably need to support, probably can just compile them against
JSR169 libraries.
- ---------
My first steps are going to be reducing the number of compile errors I
see when compiling in this environment by removing unused imports of the
missing classes and moving code from the Embed* JDBC classes to the
Embed*20 classes, when that code is in JDBC 2 but not JSR169. Then the
Embed* will be the base and JSR169 classes, Embed*20 are JDBC 2 specific
and Embed*30 JDBC 3 specific. These specific changes will not require
downloads of J2ME or JSR169 jars. I'll also try and set it up so that
the build uses jsr169 ibraries if they are available (by setting ant
properties), so others can see the issues.
Further progress probably requires easy downloads of the
CDC/Foundation1.0 and JSR169 jars for everyone. Thanks for Geir for
looking into that.
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBYa7AIv0S4qsbfuQRAk7HAJ9PA1j9W7C0D+icKa68i7IgrnGACACdHEq9
6G6cp2oseWg7rwu592zOQk4=
=xygc
-----END PGP SIGNATURE-----
Re: JSR169 support
Posted by Patrick Mueller <pm...@yahoo.com>.
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
broken.
--
Patrick Mueller
pmuellr@yahoo.com