db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Stroffek <Julius.Strof...@Sun.COM>
Subject Re: Testing implementation of private classes
Date Mon, 08 Jan 2007 12:16:04 GMT

I checked the release and all the .jar files in /lib directory 
are not sealed. Do we plan to seal the jars in the future? If so, I 
think that 'buildjars' target than could create the same jars twice - 
one set for testing purposes only which will have the same content 
except they will not be sealed.


Oystein Grovlen - Sun Norway wrote:
> Daniel John Debrunner wrote:
>> Julius Stroffek wrote:
>>> I have only two solutions to this:
>>> 1.) Change the visibility of required classes to public.
>>> 2.) Maintain the parallel package tree (suggested by Krisitian) with 
>>> implementation of tests of private classes. The tests will be in a 
>>> same package but different source directory. The build system will 
>>> manage to place the tests to derbyTesting.jar only. According the 
>>> docs, the class loader should choose the correct jar file to load a 
>>> class (if the jar sealing is turned off). I'll check this.
>>> Since changing the visibility of code is not desired I see the 
>>> option 2 as the preferred one. Are there any other possibilities? 
>>> What are your opinions?
>> Both solutions are affecting the visibility of code. Option 2) is 
>> removing the option of sealing *all* the classes in that package, 
>> thus defeating any package access protection.
>> If the testing really is just for a specific class, then it does not 
>> matter that the class is in one of the derby "product" jars. So a 
>> couple of variants of 2) are:
>>  - test only when running tests from the classpath
>>  - archive the class into another jar where it is not sealed and run 
>> the tests against with that jar in the classpath and none of the 
>> derby "product" jars.
> How about only sealing insane jars?  Then we could run such tests 
> against sane jars.

View raw message