On 25/05/2010, David Brosius <[email protected]> wrote: > >> The test cases already require Java 1.5, but the main code currently > requires only Java 1.4. > Probably should consider updating that to 1.5 at some point. It will > require a good deal of work to fix all the raw types etc., but doing > that should make the code safer. > > > Again, 5.2 requires jdk 1.3.
The current POM (5.3-SNAPSHOT) requires 1.4. Dunno when this was changed. > i'm fine with bumping this up, but it's > unclear to me if there are any apache processes needed to be followed to > change this requirement, or whether we are free to just do it. It can certainly be changed. Might be an idea to vote on it just in case. Not sure that Jakarta has a documented policy for what changes can be introduced in each type of release (major, minor, point). Minor releases must normally be drop-in replacements, at least API-wise. Changing minimum JVM release is a bit trickier - AFAIK, some PMCs allow this in a minor release. If there is any doubt, the next release could be 6.0 (there's quite a few other changes anyway). > > >> Another item to consider at some point is whether to try and make the > code thread-safe. > > > I would strongly recommend against doing that. I don't believe it's a > parsing library's job to provide this, as it tends to usually be a single > threaded activity. However, the code at the moment is not only not thread-safe, AFAICT it is thread-hostile. There are quite a few mutable static fields which control the processing. So the question should be: should the code be made thread-compatible, so that different threads could use their own independent instances. At present that is not possible as far as I can tell (except by using different classloaders). > > > ----- Original Message ----- > From: "sebb" <[email protected]> > Sent: Tue, May 25, 2010 11:30 > Subject:Re: [BCEL] anyone working on BCEL ? > > > On 25/05/2010, Torsten Curdt <[email protected]> wrote: > > > Is anyone working on - or wanting to work on - BCEL at present? > > > > > > Patch applying time is slowly approaching for me. But that's about it. > > > > > > > I know that Findbugs are keen to get away from using their patched > version. > > > > > > Well, we talked years ago. More than happy to accept patches from > > them. IIRC last them they said they are too specific though ...so. Up > > to them. But it would be great to work this out. A lot of wasted > > effort otherwise. > > > > > > > I can do some tidying up of test cases and basic warnings if that > would help. > > > > > > All contributions are welcome :) > > > > I've done a bit of tidying up of licences and a few Eclipse warnings etc. > > Unfortunately the code is infested with tabs. > I've not done anything about that yet, because it's only cosmetic, and > would make older patches (if there are any) harder to apply. > > > > There seem to have been a lot of fixes since 5.2, so it would be good > > > to get a new release out. > > > > > > I think the one thing *really* missing for a new release are people > testing it. > > Big changes since last release. > > Also unit tests - there don't seem to be many for such a large codebase. > > The test cases already require Java 1.5, but the main code currently > requires only Java 1.4. > Probably should consider updating that to 1.5 at some point. It will > require a good deal of work to fix all the raw types etc., but doing > that should make the code safer. > > Another item to consider at some point is whether to try and make the > code thread-safe. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > > ----- End of original message ----- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
