commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsoftware.com>
Subject RE: [lang] next version etc
Date Sun, 16 Apr 2006 06:53:23 GMT
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> 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.

> 
> 36666: Thoughts? Is it worth putting that inside the Enum code?

It would be nice to be Java 5/6 friendly.

> 
> 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?

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).

> 
> 37243: Time pain :) Thoughts?

Does Joda-Time deal with this case?

> 
> 37385: DOC. Don't see any problem in saying that apos; isn't included.

Agreed, especially if the HTML spec is clear about it and we can point
to it.

> 
> 37499: WONTFIX. Point to JODA.

+1.

> 
> 37690: FIX. Unit test offered.

+1. I love when there's a unit test :)

> 
> 38210: Thoughts? Is it undesired?

I wonder if the XML spec has anything to say about that.

> 
> 38401: Examine further. FIX if possible.
> 
> 38569: FIX. Patch supplied - though might need improvement.
> 
> 38800: Consider. Either FIX or point to JODA.

IMO: Point to Joda-Time for now.

> 
> 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?

Dunno either. Seems nice. Is there an example where lang would eat its
own dog food and use it internally?

> 
> 39254: Hesitant to offer up more lang.time functionality. Thoughts on
this?
> 
> 39315: Seems worthy of application.
> 
> 
> ----
> 
> There, that was fun... :)

For a broad enough definition of "fun", yes. ;)

Gary

> 
> Hen
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message