Andrew McIntyre wrote: > On 8/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > >> >> That is actually engine code, so should not be used by the tools (or the >> tests) > > > Yet there are references to JVMInfo in both ij and sysinfo. Should > these be removed, then?
Or the code moved into the common area (and bring up that whole can of worms :-) > >> it would work for some cases (assuming the code was moved), but >> it doesn't handle J2ME/CDC/Foundation or J2ME/CLDC or Java Card. > > > Currently the code in JVMInfo assumes that a J2ME VM is 1.3 level, so > the code above would currently print an error and exit on those > platforms, would it not? No idea, might get a class not found error in starting up. As you say "assumes" is the key point, it assumes it's running in J2SE (or J2ME/CDC/Foundation). It doesn't cater to the fact it might be running in a less enabled environment so it may or may not handle that case. For example, if Derby ran against OSGi ee.minimum I'm pretty sure it wouldn't work and it wouldn't get a nice error message, since our error message handling relies on classes not in OSGi ee.minimum. Should someone fix that so that Derby produces a nice error message in OSGi ee.minimum (or CLDC or JavaCard etc.) ? I don't see it as a requirement. If someone submitted a patch that made it produce a nice error message in OSGi ee.minimum then maybe it would be committed, depends on how much cruft code would be needed to add very little value. In addition, the JDK_ID level produced by JVMInfo class is just designed for J2SE and it's Derby's interpretation, not any standard Java concept. Thus with: JVMInfo.JDK_ID < JVMInfo.J2SE_15 who knows what JVMInfo.JDK_ID would end up being on J2ME/CLDC or JavaCard, may end up being a value greater than JVMInfo.J2SE_15. Dan.
