On Thu, 20 Nov 2003, Mark Taylor wrote:
> A couple of points:
>
> > In a static context
> > the only way you play the same game is by asking the local Thread for
> > its classloader.
> >
> > Class.forName("some.class", true,
> > Thread.currentThread().getContextClassLoader() );
>
>
> To save a bit of typing, do you know any reason you couldn't do it
> like this instead:
>
> class Utils {
> static void doStuff() {
> Class x = Utils.class.getClass( "some.class" );
> }
> }
Yes, that would be Utils.class.forName( "some.class" ) really, so this
would use the System class loader. "getClass" is only a method on Object
not Class.
> > JNIAST and JNIHDS. These now have jar files containing shareable
> > libraries for each architecture committed to CVS, rather than
> > following the usual method of being architecture specific and
> > performing a rebuild each time. There is a special "webstart_jars"
> > target in each for creating these jar files for the current
> > architecture (the idea being you'd then re-commit these to CVS).
> >
> > One possibility to tidy up this mess, and make it possible to do
> > architecture-free builds, is to stop JNIAST and JNIHDS from
> > re-building their JNI libraries by default and making the default
> > build action just use these pre-builts, which are updated from time
> > to time (when AST or HDS, or the C library changes require it).
>
> I don't understand why you've done this (I'm not saying it's a bad idea,
> I just don't know what is the webstart-specific reason why you have).
It's just that I wanted to have a single directory structure that worked
for all supported operating systems, rather than separate builds for
Linux, Solaris and Windows (following different links to these would look
quite odd, in a webstart sense). Some applications work without the
shareable libraries, so that would be another separate system...
Windows is special anyway since I build the dlls by hand, and I've wanted
to put these into JNIAST/JNIHDS for a while so that they are not hidden
away.
Join these two thoughts, throw all that repetition of builds that we seem
to have (a class file doesn't need to be recompiled just 'cos the
shareable library does) and voila (more French!) this system looked a
little better to me.
> Given those files are now there, it does seem a bit pointless to
> have the build generate the libraries at build time, at least on
> supported architectures. That step also makes the whole build process
> more fragile. Should I just fix the build files so the native builds
> are not part of the normal build or install targets?
That would be a logical step. Make the JNI build a special target.
> I haven't tested the webstart setup, but following a normal install
> the HDS package ant test target fails for me as follows:
>
> run-tests:
> [junit] Testsuite: uk.ac.starlink.hds.HDSNDArrayTest
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.118 sec
>
> [junit] Testcase: testBuilder took 0.104 sec
> [junit] Caused an ERROR
> [junit] class "uk.ac.starlink.hds.HDSException"'s signer information does not match signer information of other classes in the same package
> [junit] java.lang.SecurityException: class "uk.ac.starlink.hds.HDSException"'s signer information does not match signer information of other classes in the same package
> [junit] at java.lang.ClassLoader.checkCerts(ClassLoader.java:568)
> [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:496)
> [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
> [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
> [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
> [junit] at java.security.AccessController.doPrivileged(Native Method)
> [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
> [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
> [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
> [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> [junit] at uk.ac.starlink.hds.HDSNDArrayTest.testBuilder(HDSNDArrayTest.java:28)
> [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [junit] at java.lang.reflect.Method.invoke(Method.java:324)
> [junit] at junit.framework.TestCase.runTest(TestCase.java:166)
> [junit] at junit.framework.TestCase.runBare(TestCase.java:140)
> [junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
> [junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
> [junit] at junit.framework.TestResult.run(TestResult.java:109)
> [junit] at junit.framework.TestCase.run(TestCase.java:131)
> [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
> [junit] at junit.framework.TestSuite.run(TestSuite.java:168)
> [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
> [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536)
>
> [junit] Testcase: testBuilder
OK, I checked in some signed jar files, I've cleaned them so update your
CVS checkout and try again.
Cheers,
Peter.
|