Thanks for the explanation. I would, however, like to ask that this
change be reverted and a JIRA ticket be opened to evaluate this API
change. If real performance improvements can be demonstrated, we can
consider either exposing this private inner class or removing it.
Phil
These are the blockers on releasing 2.4:
LANG-362 - Niall/Matt, it looks like this is close to resolution and
'just' needs the ideas to be coded?
LANG-366 - MultiFormat becoming package scoped?
Hen
-
To unsubscribe, e-mail: [EM
On Aug 4, 2007 5:24 AM, Jeff Turner <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 04, 2007 at 02:03:54AM -0700, Henri Yandell wrote:
> > When it came up before, I thought there was a problem with enabling it
> > on an existing project? How do all the old issues look? Did they get
> > wiki'd?
>
> Old iss
Hi Phil:
By definition, when a class element is private, it cannot be seen from outside
the scope of the type that defines it. The compiler treats inner classes with
some special processing though.
Here is Olivier Thomann's explanation [1]:
"You get this warning as soon as you access a private
I would like to understand exactly what performance improvment results
from this change - i.e., see some microbenchmarks or other
explanation.
Making this protected adds it to the API that we are committing to
maintain and I do not want to do this unless it really helps
performance.
Phil
On 2/11
Perhaps we should do the following in trunk:
1) Generify (I know, it's not a word and it is funny that my spellchecker
suggests 'gentrify')) everything and keep backwards compatibility (this has
started)
2) Re-implement using Java 5 APIs where appropriate. For example, if we catch
and re-throw
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-tags-jaxme has an issue affecting its community
integration.
This
I still don't see the need to overhaul the entire API.
And I don't see the point why we shouldn't. Going from from java 1.4
-> 1.5 usually means a bit overhaul.
Perhaps usually, but for Commons IO?
The question was - why not? We are running around in circles here.
I see only a few isolated
On 2/11/08, Gary Gregory <[EMAIL PROTECTED]> wrote:
> In my mind, the point of io2 (as in, the next version plus the possible
> repackaging) is to allow us to (re)write io2 with Java 5 in mind. For
> example, you would never use a raw type in the API or internally. Any other
> non collection gen
In my mind, the point of io2 (as in, the next version plus the possible
repackaging) is to allow us to (re)write io2 with Java 5 in mind. For example,
you would never use a raw type in the API or internally. Any other non
collection generics APIs (array parameters) left would be for backward
co
Hi,
On Feb 11, 2008 2:38 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > I still don't see the need to overhaul the entire API.
>
> And I don't see the point why we shouldn't. Going from from java 1.4
> -> 1.5 usually means a bit overhaul.
Perhaps usually, but for Commons IO?
I see only a few i
On 2/11/08, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
> Phil Steitz a écrit :
> > The zips / tars are here:
> > http://people.apache.org/~psteitz/math-1.2-RC1/
> >
> > The site included in the binary distro is here:
> > http://people.apache.org/~psteitz/math-1.2-RC1/docs/
> >
> > Release notes:
> >
Phil Steitz a écrit :
The zips / tars are here:
http://people.apache.org/~psteitz/math-1.2-RC1/
The site included in the binary distro is here:
http://people.apache.org/~psteitz/math-1.2-RC1/docs/
Release notes:
http://people.apache.org/~psteitz/math-1.2-RC1/RELEASE-NOTES.txt
Shouldn't we say
On Feb 11, 2008 12:46 PM, Phil Steitz <[EMAIL PROTECTED]> wrote:
> On 2/11/08, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > The license-header.txt file is not included in the source distro -
> > which causes the checkstyle to fail when building from the src distro
> > - I've added that in (hope y
On 2/11/08, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> The license-header.txt file is not included in the source distro -
> which causes the checkstyle to fail when building from the src distro
> - I've added that in (hope you don't mind):
>
>http://svn.apache.org/viewvc?view=rev&revision=620
Additionally, nobody stops us from shipping an io compat library
which translates the
calls original io 1.x calls for io2. That one can be used as real
replacement of old 1.x
series, but offers the possibility to use as much Java 5 specifics
as possible in the
new API (varargs, new interface
The license-header.txt file is not included in the source distro -
which causes the checkstyle to fail when building from the src distro
- I've added that in (hope you don't mind):
http://svn.apache.org/viewvc?view=rev&revision=620449
Theres a couple of other files in trunk that are not in th
Hi,
On Feb 11, 2008 11:02 AM, Jörg Schaible
<[EMAIL PROTECTED]> wrote:
> Additionally, nobody stops us from shipping an io compat library which
> translates the
> calls original io 1.x calls for io2. That one can be used as real replacement
> of old 1.x
> series, but offers the possibility to us
Gary Gregory wrote:
> Ag, let's not have /both/ io and io2, this gets messy.
+1
Additionally, nobody stops us from shipping an io compat library which
translates the calls original io 1.x calls for io2. That one can be used as
real replacement of old 1.x series, but offers the possibility to us
19 matches
Mail list logo
