Re: [collections] VOTE: Collections-java5 direction

over any such problems? Steve. --- Stephen Smith, MEng (Wales). http://www.stephen-smith.co.uk/ Bryce L Nordgren wrote: Jess Holle <[EMAIL PROTECTED]> wrote on 03/12/2007 03:09:49 PM: Bryce L Nordgren wrote: Thing 2: (snipped) Generics do not even contain a way to ex

Re: [collections] VOTE: Collections-java5 direction

Bryce L Nordgren wrote: Jess Holle <[EMAIL PROTECTED]> wrote on 03/12/2007 03:09:49 PM: Bryce L Nordgren wrote: Thing 2: (snipped) Generics do not even contain a way to express "this collection is potentially composed of a mixture of elements, but every element is

Re: [collections] VOTE: Collections-java5 direction

Bryce L Nordgren wrote: Jess Holle <[EMAIL PROTECTED]> wrote on 03/12/2007 12:28:34 PM: You can always get the current unchecked behavior with Collection. Thing 1: Ummm. The fact that the above statement is incorrect is precisely why Java5 generics syntax is dan

Re: [collections] VOTE: Collections-java5 direction

ntain compatibility with older callers it is a thing of beauty. -- Jess Holle Bryce L Nordgren wrote: Hey all, This may be something so simple it goes without saying, but it also may be something that's easy to overlook. The main value of commons collections is that it performs "

Re: [logging] log4j 1.3 support

Level or Logger and are still based on Priority and Category. There were other issues too, but I'd figured out less ways around them. This is where I gave up. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED]

Re: [jxpath] one-size-fits-all "eval"?

Ooops. I meant to type "commons-user"... Correcting now. -- Jess Holle Jess Holle wrote: Dmitri Plotnikov wrote: Jess, First of all, this discussion is probably better suited to the commons-user mailing list. Sorry, you're right -- I crossed a line with this fol

[jxpath] one-size-fits-all "eval"?

h of these interfaces * Boolean * Number * String [I assume callers will apply includes castes within their XPath expressions as necessary where they expect a non-node result.] Is there such a beast? The one-API fits all (beans, JDOM, DOM, etc) approach makes this a bit hard for me to decipher. -- Jess Holle

Re: [jxpath] Future of JXPath and DOM???

re they expect a non-node result.] Is there such a beast? The one-API fits all (beans, JDOM, DOM, etc) approach makes this a bit hard for me to decipher. -- Jess Holle

Re: [jxpath] Future of JXPath and DOM???

So if such an optimization was added there would be a way to by-pass it as well? [This can't just be "if Xalan is not present" -- as Xalan is present for other reasons.] -- Jess Holle Dmitri Plotnikov wrote: Jess, JXPath has always supported Xalan through JAXP DOM APIs. Wh

Re: [jxpath] Future of JXPath and DOM???

P.S. Also, I must admit this message is somewhat of a test. If no one responds, then I can assume the JXPath community is not active enough to be worth considering over sticking with an old version of Xalan for the forseeable future. Jess Holle wrote: I am using Xalan 2.1.0 for XPath

[jxpath] Future of JXPath and DOM???

* the intended direction of JXPath, * the level of commitment to the XPath standard, and * the level of commitment to supporting the non-XSLT DOM use case outlined above. -- Jess Holle