In message <[EMAIL PROTECTED]>, steve cohen writes: >This code was calling a method in ORO that returned a Collection, also not >JDK1.1 compatible. Since the older ORO method that returned a Vector had >been deprecated, I looked at what it was doing, which was simply splitting a >string on a comma. This was an overkill use of ORO, easily replicated with a >StringTokenizer.
Oh yeah, it's way better to use StringTokenizer when you're splitting on just a constant string rather than an actual regular expression. However, if there's anything that doesn't work in 1.1 because of ORO, I can get off of my ass and finally do the multi-version compilation support we'd talked about on oro-dev. We wanted to use conditional compilation to simultaneously support J2ME, J2SE 1.2, and J2SE 1.4. J2ME support effectively makes it JDK 1.1 compatible, so we could also throw in a JDK 1.1 target. The changes are minor; the equivalent of a few ifdefs. But it keeps J2ME folks from having to make the changes themselves and will take care of any Commons Net users who complain about Net breaking on JDK 1.1 because of ORO. At any rate, if the ORO dependency is the only thing preventing 1.1 compatibility I can take care of that over the next week. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
