db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: More. Trouble with JVMInfo
Date Mon, 26 Sep 2011 21:22:26 GMT
On 9/26/2011 11:13 AM, Rick Hillegas wrote:
> Can you refresh my memory: why is sysinfo included in all of our jars? 
> Why can't we ask people to wire in the tools jar if they want to run 
> sysinfo?  I think sysinfo was thought to be stable but because it uses 
> classes like JVMInfo that are used for other things, it is not.   How 
> would this plan work in relation to the single sysinfo invocation?
This practice predates me, but I am pretty sure it is because sysinfo 
is/was  the primary tool for verifying proper classpath settings  and 
collecting information for support regarding what jars and versions are 
being used and for what versions, jvm, os  information, etc.  Many 
(most?) applications do not deploy derbytools.jar, so it doesn't make 
sense to require that jar be installed or the classpath you are trying 
to diagnose be changed to include it in a support situation.

I reopened DERBY-1046 to remove the JVMInfo duplication which I think 
was closed accidentally.  I think this class changes too frequently to 
be expected to be stable and part of sysinfo.  If a bit of code needs 
duplication in sysinfo, then that seems the way to go.  
ProductVersionHolder might need something more elaborate.








Mime
View raw message