I think we should reduce the overloading and just accept Object. From
the runtime type, we can determine how to do further checks. Then, we
can nicely implement 1 args, 2, args, ... and finally var-args overloads.
Paul
On 11/26/2009 10:49 PM, James Carman wrote:
So, what you're concerned with
So, what you're concerned with is the first parameter (the "thing" we
want to check, which we do so by reflection)? Why do we need to
change its type?
On Thu, Nov 26, 2009 at 10:42 PM, Paul Benedict wrote:
> James,
>
> Yes. I want to also eliminate the static types of all the overloaded
> method
James,
Yes. I want to also eliminate the static types of all the overloaded
methods. We don't need a version for maps, one for char sets, one for
objects, one for collections, etc. We can do all those checks dynamically.
This was my point of my original email. What are your thoughts on it?
P
I understand that. My point is that if you can create two, overloaded
methods (which I've shown you can do), one with one single argument
and one with var-args, then you can avoid the Object[] instantiation
in the single-argument case.
On Thu, Nov 26, 2009 at 9:42 PM, Paul Benedict wrote:
> Jame
James,
The compiler instantiates the Object[] every time because that's how
the ellipsis notation is translated.
Paul
On Thu, Nov 26, 2009 at 7:38 PM, James Carman
wrote:
> Yes, but if the check passes, there's no need to create the Object[]
> for single-argument method invocations.
>
> On Thu,
On Thu, Nov 26, 2009 at 5:55 PM, Phil Steitz wrote:
> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
>> wrote:
>>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz wrote:
Paul Benedict wrote:
> Oops.. I meant minor version bumps ;-)
>
> On Thu, Nov 26, 20
Yes, but if the check passes, there's no need to create the Object[]
for single-argument method invocations.
On Thu, Nov 26, 2009 at 10:59 AM, Paul Benedict wrote:
> The purpose of var-args, at least from my vantage, is to produce
> detail messages that are used by java.lang.String.format.
>
> Pa
Paul Benedict wrote:
> Phil, if you feel strongly about your concerns of incompatibility,
> then I say keep the current groupId for 1.3, and move forward with
> 1.4/2.0 in the new groupId. This way people who continue to use the
> old groupId will never get hit unexpectedly.
+1
- Jörg
---
Paul Benedict wrote:
> I am +1 with Niall on two separate releases.
+1
Me too
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi Paul,
Paul Benedict wrote:
> Personally, I would not drop commons from the artiactId since it's a
> well-known prefix. Anyone who sees "commons" can reasonably guess it's
> from Apache Commons. Also let's not forget that in a file system,
> namespacing is still important. All file names still
Phil, if you feel strongly about your concerns of incompatibility,
then I say keep the current groupId for 1.3, and move forward with
1.4/2.0 in the new groupId. This way people who continue to use the
old groupId will never get hit unexpectedly.
Paul
On Thu, Nov 26, 2009 at 11:55 AM, Phil Steitz
Niall Pemberton wrote:
> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
> wrote:
>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz wrote:
>>> Paul Benedict wrote:
Oops.. I meant minor version bumps ;-)
On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict
wrote:
> Another opti
I am +1 with Niall on two separate releases.
On Thu, Nov 26, 2009 at 11:47 AM, Niall Pemberton
wrote:
> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
> wrote:
>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz wrote:
>>> Paul Benedict wrote:
Oops.. I meant minor version bumps ;-)
Personally, I would not drop commons from the artiactId since it's a
well-known prefix. Anyone who sees "commons" can reasonably guess it's
from Apache Commons. Also let's not forget that in a file system,
namespacing is still important. All file names still have to be unique
in WEB-INF/lib :-)
My
On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
wrote:
> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz wrote:
>> Paul Benedict wrote:
>>> Oops.. I meant minor version bumps ;-)
>>>
>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict
>>> wrote:
Another option to consider is splitting the ve
On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz wrote:
> Paul Benedict wrote:
>> Oops.. I meant minor version bumps ;-)
>>
>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict wrote:
>>> Another option to consider is splitting the version numbers such as:
>>>
>>> JDBC3 --> org.commons.apache.commons-d
Niall Pemberton wrote:
> On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz wrote:
>> Jörg Schaible wrote:
>>> Hi Phil,
>>>
>>> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>>>
Jörg Schaible wrote:
> Hi Phil,
>
> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>>>
Phil Steitz wrote at Donnerstag, 26. November 2009 17:39:
[snip]
> Did you miss that I cut out the "commons" from the artifactId?
Yes, I missed it :D
> That way we have commons-dbcp-1.3.jar and dbcp-1.3.jar in the wild.
> I guess I liked "dbcp" better than "commons-dbcp4" for the new
> artifa
On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz wrote:
> Jörg Schaible wrote:
>> Hi Phil,
>>
>> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>>
>>> Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
> Jörg Schaible wrote:
Paul Benedict wrote:
> Oops.. I meant minor version bumps ;-)
>
> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict wrote:
>> Another option to consider is splitting the version numbers such as:
>>
>> JDBC3 --> org.commons.apache.commons-dbcp-1.3.0
>> JDBC4 --> org.commons.apache.commons-dbcp-1.4.0
Jörg Schaible wrote:
> Hi Phil,
>
> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>
>> Jörg Schaible wrote:
>>> Hi Phil,
>>>
>>> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>>>
Jörg Schaible wrote:
>>> [snip]
>>>
> OK, but then we should really think about "drop
Oops.. I meant minor version bumps ;-)
On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict wrote:
> Another option to consider is splitting the version numbers such as:
>
> JDBC3 --> org.commons.apache.commons-dbcp-1.3.0
> JDBC4 --> org.commons.apache.commons-dbcp-1.4.0
>
> Unless you have expectatio
Another option to consider is splitting the version numbers such as:
JDBC3 --> org.commons.apache.commons-dbcp-1.3.0
JDBC4 --> org.commons.apache.commons-dbcp-1.4.0
Unless you have expectations to continue supporting JDBC3 in the next
major release, I would seriously suggest a version bump. The t
Mladen Turk wrote:
> On 11/26/2009 03:48 AM, Niall Pemberton wrote:
>>
>> I re-enabled the site and generated an issue tracking page and
>> re-deployed the site:
>>
>> http://commons.apache.org/sandbox/runtime/
>>
>> Niall
>>> Phil
>
> Thanks guys. Much appreciated!
>
> I suppose I can just copy
Hi Phil,
Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
> Jörg Schaible wrote:
>> Hi Phil,
>>
>> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>>
>>> Jörg Schaible wrote:
>>
>> [snip]
>>
OK, but then we should really think about "drop-in replacement" or not.
B
Jörg Schaible wrote:
> Hi Phil,
>
> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>
>> Jörg Schaible wrote:
>
> [snip]
>
>>> OK, but then we should really think about "drop-in replacement" or not.
>>> Basically we say that dbcp 1.3 with JDBC4 will not be backward
>>> compatible. The
Grzegorz Słowikowski wrote:
> 2. I agree with Jorg that the JDBC3 version should be the natural
> continuation of previous
> versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
> I know that Tomcat developers are waiting for new version of
> commons-dbcp because of some leaks
The purpose of var-args, at least from my vantage, is to produce
detail messages that are used by java.lang.String.format.
Paul
On Thu, Nov 26, 2009 at 7:11 AM, James Carman
wrote:
> I just wrote a class that included...
>
> public static T someMethod(T val)
> {
> System.out.printl
Hi Phil,
Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
> Jörg Schaible wrote:
[snip]
>> OK, but then we should really think about "drop-in replacement" or not.
>> Basically we say that dbcp 1.3 with JDBC4 will not be backward
>> compatible. Then why don't we use the new artifactId f
Jörg Schaible wrote:
> Hi Paul,
>
> Paul Benedict wrote at Donnerstag, 26. November 2009 05:03:
>
>> When I was patching Hibernate, they needed different sources because
>> of JDBC3/4 incompatibility. It just wasn't possible to compile for
>> both dependencies.
>>
>> I just checked with Brett Por
I just wrote a class that included...
public static T someMethod(T val)
{
System.out.println("Single value method!");
return val;
}
public static T[] someMethod(T... values)
{
System.out.println("Multi-value method.");
return values;
}
Jörg Schaible wrote:
Hi Grzegorz,
Grzegorz Słowikowski wrote at Donnerstag, 26. November 2009 10:59:
[snip]
Hi
I want to add something from myself, I think I'm experienced Maven user.
1. As Paul said, when you have two different sources you should not try
to use classifiers
(I think te
On 26/11/2009, Phil Steitz wrote:
> sebb wrote:
> > I've updated the Commons Logging version, because that's obviously
> sensible.
> >
> > The Maven dependency checker suggests the following updates:
> >
> > org.apache.geronimo.modules:geronimo-transaction ... 1.2-beta -> 2.1.4
> > (test sc
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[] n
Hi Grzegorz,
Grzegorz Słowikowski wrote at Donnerstag, 26. November 2009 10:59:
[snip]
> Hi
>
> I want to add something from myself, I think I'm experienced Maven user.
>
> 1. As Paul said, when you have two different sources you should not try
> to use classifiers
> (I think technically it co
Phil Steitz wrote:
Paul Benedict wrote:
When I was patching Hibernate, they needed different sources because
of JDBC3/4 incompatibility. It just wasn't possible to compile for
both dependencies.
I just checked with Brett Porter of Maven. He says that if the sources
are identical, you can u
What are the pros and cons?
On Wed, Nov 25, 2009 at 9:16 PM, Paul Benedict wrote:
> If we want to implement LANG-508 (Validate: add message parameter
> construction via elllipsis notation to speed up processing), I am
> really concerned with the many overloaded versions of #validIndex()
> and #no
+1 to removing the overloaded variants now that autoboxing is available.
Hen
On Tue, Nov 24, 2009 at 4:22 PM, Paul Benedict wrote:
> I understand why this method exists:
> public static void isTrue(boolean expression, String message, Object value)
>
> But why do these variants exist?
> public st
On 11/26/2009 03:48 AM, Niall Pemberton wrote:
I re-enabled the site and generated an issue tracking page and
re-deployed the site:
http://commons.apache.org/sandbox/runtime/
Niall
Phil
Thanks guys. Much appreciated!
I suppose I can just copy the ant produced javadocs to
target/apidocs bef
Hi Paul,
Paul Benedict wrote at Donnerstag, 26. November 2009 05:03:
> When I was patching Hibernate, they needed different sources because
> of JDBC3/4 incompatibility. It just wasn't possible to compile for
> both dependencies.
>
> I just checked with Brett Porter of Maven. He says that if the
40 matches
Mail list logo
