[
https://issues.apache.org/jira/browse/DERBY-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613707#action_12613707
]
Kathey Marsden commented on DERBY-3618:
---------------------------------------
So it looks like you have stumbled upon an old and debated topic of shared
code. There was a long conversation about this a long time ago, but basically
there are some serious problems with sharing code between engine and client if
mixed jar versions are used, because you don't know what version will be used.
There may also be some issues with sealing violations with shared code that I
don't fully understand (see DERBY-1125)
I thought that the conclusion was that there would be a shared directory
created but that that code would actually only go into client until a real
shared code solution was found. Also it was determined that it was ok for
constants like Attribute.java and SQLState.java to go in because the constants
get compiled out.
Despite that, it looks like the SanityManager code made its way into the shared
directory and is actually shared between engine and client.
I am guessing it was decided that it was ok to share the SanityManager code
because it doesn't affect production (insane) builds, but that's just a guess.
Now for your changes, I don't think Monitor and all its dependencies should be
shared code and go into derbyclient.jar. I think the best solution would be to
build the trace info into the assertion message and eliminate use of Monitor in
the new code. It doesn't make sense when used in the context of client anyway.
As for JVMInfo I tend to think as well, that the cleanest thing is not to use
it. You can attempt a Class.forName() on a class only available in JDK 1.5 or
higher as a quick check of the vm level.
> Perform thread dump with ASSERTS with jdk 1.5 or higher
> -------------------------------------------------------
>
> Key: DERBY-3618
> URL: https://issues.apache.org/jira/browse/DERBY-3618
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.5.0.0
> Reporter: Kathey Marsden
> Assignee: Erlend Birkenes
> Priority: Minor
> Attachments: DERBY-3618_1.diff, DERBY-3618_2.diff, DERBY-3618_3.diff,
> DERBY-3618_4.diff
>
>
> It would be good to have a stack traces for all threads dump to the derby.log
> when an assertion occurs with JVM's that support it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
