--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 00:02 -0700, Brian Stansberry
> wrote:
> > Random thoughts....
> >
> > 1) Found a brief discussion on this list a month
> ago
> > that touched on issues with JDK detection:
> >
> >
>
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111049144008136&w=2
>
> Thanks for the link.
>
> >
> > 2) My experience is that the JVM will not try to
> load
> > a class until it is needed, so even though
> > AccessController and PrivilegedAction are
> imported,
> > LogFactory/LogFactoryImpl/SimpleLogcan be loaded.
> In
> > the test I ran the NoClassDefFoundError is thrown
> when
> > an attempt is made to use PrivilegedAction, not
> when
> > LogFactory is loaded. So, *potentially* the error
> can
> > be caught and handled or just avoided via JDK
> > detection.
>
> Yep, that's my understanding of the Sun JVM at
> least..
>
> >
> > The concern I have is that this "lazy loading" of
> > classes is not required in the spec (see
> >
>
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#22574
> > ). Some JVMs (e.g. the M$ JVM used in Win9x
> browsers)
> > *may* try to link all classes when LogFactory is
> > loaded, in which case JDK detection won't work
> unless
> > we use reflection for the AccessController stuff.
> > Reflection sounds pretty nasty. (Is it even
> possible
> > for anonymous inner classes? Don't know how it
> could
> > be.)
>
> Yep, I agree with this too. In particular, assuming
> that "lazy loading"
> is in effect might get hairy with GCJ. I think we
> would have to go with
> a reflection-based approach somehow.
>
> I don't think the anonymous-inner-class bit is a
> show-stopper; can't we
> just pull that out into a separate, ordinary, class?
>
Yes, of course (sound of palm slapping forehead) :)
> However we need to invoke it moderately frequently
> (each time
> LogFactory.getLog is called). So I'm not sure normal
> reflection will be
> acceptable.
>
Particularly given your point a week or two ago about
libraries not caching Logs in static fields. Caching
in instance fields will increase the number of
LogFactory.getLog calls.
>
> >
> > 3) Did a little archeology and it looks like JCL
> 1.0.1
> > was cut about a week before the AccessController
> stuff
> > was added. So that's the last release that ran on
> JDK
> > 1.1.
>
> Yep, that's how I read the CVS/SVN logs too. Version
> 1.0.2 was JDK1.2
> only.
>
> There's no information I can find on whether the
> change to drop JDK 1.1
> was deliberate or not..
For odd reasons (see below) I was reading Bugzilla
10825, and in the bug's discussion thread there are
comments made just a few weeks before the
AccessController stuff was added that JDK 1.1.8
compatibility was important.
>
> >
> > 4) Throwing in my own 2 cents, I think of JCL as
> being
> > targetted to component/library/framework
> developers.
> > I don't expect there are many applets being
> written
> > that target 1.1 and also incorporate the kinds of
> > libraries that use JCL.
>
> Well, as I said in my earlier email, Win9x (and
> possible WinNT) shipped
> with the microsoft 1.1 JVM, and I believe a fair
> number of simple
> applets still target that JVM in order to avoid
> requiring users of those
> operating systems to install a JVM explicitly.
>
>
> My current opinion, though, is that we should:
> (a) simply document the current state in the
> commons-logging website
> and/or wiki: JCL 1.0.2 and later require JVM1.2.
+1 .....except I just tried running JCL 1.01 using JDK
1.1 and it failed with an NPE. This was Bugzilla
10825 which was corrected in 10/2002. As I understand
it, basically JCL will fail under JDK 1.1 if it is
loaded by the system classloader (which it is in my
simple test).
Just tried JCL 1.0 and had the same problem.
I suppose in the applet-running-in-Windows scenario
that we are most concerned about JCL wouldn't be
loaded by the system classloader, so the bug may not
apply.
> (b) when working on the revised JCL, regard support
> for 1.1 as
> "desirable but not mandatory".
>
Sounds good to me. Perhaps some of Robert's ideas
about lifting off a LogFactory superclass will open a
path to providing support to 1.1 without having to
overly encumber the normal discovery process.
> I think at this point the work we already have in
> progress for JCL is
> enough without tackling this task too.
>
+1
I know that for me personally spending the last couple
evenings digging into the intricacies of getting
things to work on JDK 1.1 has pretty well exhausted my
appetite for the topic ;)
Brian
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
