[
https://issues.apache.org/jira/browse/DERBY-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540840
]
djd edited comment on DERBY-3176 at 11/7/07 10:57 AM:
------------------------------------------------------------------------
Well the main reason is that is how the code is intended to work :-) I was
mistaken in my earlier comment, the id indicates the base JDK level and the
boolean indicates its the J2ME subset. Just adding a new id without modifying
the rest of the code to handle this new type of id will not work.
There are modules that will work in J2ME CDC/Foundation 1.1 and J2SE 1.4, they
indicate this by specifying their jdk level as 4 in modules.properties. Any
module that requires classes that are in J2SE 1.4 and not in the J2ME subset
indicate this by explicitly stating they need that class: E.g.
derby.module.jdbcJ4=org.apache.derby.jdbc.Driver30
derby.env.jdk.jdbcJ4=4
derby.env.classes.jdbcJ4=java.sql.Driver
The order of the id (jdk levels) is also significant, for any two modules that
can run in a given environment, the one with the highest jdk id will be
selected and currently the code works in that they are the base jdk levels.
Inserting values in the middle for J2ME I think has the potential to lead to
confusion, especially when migrating changes across branches. E.g. for the J2ME
based upon Java 5, what would a new id be, since there is no gap between
J2SE_142 and J2SE_15.
Feel free to implement a different scheme, but it will require more than just
adding an id in JVMInfo.
was (Author: djd):
Well the main reason is that is how the code is intended to work :-) I was
mistaken in my earlier comment, the id indicates the base JDK level and the
boolean indicates its the J2ME subset. Just adding a new id without modifying
the rest of the code to handle this new type of id will not work.
There are modules that will work in J2ME CDC/Foundation 1.1 and J2SE 1.4, they
indicate this by specifying their id as 4 in modules.properties. Any module
that requires classes that are in J2SE 1.4 and not in the J2ME subset indicate
this by explicitly stating they need that class: E.g.
> J2ME support for phoneME platform disabled in 10.3
> --------------------------------------------------
>
> Key: DERBY-3176
> URL: https://issues.apache.org/jira/browse/DERBY-3176
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.1.4
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-3176-01-phoneME-aa.diff,
> derby-3176-01-phoneME-ab.diff, derby-3176-01-phoneME-ac.diff
>
>
> Derby 10.2 runs on the phoneME small device platform. However, on that
> platform Derby 10.3 fails to boot databases, complaining that Derby cannot
> find an appropriate implementation of DataValueFactory.
> For details on how to install and run the phoneME platform, please see
> http://blogs.sun.com/wittyman/entry/javadb_on_sun_javame_cdc These are great
> instructions but I needed to adjust them as follows:
> 1) I had to use 10.2 because 10.3 and the development mainline would not run
> on this platform
> 2) I needed to to set LD_LIBRARY_PATH so that the vm could find the necessary
> shared libraries.
> Here is the phoneME startup script which worked for me:
> #! /bin/bash
> #
> # Run an ij script in the phoneME vm
> #
> # $1 is the script to run
> export LD_LIBRARY_PATH=$CDC_HOME/lib
> cd ~/demo/tearoffToPhone/data
> $CDC_HOME/bin/cvm -Xbootclasspath/a:$JSR169_HOME/lib/jsr169.jar \
> -cp $DERBYJARS/derby.jar:$DERBYJARS/derbytools.jar \
> -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource \
> -Dij.dataSource.databaseName=sample \
> -Dij.dataSource.createDatabase=create \
> org.apache.derby.tools.ij $1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
