Community
Participate
Working Groups
There are several inconvenient "convenience" methods cluttering this interface that I'd like to get rid of before R2.0.
I will attach patches of the changes for review.
Created attachment 69118 [details] Removing extraneous methods from ISystemProfileManager Please review the attached patch. It removes methods from ISystemProfileManager that should better be left up to consumers of the interface. Also removes the methods from the SystemProfileManager implementation.
Patch looks good to me. Note that it's a breaking API change because you remove methods. Note that there is constructor Vector(Collection c) which allows you to write the code slightly more elegant: String[] nameArray = manager.getSystemProfileNames(); Vector names = new Vector(Arrays.asList(nameArray)); Then, taking into account that Vector is synchronized on all access which is not necessary here, a further optimization could be made by allowing ValidatorProfileName and all other validators take a List argument instead of a Vector argument. List is a superinterface of Vector and more generic than Vector. Doing so, you could pass in an ArrayList rather than a Vector -- the ArrayList is not synchronized. Feel free to make these changes or not, it's up to you.
Patch applied. Martin's suggestions made as well. All validators changed from Vector to List arguments which generalized and simplifies the code. This bit is a non-breaking change since List is a superInterface of Vector.
(In reply to comment #4) > This bit is a non-breaking change since List is a superInterface of Vector. Just for completeness, it would have broken binary compatibility. But yes, it is source compatible. Which means that client code needs to be recompiled against the new sources in order to run. This means, that we could not have made this change in the 2.0.1 stream. Good to have it now. BTW, are the validators defined to access the List passed into them in a read-only manner? That would be an important part of Javadoc. Because if they access it read-only, we can pass in arrays by ValidatorNames(Arrays.asList(myArray)) directly without having to create a new, modifiable array before. I'd very much recommend specifying them as accessing the list read-only (if they do need to make modifications they could copy the list locally).
Actually, would a Collection rather than a List also work? Collection is a superinterface of List, and as long as you only like to * know whether an element is there or not * convert into an array * dont depend on any particular sorting or uniqueness constraints You you should be fine with accepting a Collection as well. This would allow also passing in things like a HashSet if the client prefers such data structures. But the "read-only" property mentioned before is certainly more interesting than the "Collection or List" property.
I usually steer away from putting Collections in interface definitions from habit since they are so general, but I think in this case the only thing that's needed is to have a exclusion list - in which case a collection would be perfectly OK. I'll take a look.
The read-only idea is good. I'll document it in the javadoc.
Changed list arguments to collections and documented read-only behavior for them.
[target cleanup] 2.0 RC2 was the original target milestone for this bug
