On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
Sebb, someone needs to check to see if any collections in
[collections] could implement the new interfaces added in Java 6 -
NavigableSet, NavigableMap and so on.
Stephen
On 24 June 2012 12:25, sebb seb...@gmail.com wrote:
://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Jul 4, 2012 at 9:59 AM, Jörg Schaible
joerg.schai...@scalaris.com wrote:
Stephen Colebourne wrote:
On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
Sebb, someone needs to check to see if any collections
On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:42 AM, James Carman
ja...@carmanconsulting.com wrote:
On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com wrote:
Are these specific examples not the words you would actually use were
On 4 December 2012 23:05, Gary Gregory garydgreg...@gmail.com wrote:
I like the name weaver.
Does it make sense to allow different libs to be plugged in? BCEL,
ASM... Or do do we have to pick one?
Based on what I see in various projects, ASM won, BCEL lost. Main
problem tends to be different
FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both
written with static imports in mind. Moreover, with support for static
methods in interfaces being added, this is likely to increase as a
pattern. Those facts may or may not affect decisions in commons.
Stephen
On 4 February
On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote:
It seems to me that the Encoder/Decoder interfaces are screaming out to be
generified, and the current sub-interfaces should be removed unless there's
a compelling reason for them e.g. if they add extra methods. It is
On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com wrote:
Specifically for StringUtils, should we have a SunStringUtils? This would
let you know that you are depending on com.sun code.
I really don't like that idea!
Generally, it is non-Sun JVMs including Android that are the
Oracle advise using AtomicReference for any threaded cases, and we
have MutableObject for other cases. I'm very dubious about adding a
second version of the same class.
Stephen
Limited mobile access
On 11/09/2011, Henri Yandell (JIRA) j...@apache.org wrote:
[
On 31 December 2011 08:45, Henri Yandell flame...@gmail.com wrote:
Three changes of interest. Two are the removal of final on public
methods. The other is the addition of Serializable to StrBuilder.
As described above, those are source and binary compatible.
Stephen
Which is the worry? And
On 4 February 2012 05:38, ma...@nimp.co.uk ma...@nimp.co.uk wrote:
Apache Commons Lang seems to be the right place for that kind of utility
class, however, my utility class is coded in Scala, is that ok ?
Not in my opinion No.
I have no problem with a Scala-only commons component, but I think
I would see this as more like caching functionality than collections
functionality. And there are plenty of other caching libraries.
Stephen
On 13 December 2010 03:27, Balazs Attila-Mihaly (Cd-MaN)
x_at_y_o...@yahoo.com wrote:
Hello everybody.
I would like to know if there would be any
I would recommend against this for [lang].
[lang] is a low-level project intended to have no framework or
religious aspects, just simple relatively non-controversial elements
that assist the basic Java packages. A maths parser, however useful,
isn't that closely related IMO.
Stephen
On 5
On 27 January 2011 08:45, Jörg Schaible joerg.schai...@scalaris.com wrote:
In the light of LANG-577, I wondered if the mutable package is still
necessary looking at the concurrent stuff of the JDK. I tried once to start
a discussion about it
Traditionally, many commons projects has taken no position on the
correct way to instantiate objects, whether via constructor or bean
methods. This was to allow construction from tools such as Velocity.
It is also still easier to construct using Spring via bean methods
rather than the constructor.
for me and we can
wait for additional feedback.
Jacopo
On Jan 29, 2011, at 1:16 PM, Stephen Colebourne wrote:
Traditionally, many commons projects has taken no position on the
correct way to instantiate objects, whether via constructor or bean
methods. This was to allow construction from
It used to be dubious practice, but now that IDEs can provide an error
for this case, it is IMO back to being good practice (in that its easy
to read and understand, and follows the Sun conventions)
Stephen
On 30 January 2011 13:22, Mikkel Meyer Andersen m...@mikl.dk wrote:
Hi,
I noticed that
On 30 January 2011 15:11, sebb seb...@gmail.com wrote:
On 30 January 2011 09:09, Stephen Colebourne scolebou...@joda.org wrote:
The modern standard for altering immutable classes was laid down by Joda-Time
strategy = strategy.withCommentStart(#);
Not sure I undestand that.
An immutable
I have no philosophical problem with adding to an enum in a later
release, its designed to be compatible (don't persist the ordinal).
However, I'm unconvinced that an enum is the right solution here. I
should probably study the details, but if Android is broken perhaps
thats just how it is.
I can give some feedback based on JSR-310.
I have a small hierarchy of exceptions that attempts to capture some
key problems that may occur. The problem I found was that as I
refactored code, the exceptions listed in Javadoc quickly became
inaccurate. As a result, I've started converting many
On 1 February 2011 13:52, luc.maison...@free.fr wrote:
I have a small hierarchy of exceptions that attempts to capture some
key problems that may occur. The problem I found was that as I
refactored code, the exceptions listed in Javadoc quickly became
inaccurate. As a result, I've started
On 2 February 2011 00:12, Gilles Sadowski gil...@harfang.homelinux.org wrote:
Here is a probably too simple example:
com.example defines IOException
com.example.input uses IOException
com.example.output uses IOException
Well, I don't see that as obviously better than storing all exceptions
On 2 February 2011 06:04, Phil Steitz phil.ste...@gmail.com wrote:
What we report back to the application using [math] is that one of
the following kinds of bad things has happened
a) they have violated preconditions - they get
MathIllegalArgumentException (same semantics as anywhere else)
On 2 February 2011 09:23, Luc Maisonobe luc.maison...@free.fr wrote:
It seems the thread asking for help on the exception API design is going
to be fruitful, and it starts well with interesting ideas. I guess some
of these ideas will change again our view and we will converge
(hopefully not
Apache is a place where community matters more than code. Right now,
the community dynamics within [math] are clearly difficult.
I ask ALL those involved to step back for the weekend and to not post
on the topic of [math] until Monday.
In that time, I ask ALL involved to reflect on how the
Based on what I know of OGNL, it is/was reasonably well used. Trying
to merge it into another project doesn't help those existing users.
The question is what are the author(s) of OGNL looking for? A home for
maintainance? The Apache brand? To reinvigorate it? The latter fits
with a merger into
The recognised standard in the JDK is NPE on invalid null input.
I have never overly liked this, but conform to it for JSR-310/ThreeTen.
I use IAE in other projects which are higher up the stack. Whether
[math] is low or high level may determine the choice you make.
Personally, I don't use
I consider it sufficient (preferable) to do the following:
@param foo the foo, not null
Where the , not null implies NPE when a null is passed in (document
once in the overview javadoc if you feel necessary). This approach is
easier to transfer to a @NotNull annotation in the future (or the
To be a TLP, you need a bare minimum of 3 active committers,
preferably 6. And you'd need to go via the incubator. Commons is an
easier fit as the committers can be shared with other commons
components, but that still depends on existing commons committers
saying that they'd be willing to help
I'm not overly enthused about some of the changes, but since I've not
been paying attention its difficult for me to vote/block. Anyway here
is my review:
ArrayUtils.hashCode() has been removed, but it had different
functionality to Arrays.hashCode wrt nested arrays.
Object[] arrayA = new
feedback from anyone would be excellent.
Hen
On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne scolebou...@joda.org
wrote:
I'm not overly enthused about some of the changes, but since I've not
been paying attention its difficult for me to vote/block. Anyway here
is my review
On 3 March 2011 18:56, Matt Benson gudnabr...@gmail.com wrote:
[SNIP]
I don't love the new Pair class. We have an interface based version
here at OpenGamma to allow primitive implementations for performance.
I might be able to get our code released if there was interest.
Providing interfaces
I now have authoristion from OpenGamma to discuss adding a Pair class
to [lang] based on our internal classes. If necessary a CCLA can be
signed, although since we are not necessarily importing the OpenGamma
classes as is and I'd be writing code in [lang3] with my Apache hat
on, the CCLA might not
On 4 March 2011 06:16, Henri Yandell flame...@gmail.com wrote:
Going through each.
ArrayUtils.hashCode() has been removed, but it had different
functionality to Arrays.hashCode wrt nested arrays.
DONE
I don't love the new Pair class.
New thread.
ArrayUtils.toArray() javadoc has example
As there is no need to be public, I'm not fussed that they are int. An
enum just increase the jar file size for little benefit when you have
private values.
Stephen
On 4 March 2011 17:15, sebb seb...@gmail.com wrote:
On 4 March 2011 13:31, scolebou...@apache.org wrote:
Author: scolebourne
On 4 March 2011 17:15, sebb seb...@gmail.com wrote:
On 4 March 2011 13:30, scolebou...@apache.org wrote:
Log:
Document mutability of UTC constant, which isn't ideal
AFAICT, it's not used within Lang3 - so why don't we just delete it ?
Does it really offer much benefit, given the drawback
On 4 March 2011 18:35, Matt Benson gudnabr...@gmail.com wrote:
I agree that it would be nice to do whatever we're going to do
quickly, and ship with *something*. On the other hand, I don't want
to ship the existing class without consensus on design, only to give
ourselves (and users)
On 18 March 2011 03:56, Henri Yandell flame...@gmail.com wrote:
Something occurred to me today. We're moving from String to
CharSequence in the API, but not thinking of the use case.
If I call:
StringUtils.toLowerCase(stringBuffer);
I'd argue that the likely style would be to modify the
How about no @Version tag or $Id ?
Stephen
On 5 April 2011 09:16, Simone Tripodi simonetrip...@apache.org wrote:
Hi all guys,
after the @author tag, I'm here to ask to clarify *to me* how @version
shall be used in Commons :)
I saw various usage across components:
- In [digester] we just use
On 5 April 2011 10:49, sebb seb...@gmail.com wrote:
On 5 April 2011 10:31, Christian Grobmeier grobme...@gmail.com wrote:
I'd tend to remove that package and use commons-logging in the
traditional way, WDYT?
Probably we should get rid of commons-logging to. Its pretty outdated,
slf4j is more
I'd agree with an alpha area, but I don't agree with releasing it.
[lang] is too core to other projects to be doing things like that IMO.
Stephen
On 7 April 2011 07:35, Henri Yandell flame...@gmail.com wrote:
I've been pondering the tension between stability and innovation.
Once 3.0 is out
On 7 April 2011 23:33, Matt Benson gudnabr...@gmail.com wrote:
This is what the javadoc nowadays does by default ...
Yes, but personally I like them as a good reminder when looking though the
code.
(Or as nothing more to add).
I feel more comfortable seeing them as well (I'm almost
On 11 April 2011 16:14, Phil Steitz phil.ste...@gmail.com wrote:
The point of keeping a working Ant build is for users who want to
build from source and are not Maven users (many, many users in the
real world).
I don't believe there are many of those users. Most just pickup the jar.
I oppose
-1
The Pair class hashCode method is incompatible with Map.Entry.
(I haven't checked other parts of the release yet)
Stephen
On 9 April 2011 06:06, Henri Yandell flame...@gmail.com wrote:
Lang is ready to consider 3.0 release again.
RC2 is available here:
I fixed the Map.Entry equals/hashCode compliance.
I shortened the toString form to omit the class name, as it is
superfluous - (A,B)
Out library uses square brackets, but I can live with round.
I don't believe that requiring every pair to carry around a format
string is viable. These must be
On 12 April 2011 17:10, Matt Benson gudnabr...@gmail.com wrote:
On Tue, Apr 12, 2011 at 10:20 AM, Stephen Colebourne
scolebou...@joda.org wrote:
The [collections] KeyValue class was a mistake. [lang] Pair is a
better more general concept.
The only thing I'd consider with [lang] Pair now
Basic work with URL and URI is [io]
Stephen
On 12 April 2011 20:04, Gary Gregory garydgreg...@gmail.com wrote:
Hi All:
I am looking for a home for the code below. It seems to fit nicely in [io]
IOUtils because it reuses IOUtils. Because it is about URLs and URI it feels
like it should be in
On 20/04/2011, Matt Benson gudnabr...@gmail.com wrote:
On Wed, Apr 20, 2011 at 1:10 AM, Henri Yandell flame...@gmail.com wrote:
Is Pair now good (for a value of consensually agreed good)?
Good enough, although Stephen noted in ImmutablePair's javadoc that
being non-final, a subclass could add
I cannot do any checking for at least 48 hours due to current holiday
absence of all decent net.
Stephen
On 29 April 2011 20:58, Henri Yandell flame...@gmail.com wrote:
[Repeating now that I've rebuilt the artifacts using Java 1.5]
=
Lang is ready to consider 3.0 release again.
RC3 is
(review now back from holiday)
-1
I'm unhappy with the change in FastDateFormat from new
GregorianCalendar() to Calendar.getInstance(). This will pick up
alternate calendar systems based on the default locale, and probably
mess up the rest of the code which I expect relies on it being
gregorian.
So
While I can see the benefits of toString(String format), I'm
struggling to understand what formatTo(...) gains Pair.
I've added a test (in svn), and removed the Formattable interface from
Pair (not in svn), and get the same output, so implementing
Formattable appears to be pointless to
On 4 May 2011 13:10, sebb seb...@gmail.com wrote:
/**
- * p{@link FormattableUtils} instances should NOT be constructed in
+ * p{@code FormattableUtils} instances should NOT be constructed in
What's wrong with @link here?
In general, it is not advisable to use @link in the first
On 4 May 2011 13:47, Matt Benson gudnabr...@gmail.com wrote:
At some point Hen mentioned the idea of a PairFormat class. I don't
think this is a bad idea, but the parsing capabilities of such a beast
would be minimal to nonexistent, and it still doesn't seem that it
would be configurable in a
On 4 May 2011 16:23, Gary Gregory garydgreg...@gmail.com wrote:
Ah, well, it would make it easier to port my current code: create subclasses
with the desired formatting and replace package names. Each subclass would
call toString(format) and that's it. The alternative is to either call
On 4 May 2011 17:58, Gary Gregory garydgreg...@gmail.com wrote:
I think we still have naming problems with the Pair class reflected in this
Javadoc fragment:
* @param L the first element type
* @param R the second element type
Either we call them L left and R right, or we call them F
On 18 May 2011 09:11, Luc Maisonobe luc.maison...@free.fr wrote:
Should I replace with one-d, two-d and three-d ?
Of course this should read: one_d, two_d and three_d ...
In the variety of Java source I've seen, multiple words are scrunched
together, giving oned, twod, threed.
Stephen
This issue about what immutable means wrt final on the class has
bounced around a few threads.
In my view, immutable has a specific meaning, whereby the object is
unequivically safe to use and share between threads. To do so, there
are certain rules. One that is disputed is whether the class must
On 18 May 2011 17:46, Matt Benson gudnabr...@gmail.com wrote:
On Wed, May 18, 2011 at 11:32 AM, Gary Gregory garydgreg...@gmail.com wrote:
Why doesn't a Range does extend Pair? It's pretty clear (to me at least)
that a range is a pair of values.
Because the Pair is in our tuple package, it
On 18 May 2011 17:58, Matt Benson gudnabr...@gmail.com wrote:
On Wed, May 18, 2011 at 11:47 AM, Stephen Colebourne
scolebou...@joda.org wrote:
This issue about what immutable means wrt final on the class has
bounced around a few threads.
In my view, immutable has a specific meaning, whereby
On 18 May 2011 18:09, Stephen Colebourne scolebou...@joda.org wrote:
See the EvilFoo example above. Any ability to subclass, even with safe
methods, means its not completely thread-safe.
More info:
StringBuilder evilBuf = new StringBuilder();
EvilFoo evilFoo = new EvilFoo(evilBuf);
doStuff
The discussion threads ended with both th notion that Formattable was
adding no value and final was best added for safety. I checked before
making the change.
Feel free to propse alternatives...
Stephen
On 25 May 2011 15:48, Matt Benson gudnabr...@gmail.com wrote:
Way to make unilateral
I've used scannotation before, which is reasonably well known I
believe, but could probably be improved on. I think with multiple
versions at Apache, it is a perfect concept for commons. I would check
out [discovery] first to see if that has a similar goal.
I'd set it up separately to [lang]
On 3 July 2011 22:04, Gary Gregory garydgreg...@gmail.com wrote:
* Email thread - what else should implement Formattable?
I would look at this differently to get 3.0 out the door: Let's make
sure we do not make anything Formattable that we might have to back
out later.
Currently, nothing
On 3 July 2011 19:07, Gary Gregory garydgreg...@gmail.com wrote:
http://markmail.org/message/ml7efpvqezysvs2p?q=Validate+list:org%2Eapache%2Ecommons%2Edev/
Since this has gone quiet, I was going to follow through and rename the
validate* method (which are all @since 3.0) to check*. Someone
On 2 July 2011 15:28, Jörg Schaible joerg.schai...@gmx.de wrote:
Can somebody else give the ContextedException stuff a review? I used in the
meanwhile a copy of it in a project, but a method name is bugging me.
The structure looks reasonable to me.
While you could rename replaceValue() to
On 4 July 2011 23:13, Jörg Schaible joerg.schai...@gmx.de wrote:
Sorry, why is setValue more vague - isn't it the other way round?
As a method name, replace is explicit, set slightly less so. Either
work here, so if you want to change it go ahead.
More generally, I now think the index suffix
On 6 July 2011 09:52, Jörg Schaible joerg.schai...@scalaris.com wrote:
I can traverse now the set of keys to get this list when it is internally
implemented with a LinkedHashMap. Remember, one important element of a
contexted exception is a more informational and structured message. In the
On 6 July 2011 21:45, Jörg Schaible joerg.schai...@gmx.de wrote:
Since the ExceptionContext is especially designed for an exception mix-in, I
wonder if we better use more qualifying names for this use case:
interface ExceptionContext {
addContextValue(...);
setContextValue(...);
On 7 July 2011 00:57, Jörg Schaible joerg.schai...@gmx.de wrote:
Proposed changes done. Please review, especially also Javadoc as I'm a non-
native speaker.
Done. I think you could remove the add/set methods taking a Pair. The
other add/set methods taking two arguments is sufficient, and I
On 7 July 2011 11:48, Jörg Schaible joerg.schai...@scalaris.com wrote:
One last opinion about the output? Originally we had e.g.:
[Handler = PersonConverter]
[Current Element = Person]
[Role = COO]
[Handler[1] = CompanyConverter]
[Current Element[1] = Company]
The current output does
On 12 July 2011 18:56, Jörg Schaible joerg.schai...@gmx.de wrote:
1/ FastDateFormat
The date format yyy yy y is formatted with JDK 7 as 2003 2003 03
2003 instead of 2003 03 03 03. So, should FastDateFormat follow the JDK
in any case and adjust its result according the runtime?
I'm willing to vote +1
Although I haven't checked every recent change, but AFAIK recent
changes have been minor and my previous issues are resolved.
I would note that the svn as of right now does not compile, due to an
IOUtils reference that shouldn't be there.
Stephen
On 16 July 2011 01:18,
StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
been added as a dependency, then it needs to be removed, even for
testing)
Stephen
On 18 July 2011 23:41, Gary Gregory garydgreg...@gmail.com wrote:
On Jul 18, 2011, at 18:36, Stephen Colebourne scolebou...@joda.org wrote
I think from the quiet reply its apparent that [collections] is pretty
quiet these days. I think [collections] development must focus first
on a release of a Java 5 version of what it has, rather than new code.
Stephen
On 14 July 2011 01:19, Simone Tripodi simonetrip...@apache.org wrote:
Hi all
it is OK
to
also depend on [io] for testing as well. CP'ing code is lame in this
case
IMO.
Gary
Hen
On Mon, Jul 18, 2011 at 3:50 PM, Stephen Colebourne
scolebou...@joda.org wrote:
StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
been added
On 19 July 2011 16:32, Gary Gregory garydgreg...@gmail.com wrote:
When you say Personally, I'm OK with using JUnit and mocking utilities as
they are both specifically intended for testing. are you thinking that
there are alternative solutions?. IMO, JUnit is a requirement, not something
we
You will need both versions of commons-lang, the new and the old.
Stephen
On 27 July 2011 11:17, Rohan Kadam roha...@cybage.com wrote:
Hi All,
We have upgraded our common lang jar to 3.0 version. We have replaced package
name lang to lang3. But since it has already been mentioned on apache
My thought is that there might be some java.util.logging helpers that
could be written, and perhaps they might go in [lang] if there are 5
or fewer classes.
I assume that slf4j and log4j have their own j.u.logging connections,
so that end is dealt with.
The time of [logging] has probably passed.
I think that a key mistake was trying to do both generics and
refactoring. I'd suggest that quite a few users would simply like a
generified [collections] 3.5 that is fully backwards compatible (as
the JDK was) and with no refactoring.
Now, some of the API cannot be generified correctly, so for
of generics-RnD.
Hen
On Wed, Aug 3, 2011 at 8:23 AM, Stephen Colebourne scolebou...@joda.org
wrote:
I think that a key mistake was trying to do both generics and
refactoring. I'd suggest that quite a few users would simply like a
generified [collections] 3.5 that is fully backwards
one method and then release [to take it to extremes].
Hen
On Fri, Aug 5, 2011 at 12:33 AM, Stephen Colebourne
scolebou...@joda.org wrote:
I agree with this. And I think it serves users better, many of whom
have migrated to Google Guava.
1) New bug fix only release, JDK 1.4 compatible
2) New
I've just noticed this thread.
I'd like to ask those involved to consider if they can find a route
where the package name and group do *not* change.
- Changing to JDK 5 does not require a a package name change (generics
are backward compatible if the erased signatures don't change).
- Removing
On 12 August 2011 11:19, sebb seb...@gmail.com wrote:
- Removing deprecated methods does not require a package name change
How so?
If there are any external references to them in an application that
cannot be removed, then both old and new jars will need to be
deployed.
Which cannot be
On 12 August 2011 14:54, sebb seb...@gmail.com wrote:
We have lang3 and digester3 under our belts now with new packages. Are
we going to change policy again? I hope not. We sure spent a lot of
time on this and thought we made a sane decision as a community.
Joda-time is its own world can do
The new ObjectUtils.firstNonNull() method checked for both null and the
ObjectUtils.NULL constant object. Since that was the only method with
that behaviour I removed the check for the NULL object.
The question is broader than that... do we want all null checks in
ObjectUtils or [lang] to
Niall Pemberton wrote:
[X] +1 Yes lets sponsor it
[ ] -1 No because...
[X] +1 Use the Commons mailing lists
[ ] -1 Bad idea because...
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
Henri Yandell wrote:
On Thu, Nov 19, 2009 at 9:24 AM, Paul Benedict pbened...@apache.org wrote:
On Thu, Nov 19, 2009 at 1:39 AM, Henri Yandell flame...@gmail.com wrote:
Your argument being that the JDK and others do NPE when null? i.e. NPE
= IAE(null)?
Yes. Some things to note:
* The JDK
support.
Paul
On Tue, Nov 17, 2009 at 3:33 AM, Stephen Colebourne
scolebou...@btopenworld.com wrote:
The new ObjectUtils.firstNonNull() method checked for both null and the
ObjectUtils.NULL constant object. Since that was the only method with that
behaviour I removed the check for the NULL object
I'm unconvinced by this change overall. It feels like a bit of a
diversion from the original purpose of the class. I think it
complicates greatly what should be a really simple, no-brainer, class.
I could live with a one arg addition, but want to avoid varargs and primitives:
public static T T[]
Paul Benedict wrote:
I want to rename isTrue to validateArgument (which throws
IllegalArgumentException); then also introduce validateState (which
throws IllegalStateException).
We have this in a work version of this class, I'm not sure that it
doesn't confuse the purpose of the class. As
Once upon a time, there was a commons sandbox project that held all
sorts of small interfaces just like this one. It was called commons-pattern.
It didn't suceed, because these interfaces really need to be provided by
the JDK and implemented by all the JDK classes to be successful. Beyond
There are many good points in this thread. My input is to try and
outline where I have seen te boundaries.
[lang] vs [math] - [lang] doesn't require a maths degree. [math] does.
[lang] vs [functor] - [lang] doesn't require FP knowledge or religion.
[functor] does.
[io] - handles Stream,
Divest? I object to removing Fraction from [lang], as its a very core
concept tat is missing from the JDK. And thee are many users who would
just want Fraction and none of the rest of the [math] library.
The [lang] maths package is fo non-mathematicians. The [math] library is
for serious
I do fear that this discussion may be over-thinking. Most users will, I
believe, be working with String and want a String back. Many of these
calls may be in time-critical code, so the conversion from a
CharSequence (even though trivial) may be a small overhead.
We also have StrBuilder for
On 26 August 2010 11:29, James Carman ja...@carmanconsulting.com wrote:
This way, you could do:
Person p = SerializableUtils.deserialize(bytes);
No casting! Now, if the bytes don't represent a Person object, then
you'll get a ClassCastException, but that's exactly the same thing
that would
On 6 October 2010 11:49, Niall Pemberton niall.pember...@gmail.com wrote:
The original plan for 2.0 was thinking it would be *incompatible* and
hence the major version changed - I guess it mainly stuck from that
starting point:
http://markmail.org/message/46dos5wjdfhcr5nr
Sebb did bring
I don't think comons lang has a routine for converting a standard
wildcard string (with * and ?) to a regex.
Here is a first suggestion, although I'm sure it can be improved.
public Pattern createPattern(String text) {
StringTokenizer tkn = new StringTokenizer(text, ?*, true);
, 2010 at 9:06 AM, Stephen Colebourne scolebou...@joda.org
wrote:
I don't think comons lang has a routine for converting a standard
wildcard string (with * and ?) to a regex.
Here is a first suggestion, although I'm sure it can be improved.
public Pattern createPattern(String text
rather than Lang.
Also, filename globbing is not consistent across OSes.
On 8 October 2010 15:32, Stephen Colebourne scolebou...@joda.org wrote:
Human users enter wildcards * and ? (because regex is too complex). In
my case, I'm passing it to MongoDB, which needs regex.
Stephen
On 8
On 12 October 2010 00:29, Niall Pemberton niall.pember...@gmail.com wrote:
Part of me thinks its a bit late in the day to raise this when its
been in svn for 2+ years. But then again, if more people agree with
Gary then I can cancel the release and rename them (I would probably
opt for
Essentially, a more valid version is in [configuration] IIRC, but this
one remained because people didn't want to load another jar just for
this simple functaionlity. All IIRC.
Stephen
On 20 October 2010 16:32, Matt Benson gudnabr...@gmail.com wrote:
On Oct 19, 2010, at 9:29 PM, sebb wrote:
1 - 100 of 214 matches
Mail list logo
