i've been considering for a while whether the commons should ship a simpler but reasonably compatible version of JCL. over the years, we've recommended this so many times but have always left it to the actual user to go away and do the work themselves. i've come to the conclusion that it would be a good idea for this to be available as a separate component.
i think that there is an argument that we leave static binding until JCL2.0 but i would prefer a version to be available as a (limited) substitute for 1.1. this would be created by stripping out all the classloading magic required to support the java 1.2 hierarchical classloading model and would be java 1.1 compatible. most of the standard JCL configuration mechanisms would still be used but only the class classloader would be searched. the jar would be fully compatible with the JCL API but semantically (and possibly also binary) incompatible with the SPI. no exceptions would be thrown when discovery fails: a backup log implementation would be provided. the diagnostic log switch would allow limited debugging of configurations. this would be runtime only substitute: applications should still compile against the conventional JCL jar. use cases replacing (dynamic discovery) JCL: * for J2ME applications * for applets * for some client-side applications * for frameworks which do not want JCL dependencies (Torsten's requirements) * for those requiring maximum performance (at the expense of flexibility) opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
