RE: [lang] next version etc
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, April 16, 2006 7:23 AM To: Jakarta Commons Developers List Subject: Re: [lang] next version etc snip 36925: Status Gary? I like the feature and it is done and it tested. The only thing I can think of is trying to make the API names better (they seem fine now to me). I would like to see method override taking in a Collection of Strings, otherwise its done. snip A Collection version of the method is now in SVN. All feedback welcome. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] next version etc
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 6:04 PM To: Jakarta Commons Developers List Subject: [lang] next version etc I want to do something fun...so how about a Lang release. First up; 2.2 or 3.0? It would be nice to have one without enum and the other deprecated bits. IMO: 2.2, then 3.0 which removes 'enum' and anything that Java 5/6 complains about. Or... The ticket list below is long and diverse in scope and time needed. A possible release early, release often track could be: - Release 2.2 now, with only critical fixes. Time frame: now=weeks. - Release 2.3: implement easy fixes and apply no-brainer patches. Time frame: +1 month. - Release 2.4: implement trickier new features that require discussion and time to implement. Time frame: Months. - Release 3.0: - discuss breaking the API by removing deprecated methods? - discuss changing the base JRE requirement? - discuss deprecating any date/time code that can be replaced with Joda-Time. - builds/works on Java 5? - builds/works on Java 6? Some brief comments on some of the list items: Second up; text? I think it needs to go into our next version regardless of version number, or we need to decide to drop it. I will use text.VariableFormatter in our product. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) I have no plans to use the Str* classes though. Third, bugs. Here're my thoughts: 20015: WONTIFX? Gary's on making Entities public. Looks like a lump of work to do, is it likely to happen or should we just decide that Entities shouldn't be public? I don't recall user's being desperate to use this class. Release early, release often. Let's leave this one for later. 26659: WONTFIX? Seems like too much in the way of date work - suggest JODA instead unless a patch is offered. I use Joda-Time now. I would even like to propose deprecating DateUtils 'softly' in favor of Joda-Time. I am sure many will not like this at all since Joda-Time is pretty large. 29692: Patch recently added. Consider and either apply or WONTFIX. Seems too specific/complex. 30082: WONTFIX. This is too specific an issue to be putting in Lang I believe. I agreed. 30184: Consider for lang.text. There are no unit tests provided (I know, the class is pretty simple). 31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated, or is it simple enough and we can do it? 33102: FIX: On the one hand, it's pretty simple stuff, and we'd have to support the roll(..) method. On the other hand, user's like this stuff and it's not hard to add it, even if we overload with Calendar as well. 4 methods would be needed. +0. Joda-Time? 33401: FIX: it's a bit redundant, but I've no reason not to have these methods available. Any -1s? Needs better method names IMO. -0. I'm always in favor of release early, release often when there are no unit tests with a code proposal ;) 33609: FIX. Javadoc needs improving. Nothing wrong with better docs! :) 33825: WONTFIX. Standard java.time question - is it valuable and simple, or should we just point to JODA? I'm going to go with WONTFIX as my default answer on time enhancements. I'm with you: Joda-Time. 33889: Unsure. Could be a CharSet enhancement instead of just a camel case method. Thoughts? 33997: I think this is a useful method - just need to make sure the implementation is the best possible. What about commons-math? 34284: FIX: NullPointer; test and fix. 34351: FIX: I don't see any reason not to try to write Albert's method. If not obvious when digging into it, then we can WONTFIX. 35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave the scope of 'simple' to my ignorant brain :) 35588: Part of the lang.text call. I need text.VariableFormatter. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) 35826: Bring up with [math]. I think it could be in either, not sure I have the itch to write a BigXxx replacement though. Indeed, what does [math] think about that? It would be interesting to know what the [math] folks think about project boundaries for class like that. 36061: FIX. Seems simple enough - bug and patches. Some of these bugs might be obsolete. I thought I'd take care of object cycles a while back. Hm, but that might have been for the ReflectionToStringBuilder class, not the ToStringBuilder. 36512: FIX. I think there's value for a .forName improvement. Personally, I would only do the super simple stuff, primitives I suppose. Arrays of primitives ok... Basically, anything that you can say in Java code: int, int[]. Yeah, that's nice. But I would not want to have us invent a mini-language which the talk of eating up spaces starts to feel like. My vote would be to keep it simple in the first cut, if it is there at all. 3: Thoughts? Is it worth putting that inside
Re: [lang] next version etc
-- 20015: WONTIFX? Gary's on making Entities public. Looks like a lump of work to do, is it likely to happen or should we just decide that Entities shouldn't be public? I don't recall user's being desperate to use this class. Release early, release often. Let's leave this one for later. -1.- XML at this level is out of scope -- 26659: WONTFIX? Seems like too much in the way of date work - suggest JODA instead unless a patch is offered. I use Joda-Time now. I would even like to propose deprecating DateUtils 'softly' in favor of Joda-Time. I am sure many will not like this at all since Joda-Time is pretty large. -1. There are many complications getting this kind of calculation right, and people should be forced to use a proper tool ;-) -- 29692: Patch recently added. Consider and either apply or WONTFIX. Seems too specific/complex. -1. A multiline string isn't really the same as a regular string. Its more at the business logic level to define how a multiline string works (ie. perhaps it should be a class holding a String[]) -- 30082: WONTFIX. This is too specific an issue to be putting in Lang I believe. I agree. Much of StringEscapeUtils is dubious scope for lang. Adding this doesn't help. -- 30184: Consider for lang.text. There are no unit tests provided (I know, the class is pretty simple). Could be added, though I'm not especially fussed. -- 31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated, or is it simple enough and we can do it? -1, This stalled because its a mess of possible issues. There isn't even a solution in Joda-Time yet. -- 33102: FIX: On the one hand, it's pretty simple stuff, and we'd have to support the roll(..) method. On the other hand, user's like this stuff and it's not hard to add it, even if we overload with Calendar as well. 4 methods would be needed. +0. Joda-Time? +1 to add, -0 to roll. -- 33401: FIX: it's a bit redundant, but I've no reason not to have these methods available. Any -1s? Needs better method names IMO. -0. I'm always in favor of release early, release often when there are no unit tests with a code proposal ;) -1, these seem too specific to me -- 33609: FIX. Javadoc needs improving. Nothing wrong with better docs! :) +1. -- 33825: WONTFIX. Standard java.time question - is it valuable and simple, or should we just point to JODA? I'm going to go with WONTFIX as my default answer on time enhancements. I'm with you: Joda-Time. -1. The JDK doesn't support time or date ranges. Trying to patch support in would lead to large amounts of code in the end. -- 33889: Unsure. Could be a CharSet enhancement instead of just a camel case method. Thoughts? +1. But stick with a fairly simple implementation. -- 33997: I think this is a useful method - just need to make sure the implementation is the best possible. What about commons-math? Trouble is that double can't accurately hold some numeric values. I believe that this is what BigDecimal is for. I won't stop a mathematician having a go though. -- 34284: FIX: NullPointer; test and fix. +1 FIX -- 34351: FIX: I don't see any reason not to try to write Albert's method. If not obvious when digging into it, then we can WONTFIX. Not something I've ever hit, but no objections to FIX. -- 35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave the scope of 'simple' to my ignorant brain :) Probably should fix this, but classloaders just go wrong. -1 -- 35588: Part of the lang.text call. I need text.VariableFormatter. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) Do you need all its complexity with escaping? -- 35826: Bring up with [math]. I think it could be in either, not sure I have the itch to write a BigXxx replacement though. Indeed, what does [math] think about that? It would be interesting to know what the [math] folks think about project boundaries for class like that. There is almost certainly a need for these classes, but I'm not volunteering to write them from scratch. 36061: FIX. Seems simple enough - bug and patches. Some of these bugs might be obsolete. I thought I'd take care of object cycles a while back. Hm, but that might have been for the ReflectionToStringBuilder class, not the ToStringBuilder. FIX if still an issue -- 36512: FIX. I think there's value for a .forName improvement. Personally, I would only do the super simple stuff, primitives I suppose. Arrays of primitives ok... Basically, anything that you can say in Java code: int, int[]. Yeah, that's nice. But I would not want to have us invent a mini-language which the talk of eating up spaces starts to feel like. My vote would be to keep it simple in the first cut, if it is there at all. +1, but treat this with care. Its a potential feature scope into parsing the whole of Java. -- 3: Thoughts? Is
Re: [lang] next version etc
On 4/15/06, Gary Gregory [EMAIL PROTECTED] wrote: -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 6:04 PM To: Jakarta Commons Developers List Subject: [lang] next version etc I want to do something fun...so how about a Lang release. First up; 2.2 or 3.0? It would be nice to have one without enum and the other deprecated bits. IMO: 2.2, then 3.0 which removes 'enum' and anything that Java 5/6 complains about. Or... The ticket list below is long and diverse in scope and time needed. A possible release early, release often track could be: - Release 2.2 now, with only critical fixes. Time frame: now=weeks. - Release 2.3: implement easy fixes and apply no-brainer patches. Time frame: +1 month. - Release 2.4: implement trickier new features that require discussion and time to implement. Time frame: Months. I think it's worthwhile to group the issues into the separations you've suggested, then we can discuss release points. Size of groups would determine whether the above makes sense. My immediate feel is that it's too many releases - good for Lang but bad for the other Commons components if we suck up 4 or 5 of our interest level in this way. - Release 3.0: - discuss breaking the API by removing deprecated methods? There needs to be discussion? :) General rule is that we drop deprecateds at the next major. - discuss changing the base JRE requirement? Any reasons jumping to mind to change? - discuss deprecating any date/time code that can be replaced with Joda-Time. This should be done in 2.2/ASAP. I'm not sure we have that much that should be deprecated - we just need to be getting good at drawing the line of what is fine to implement and what is too much. - builds/works on Java 5? - builds/works on Java 6? +1 to both. Trying to build commons components under Harmony is on my todo list too. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] next version etc
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 16, 2006 7:23 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] next version etc
snip
--
30184: Consider for lang.text.
There are no unit tests provided (I know, the class is pretty
simple).
Could be added, though I'm not especially fussed.
IMO, we should always add unit tests with new code. This is a case of
eating our own dog food, process-wise. If we do not lead by example, we
are not encouraging patch submitters to submit unit tests with their own
patches.
snip
35588: Part of the lang.text call.
I need text.VariableFormatter. If 2.2 does not come out soon, I am
going
to pluck it out of there for our own use ;)
Do you need all its complexity with escaping?
I want to provide our users with highly flexible configuration files
(and scripts) where Java system properties and environment variables are
available.
It is possible that some of our users would need escaping things like
'$' and '{}'. The flexibility I would be willing to give up is what
characters to use for $ and {}, but this is the part that adds the least
amount of complexity.
If you are thinking of removing the ability to do things that correspond
to ${aVarPiece${anotherPiece}}, then I am somewhat indifferent right
now. It just seems like a lot of work to undo the code and the unit
tests since the current implementation works and it well covered by unit
tests. Furthermore, it seems to me like once a feature like
VariableFormatter is released, implementing the above feature would be
the next step in the evolution of the class. Just my POV though...
snip
36925: Status Gary?
I like the feature and it is done and it tested. The only thing I
can
think of is trying to make the API names better (they seem fine now
to
me).
I would like to see method override taking in a Collection of Strings,
otherwise its done.
I am working on this now.
snip
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] next version etc
On 4/16/06, Gary Gregory [EMAIL PROTECTED] wrote:
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
35588: Part of the lang.text call.
I need text.VariableFormatter. If 2.2 does not come out soon, I am
going
to pluck it out of there for our own use ;)
Do you need all its complexity with escaping?
I want to provide our users with highly flexible configuration files
(and scripts) where Java system properties and environment variables are
available.
It is possible that some of our users would need escaping things like
'$' and '{}'. The flexibility I would be willing to give up is what
characters to use for $ and {}, but this is the part that adds the least
amount of complexity.
If you are thinking of removing the ability to do things that correspond
to ${aVarPiece${anotherPiece}}, then I am somewhat indifferent right
now. It just seems like a lot of work to undo the code and the unit
tests since the current implementation works and it well covered by unit
tests. Furthermore, it seems to me like once a feature like
VariableFormatter is released, implementing the above feature would be
the next step in the evolution of the class. Just my POV though...
+1 to the escaping - it seems like it's just doing the right thing,
not an increased feature.
Increased feature would be: ${ENV.foo} :) Where ENV means the
environment (or ${D.foo} where it means the standard env).
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] next version etc
Summarising the 25 remaining open issues: Debatable: 29692 - I think a lang.text.Indenter would be valuable. (33825), 38800 - DateRange class. Two separate offerings of this class. What are the problems with having this? What are the hidden bugs? Remaining issue for next release: 30184 - CompositeFormat 33401 - check 34284 - NPE in EqualsBuilder 34351 - ClassUtils.getPublicMethod 35588 - text.VariableStuff 36061 - Error in ToStringBuilder 36873 - text.VariableStuff 37385 - Improve javadoc for EscapeUtils 38569 - StringEscapeUtils amphersand bug. 39254 - Expose DateIterator or add method 39315 - New method for EqualsBuilder 37499 - Improve parseDate API The following seem to involve significantly more time than the above - still could go in next release but time needs to be spent. 33889 - Split camel case code. 36512 - Enhanced forName 3 - EnumUtils in 1.5 36925 - ReflectionToStringBuilder and secure fields 37243 - DateUtils.trunc + DST bug 37690 - RandomString + Unicode 38210, 39167 - Complaints about the escapeXml functionality. 38401 - Bug in DurationFormatUtils Must wait until 3.0: 36886 - Change Exception in Validate.notNull 39322 - Clean up Lang Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] next version etc
3.0 vs. 2.2? I say let's do both! Let's release 2.2 with the new features and quickly release 3.0 with the deprecated stuff removed/cleaned up (no new features). That way, we're able to give the new features to folks who also need the deprecated stuff. But, we're also able to slim down a bit immediately thereafter. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 9:04 PM To: Jakarta Commons Developers List Subject: [lang] next version etc I want to do something fun...so how about a Lang release. First up; 2.2 or 3.0? It would be nice to have one without enum and the other deprecated bits. Second up; text? I think it needs to go into our next version regardless of version number, or we need to decide to drop it. Third, bugs. Here're my thoughts: 20015: WONTIFX? Gary's on making Entities public. Looks like a lump of work to do, is it likely to happen or should we just decide that Entities shouldn't be public? I don't recall user's being desperate to use this class. 26659: WONTFIX? Seems like too much in the way of date work - suggest JODA instead unless a patch is offered. 29692: Patch recently added. Consider and either apply or WONTFIX. 30082: WONTFIX. This is too specific an issue to be putting in Lang I believe. 30184: Consider for lang.text. 31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated, or is it simple enough and we can do it? 33102: FIX: On the one hand, it's pretty simple stuff, and we'd have to support the roll(..) method. On the other hand, user's like this stuff and it's not hard to add it, even if we overload with Calendar as well. 4 methods would be needed. 33401: FIX: it's a bit redundant, but I've no reason not to have these methods available. Any -1s? 33609: FIX. Javadoc needs improving. 33825: WONTFIX. Standard java.time question - is it valuable and simple, or should we just point to JODA? I'm going to go with WONTFIX as my default answer on time enhancements. 33889: Unsure. Could be a CharSet enhancement instead of just a camel case method. Thoughts? 33997: I think this is a useful method - just need to make sure the implementation is the best possible. 34284: FIX: NullPointer; test and fix. 34351: FIX: I don't see any reason not to try to write Albert's method. If not obvious when digging into it, then we can WONTFIX. 35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave the scope of 'simple' to my ignorant brain :) 35588: Part of the lang.text call. 35826: Bring up with [math]. I think it could be in either, not sure I have the itch to write a BigXxx replacement though. 36061: FIX. Seems simple enough - bug and patches. 36512: FIX. I think there's value for a .forName improvement. 3: Thoughts? Is it worth putting that inside the Enum code? 36839: WONTFIX: Covered by lang.text. 36873: FIX: Hooked to lang.text; but as a patch is provided I don't see any reason not to go with that. 36886: FIX: Seems valid. Tied to 2.2 vs 3.0 I think - backwards compat. 36915: WONTFIX: As I've no idea what's actually being said :) 36925: Status Gary? 37243: Time pain :) Thoughts? 37385: DOC. Don't see any problem in saying that apos; isn't included. 37499: WONTFIX. Point to JODA. 37690: FIX. Unit test offered. 38210: Thoughts? Is it undesired? 38401: Examine further. FIX if possible. 38569: FIX. Patch supplied - though might need improvement. 38800: Consider. Either FIX or point to JODA. 38912: No clue or itch on this one. Is it important for us to provide this? Is it of use to users, or just to other libraries who 50% of the time don't have a dependency on lang? 39254: Hesitant to offer up more lang.time functionality. Thoughts on this? 39315: Seems worthy of application. There, that was fun... :) Hen - 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]
[lang] next version etc
I want to do something fun...so how about a Lang release. First up; 2.2 or 3.0? It would be nice to have one without enum and the other deprecated bits. Second up; text? I think it needs to go into our next version regardless of version number, or we need to decide to drop it. Third, bugs. Here're my thoughts: 20015: WONTIFX? Gary's on making Entities public. Looks like a lump of work to do, is it likely to happen or should we just decide that Entities shouldn't be public? I don't recall user's being desperate to use this class. 26659: WONTFIX? Seems like too much in the way of date work - suggest JODA instead unless a patch is offered. 29692: Patch recently added. Consider and either apply or WONTFIX. 30082: WONTFIX. This is too specific an issue to be putting in Lang I believe. 30184: Consider for lang.text. 31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated, or is it simple enough and we can do it? 33102: FIX: On the one hand, it's pretty simple stuff, and we'd have to support the roll(..) method. On the other hand, user's like this stuff and it's not hard to add it, even if we overload with Calendar as well. 4 methods would be needed. 33401: FIX: it's a bit redundant, but I've no reason not to have these methods available. Any -1s? 33609: FIX. Javadoc needs improving. 33825: WONTFIX. Standard java.time question - is it valuable and simple, or should we just point to JODA? I'm going to go with WONTFIX as my default answer on time enhancements. 33889: Unsure. Could be a CharSet enhancement instead of just a camel case method. Thoughts? 33997: I think this is a useful method - just need to make sure the implementation is the best possible. 34284: FIX: NullPointer; test and fix. 34351: FIX: I don't see any reason not to try to write Albert's method. If not obvious when digging into it, then we can WONTFIX. 35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave the scope of 'simple' to my ignorant brain :) 35588: Part of the lang.text call. 35826: Bring up with [math]. I think it could be in either, not sure I have the itch to write a BigXxx replacement though. 36061: FIX. Seems simple enough - bug and patches. 36512: FIX. I think there's value for a .forName improvement. 3: Thoughts? Is it worth putting that inside the Enum code? 36839: WONTFIX: Covered by lang.text. 36873: FIX: Hooked to lang.text; but as a patch is provided I don't see any reason not to go with that. 36886: FIX: Seems valid. Tied to 2.2 vs 3.0 I think - backwards compat. 36915: WONTFIX: As I've no idea what's actually being said :) 36925: Status Gary? 37243: Time pain :) Thoughts? 37385: DOC. Don't see any problem in saying that apos; isn't included. 37499: WONTFIX. Point to JODA. 37690: FIX. Unit test offered. 38210: Thoughts? Is it undesired? 38401: Examine further. FIX if possible. 38569: FIX. Patch supplied - though might need improvement. 38800: Consider. Either FIX or point to JODA. 38912: No clue or itch on this one. Is it important for us to provide this? Is it of use to users, or just to other libraries who 50% of the time don't have a dependency on lang? 39254: Hesitant to offer up more lang.time functionality. Thoughts on this? 39315: Seems worthy of application. There, that was fun... :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
