Re: [collections] VOTE: Collections-java5 direction ; notifying collections
[EMAIL PROTECTED] wrote on 03/14/2007 08:22:30 PM: There are plenty of regular users of commons-collections who are also commons developers (including myself), so I'm quite sure that the existing non-generics library will be maintained long-term (ie bugfixes applied). Whether there is enough enthusiasm to add significant new features once the generics-enabled version is out is less certain, but that's less important. You certainly don't need to worry about being left using a buggy commons-collections. Muchas gracias! Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction ; notifying collections
Stephen Kestle [EMAIL PROTECTED] wrote on 03/12/2007 09:15:11 PM: Bryce L Nordgren wrote: Are you going to still produce binary releases which are compatible with 1.4, even though they won't be able to compile the new source releases? Or are you going to use some sort of code stripper thingy which gets rid of generics for backwards source compatibility? No, not as far as the conversation is going. Bear in mind that SDKs =1.4 inspired this library due to perceived shortcomings in the reference implementations of the collection framework interfaces. It seems counterintuitive to make SDKs = 1.5 the only platform on which this can compile. But as long as the binaries stay backwards-compatible, that's OK. Why bother? The current collections serve very well for =1.4. The major pain is coming from 1.5 users having to suppress warnings all over the place if they want to use commons-collections. I understand that the binary break will limit the backwards compatibility, but if you're needing to develop for 1.4 and 1.5, use 1.4 libs. As far as I see, most people leap to Java 5 rather than tip toeing. First, let me understand the proposal. Is a 1.4 compatible version of commons-collections going to continue to be supported simultaneously with the 1.5+ reboot? Your answer above indicates no. If the answer is in fact no, you answered your own question (Why bother?) with if you're needing to develop for 1.4 and 1.5, use 1.4 libs. You raised a very good reason to bother. However, if the answer is yes, I can go away happy and stop bothering everyone with large codebase maintenance issues. My perspective may not be common. The GeoTools project has been under development for years. It is modular and has many many separate developers, some of whom have moved onto greener pastures. The official policy is that we develop for Java 5 now. Yet there is a sizable code base developed during the time of 1.4. Although we have our Java 5 advocates, there is no one with the budget of time or money to pull the entire code base forward simultaneously. So if it happens at all, it must happen by means of tip toeing. Veteran, well-tested code may eventually be phased out, but realistically we're talking years. We may see Java 1.8 before the last of 1.4 is phased out. We just don't have the developer power to factor in the latest compiler toys every two years (and deal with the new bugs introduced by the process), no matter how shiny the new toys are. Ergo, we need access to quality 1.4 libraries for the foreseeable future. Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction
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 intuitive type checking. Collections can contain mixed types which are bounded on both the top and the bottom end. They can also be forced to contain only one type of object. This allieviates some of the practical problems with Java5 collections; namely you can't add anything to a Collection? extends Object. If you intend to retain this functionality, I believe the only legal way is to retain implementations of Collection (no generics). I would very much like to see this functionality retained. :) Please pardon me if this was an obvious email. Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction
Jess Holle [EMAIL PROTECTED] wrote on 03/12/2007 12:28:34 PM:
You can always get the current unchecked behavior with
CollectionObject.
Thing 1:
Ummm. The fact that the above statement is incorrect is precisely why
Java5 generics syntax is dangerous. CollectionObject is not considered a
supertype of any other typed Collection, and is therefore not
interchangeable with other typed collections. (e.g. you can't pass it
around like you would a Collection)
To treat the elements of the collection as you always have, one needs
CollectionObject, as above.
To treat the collections themselves as you always have, one needs
Collection?.
However, if you have a collection which is a supertype of all other
collections, you cannot add any elements to it because the single legal
element type for that collection is unknown.
Thing 2:
I don't want the old unchecked behavior. I want checked behavior,
commons-collections style. Commons-collections can handle mixed element
types, where every element has bounds on its types. Generics do not even
contain a way to express this collection is potentially composed of a
mixture of elements, but every element is guaranteed to be between {Parent}
and {Child} in the class hierarchy. In order to implement this type of
checked behavior, Java Generics requires that we use the unchecked
syntax. I guess we should call it implementation-defined type checking.
My plea is not intended to start a war over Java generics, but to beg that
current functionality not be abandonded merely because Java Generics cannot
adequately describe it.
Thing 3:
:)
Bryce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction
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 guaranteed to be between
{Parent}
and {Child} in the class hierarchy. In order to implement this type
of
checked behavior, Java Generics requires that we use the unchecked
syntax.
You can express the bounds of ? extends A super B, right? There's
even a more obscure syntax for expressing something that extends
multiple classes in cases.
My fears have just been amplified by about an order of magnitude. Your
expression does not repeat _NOT_ mean: this collection is potentially
composed of a mixture of elements, but every element is guaranteed to be
between {Parent} and {Child} in the class hierarchy. It means this
collection contains elements all of the same type, and this type is
guaranteed to be between {Parent} and {Child}.
Use Java generics to express concepts that Java generics actually contains
a vocabulary for. However, please do not exclude current functionality
merely because Java generics cannot articulate the concept.
Generics is a minefield. Please be extremely cautious.
Bryce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction ; notifying collections
Stephen Smith [EMAIL PROTECTED] wrote on 03/12/2007 03:35:06 PM:
That sounds like a good point to me. Have you thought about submitting
some backwards compatibility test cases to Jira, to ensure we don't trip
over any such problems?
I believe I wrote two Predicates (SuperclassPredicate and
SubclassPredicate). Construct the AndPredicate(SuperclassPredicate(lower),
SubclassPredicate(upper)) and Bob's your uncle. I don't know how to write
the test cases for generics. What happens when you do:
public class PredicatedCollectionT {
T public static CollectionT decorate(CollectionT, Predicate) {
.. }
} ;
and then try to run
Collection safe = PredicatedCollection.decorate(new ArrayList(),
myPredicate);
Does the compiler figure this out correctly or does it do something subtly
nonintuitive?
===
It may be that Java generics adds type safety for some. However, if you're
passing collections back and forth between 1.4 code and 1.5/1.6 code, you
have all the potential problems of the un-typechecked world _plus_ the
false sense of security that you're safe. In short, your library offers
real type safety. Please don't limit the reboot to the incomplete type
safety offered by Java generics. There is real value added here.
On another note, I messed with commons-events (dormant). I did it in the
GeoTools subversion server because I had commit access there. The product
is a little incomplete and provides a notifying collections framework.
Sooner or later I have to polish it off. When that happens, is there any
interest in folding it into commons-collections before or after the reboot?
If not, GeoTools is going to need to petition Apache to release the code to
us under LGPL instead of the ASL in order to make licencing manageable. At
that time, I'll refactor it into the GeoTools package space.
Bryce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction ; notifying collections
Stephen Kestle [EMAIL PROTECTED] wrote on 03/12/2007 07:05:21 PM: I'm unsure why people who use Java 5 only should pay a runtime penalty when it isn't needed. If this issue concerns you, use java.utils.Collection.CheckedCollection. Being a C fanatic, I said the same thing about array bounds checking and garbage collection. In for a penny in for a pound. But at least in C I _knew_ I was responsible for ... well... everything. This may be an example of my point about illusory safety. You write all your own code from scratch? Or you use only libraries which have been generified? You never pass a Java5 collection to a library written before generics? To give an example close to home: you _never_ use the current commons-collections, in particular the TransformedCollection decorator? Just because your code is Java5 and you're only using the java5 jvm doesn't mean that everything maven goes out to grab was compiled with java 5 as a target. Transitive dependencies aggravate this situation. If you're writing something that is supposed to work with 1.5 _and_ 1.4, you cannot use CheckedCollection. Kindof a gotcha. Are you going to still produce binary releases which are compatible with 1.4, even though they won't be able to compile the new source releases? Or are you going to use some sort of code stripper thingy which gets rid of generics for backwards source compatibility? Bear in mind that SDKs =1.4 inspired this library due to perceived shortcomings in the reference implementations of the collection framework interfaces. It seems counterintuitive to make SDKs = 1.5 the only platform on which this can compile. But as long as the binaries stay backwards-compatible, that's OK. However, if the library offers real type safety already, then it should continue to do so, or at least offer a decent workaround. Amen! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-events: similarity to java.beans.PropertyChangeSupport
Please respond with comment on http://issues.apache.org/jira/browse/SANDBOX-149. I am exploring re-designing collections-events using extension of the standard property change support stuff in java.beans. I'm trying to keep the goals/tradeoffs mentioned in the 3 proposals email in mind. The main thing I don't quite understand yet is: The packages currently support vetoable changes _and_ pre/post events. Aren't these the same thing? Or should pre/post events be renamed to change requests and changes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Collections-events
Stephen Colebourne [EMAIL PROTECTED] wrote on 06/08/2006 01:29:25 AM: I would be willing to help revive collections-events if there is interest. Even more so if it can happen with generics support. Logically, this would be a generics only project now. Does this affect you Bryce? (If it does, then perhaps we might need to try retro*) I could go either way. I'd be biased towards keeping it 1.4 just because I don't think Generics adds anything to this particular block of code. How would you even use Generics with ObservableCollection/Set/Map/List? If there's a legitimate use of generics within the package, I may be convinced. Generics seems more applicable to commons-collections. Jeez, you start porting commons-collections to generics and you've suddenly got an awful lot of overlap with Java5 SE. You've got a really good thing going on here with your implementation! You have a typed collections framework which does not require a JVM change. Furthermore, if you do use a java 5 sdk targeted to java1.4, your type-checking still works (unlike the J2SE package). Why would you want to change that and become redundant? But the best reason to stay at 1.4, at least for now: it seems to already work! I really don't understand why this was mothballed. Might it be released as 0.1 in its current state, then refactored to 1.5 in the next release? On the other hand, I don't have a good grasp of why one would use generics at all, especially at the cost of breaking compatibility with many existing systems. Take it with a grain of salt. :) Now if it was a full-up template facility, I could see using it. Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Collections-events
Commons-collections is too big. It was deliberately broken out to make both parts managable. This project did have quite an active life at first. Where it floundered was that there were IIRC three competing code implementations (not just designs). I believe that all are currently in SVN. To revive this, we would have to select one without excessive ego. I'm not sure I'm looking at the same package. I see 25 classes, 30 tops. There doesn't seem to be any overlap (e.g. two concepts coded in competing ways). And when it's compiled, the jar is 35k. (less than 10% of commons-collections, which weighs in at 500k--and commons-events depends on commons-collections to boot). I also believe that Michael Heuer may have released something related on java.net? Cool. I'll go looking for it too. Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-events passes tests...
My original checkout of commons-events failed two out of 316 tests packaged with it. It took a couple of hours, but here's the diagnosis: I was depending on commons-collections 3.1 and the test in commons-events was finding a bug in HashBag (actually AbstractMapBag) w.r.t. the return value of remove(). I updated the dependency to commons-collections-3.2 (installed manually in my maven repo) and the problem vanished. (I did have to fix some control logic in ObservableBag, but it was really cosmetic.) Note that even though the buggy return value was fixed, the unit tests for commons-collections (3.2) do not examine the return value of the remove() method. I don't know whether this is a bug or not. :) Now the patient looks fine!! Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-collections events
Dear Jakarta Commons developers I'm in the process of stealing (possibly forking) the dormant project commons-events. While I am highly motivated to adopt it as a baseline, I'd be integrating it into a Geospatial library (GeoTools; http://docs.codehaus.org/display/GEOTOOLS/). I'd really rather keep it separate and refer to it by a dependency. Would there be any interest in reviving this project if I handed it back to Apache with tests, a maven 2 POM, and whatever fixins might be required to make it function? Conversely, would anyone have advice on the current state of the code (what to watch out for, etc.) for a person primarily interested in the ObservableSet/Map/List/Collections? As I am lazy and refactoring is work, I hope to sweet talk someone here into taking commons-events back when I'm done with it. Maybe even release it. :) Progress may be observed at: http://svn.geotools.org/geotools/branches/jts-wrapper/module/events/ Out of curiousity, is there any reason not to absorb commons-events back into commons-collections? Thanks, Bryce PS: I'd like to update my maven dependency for commons-collections to 3.2, but it's not on ibiblio yet (released May16th). When might this arrival be celebrated? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
