Hi Thomas. The only issue I see with introducing a "equalsOneOf" is that it
setups the pondering for other uses... greater than one of, less than one
of, and whatever of one of. With that said, I would rather see the proposed
method accept a function/visitor callback to determine the check. If you'
e JEP is
> linked to https://bugs.openjdk.java.net/browse/JDK-8061493 but how do you
> get an account on that?
>
> I recall hearing a preso on how the comments for Java were locked down for
> fear of too much feedback... or something.
>
> Gary
>
> On Thu, Jul 14, 2016
If this issue has been raised in the past, my apologies. I did a search for
"Verona" in the mail archives here and didn't see any hit besides Oracle's
own notification [1]. That was the only hit.
In JDK 9, the version string is changing from 1.0.X to bigger numbers like
9.0.0 [2]. Code that has as
Odd way to use versions, imo. Sounds like "discussion" and "review patch"
and "patch needed" tags would be the better tool.
Cheers,
Paul
On Wed, Apr 15, 2015 at 3:18 PM, Duncan Jones wrote:
> Hi folks,
>
> Currently the "Review Patch" fix version seems to be applied whenever
> code has been su
If you are bumping the minimum java version, this should be really 1.5.
Technically the bump won't be a true drop in for someone on 1.4 but who
is on 1.4 anymore? Your call.
On Jan 5, 2015 10:11 AM, "Benedikt Ritter" wrote:
>
>
> Send from my mobile device
>
> > Am 05.01.2015 um 16:34 schrieb
;
> On Fri, Dec 5, 2014 at 6:33 AM, Paul Benedict
> wrote:
>
> > Devang, you can immediately start by going to JIRA [1] and finding some
> > "low hanging fruit" that interests you. Look for an easy ticket and
> submit
> > a patch. This will start y
Devang, you can immediately start by going to JIRA [1] and finding some
"low hanging fruit" that interests you. Look for an easy ticket and submit
a patch. This will start your code contribution to the community.
[1] https://issues.apache.org/jira/browse/COLLECTIONS
Cheers,
Paul
On Thu, Dec 4,
Whenever I've felt like there is "too much work and too little people to do
it", I remind myself Apache is not a job (unless someone is paying you for
your work), but a volunteer organization. Everyone does what he/she wants
to do... and if it's not personally fun or interesting, those people will
Even I must admit that the use of "final" here is more of a formality than
a necessity. I believe that's why it's been called a "stylistic" commit.
The compiler isn't driving you to use it for what you need to accomplish,
and there is no pressing technical need to use it aside from it enforces
some
I do not not like "final" used this way. Unless you have a constant or a
language mandating "final" for a particular usage, this is unnecessary
noise to the code.
Cheers,
Paul
On Thu, Oct 23, 2014 at 2:34 PM, Oliver Heger
wrote:
> There was no reaction on my comment so far.
>
> I am tempted to
You are not including duplicate artifacts, they are totally distinct.
ebb" a écrit :
> >
> > On 17 October 2014 21:57, Paul Benedict wrote:
> > > FWIW, I have found no difficulty moving code from lang2 to lang3. It's
> a
> > > breeze. I did a wholesale replacement of the package name and then
> fixed
> > > any com
FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
breeze. I did a wholesale replacement of the package name and then fixed
any compiler problems due to API differences.
Cheers,
Paul
On Fri, Oct 17, 2014 at 3:51 PM, sebb wrote:
> On 17 October 2014 21:37, Romain Manni-Buc
I think some people find it unseemly to have both commons 2 and 3 jars in
the classpath. It's OK. This is how a project can make major improvements
and not affect previous clients -- because the package names are different.
The two can live together just fine.
Cheers,
Paul
On Fri, Oct 17, 2014 a
o
> hasn't tried git, to add a small feature, add some comments, or add a unit
> test, we'll learn enough. The project lead can look at the impact on the
> release process, and report any findings. At least at that point, we'll
> have learned enough from the process to
Is there an itch to scratch (need) by moving to git as opposed to just
continue using svn?
Cheers,
Paul
On Tue, Sep 9, 2014 at 9:49 AM, sebb wrote:
> On 9 September 2014 15:32, Gary Gregory wrote:
> > On Tue, Sep 9, 2014 at 9:17 AM, sebb wrote:
> >
> >> On 9 September 2014 14:10, Gary Gregor
Gary, 1.2 of what?
Cheers,
Paul
On Mon, Jul 7, 2014 at 3:38 PM, Gary Gregory wrote:
> Note that 1.2 is about to be released.
>
> Gary
>
> Original message From: brit...@apache.org
> Date:07/07/2014 15:36 (GMT-05:00) To:
> comm...@commons.apache.org Subject: svn commit: r160
For anyone here in Commons who likes API designing, take a look at this new
proposal coming down the pike. The proposal helps simplify/specify how APIs
declare their type parameters and the impact (better, hopefully) for
clients of those APIs.
https://bugs.openjdk.java.net/browse/JDK-8043488
Make
ttle because the
march is going the other direction.
Paul
Cheers,
Paul
On Tue, May 6, 2014 at 6:27 PM, sebb wrote:
> On 6 May 2014 22:54, Paul Benedict wrote:
> > This is not a matter of law. If Oracle/Sun set a direction on how to use
> > NPE, it's a really good idea to
This is not a matter of law. If Oracle/Sun set a direction on how to use
NPE, it's a really good idea to follow them -- even if you don't agree, do
it for the sake of consistency. I don't think using IAE is somehow "better"
Java than what they are doing. And I give weight to what Joshua said
becaus
Yes, it's supposed to throw NPE for the reasons stated a couple times in
this thread. That's by design, not accident. The "official" version in
java.lang.Objects (JDK 7+) does the same thing.
Cheers,
Paul
On Tue, May 6, 2014 at 4:00 PM, Duncan Jones wrote:
> On 6 May 2014 20:41, Phil Steitz
nd in Joshua Bloch's book.
Cheers,
Paul
On Tue, May 6, 2014 at 3:50 PM, Duncan Jones wrote:
> On 6 May 2014 19:19, Paul Benedict wrote:
> > NPE is implicit if the method does not allow an argument to be null. This
> > doesn't have to be the case. This has nothing to d
NPE is implicit if the method does not allow an argument to be null. This
doesn't have to be the case. This has nothing to do with the JDK vs. 3rd
party source. It's just about the contract. As long as you document which
arguments can be null, then you're good -- otherwise throw an NPE to
capture t
ing Javadoc was XML, I'll
gladly eat my words and enjoy learning something new. But why fight the
technology? Javadoc isn't ever going to be XML so why continue going down
that path?
On Thu, May 1, 2014 at 9:15 PM, Phil Steitz wrote:
> On 5/1/14, 2:31 PM, Paul Benedict wrote:
> &
s, buys you nothing. What buys you something is properly
formatted HTML in an HTML document.
Cheers,
Paul
On Thu, May 1, 2014 at 5:02 PM, Gilles wrote:
> On Thu, 1 May 2014 16:31:13 -0500, Paul Benedict wrote:
>
>> Gilles,
>>
>> Javadoc is not XHTML but HTML... and
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML fragment.
Documentation writers need to remember that their content is being placed
within a bigger document so correct tag usage is important to get
predictable results.
I think all Math committers will find this thread abou
Personally, I don't see a reason to revert the javadoc changes. There's no
turning back the clock on the javadoc processing engine -- it's not like 9
or 10 is going to stop warning about malformed HTML. Although I am not a
Math contributor/commiter, I support the change since going forward it will
Wrong syntax is different than missing syntax. The former affects
readability while the other just affects usability. Glad you found a way to
catch the former but ignore the latter.
On Thu, May 1, 2014 at 5:22 AM, Mark Struberg wrote:
> Actually the ',' causes a bug in the maven-javadoc-plugin.
Looks like I found the message I alluded to. Make sure you read the whole
thread for fun ;-)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html
On Wed, Apr 30, 2014 at 12:36 AM, Thomas Neidhart wrote:
> On 04/30/2014 03:50 AM, Gary Gregory wrote:
> > Well, it does not su
That's actually a really good point :-)
On Tue, Apr 29, 2014 at 8:50 PM, Gary Gregory wrote:
> Well, it does not support HTML in the sense that you MUST close all tags.
> No lonely s...
>
> Gary
>
>
> On Tue, Apr 29, 2014 at 9:35 PM, Paul Benedict
> wrote:
>
&g
JDK Javadoc only supports HTML. It doesn't support XHTML. I remember
someone saying this on the OpenJDK lists but don't know where it is... but
I do remember that.
On Tue, Apr 29, 2014 at 8:12 PM, Gary Gregory wrote:
> Bernd,
>
> For paragraphs I use la di da, never the concept of a "line
> sepa
Yup. I have depend on Lang 3 for my own code and many of my transitive
dependencies relies on Lang 2. There's no problem with having both
libraries in your code.
On Tue, Apr 22, 2014 at 9:22 AM, Matt Benson wrote:
> Note that you can use [lang] v2 and v3 together in the same project as both
> t
FYI, for anyone maintaining the site, the javadoc is not present from the
site's links.
--
Cheers,
Paul
The downside of it returning an empty collection is you either have (1) to
instantiate a collection just to say you have nothing or (2) you use an
immutable collection. #1 is bad in itself and #2 is only as bad if the
collection is otherwise writable. For example, it would be really strange
for the
I think starting the classes should be @since tagged; that's standard
procedure in the javadoc world, as far as i know. Regarding what's
forgotten, I never worried about that and fixing it is easy.
On Thu, Mar 27, 2014 at 11:18 AM, sebb wrote:
> On 27 March 2014 15:47, Paul Be
Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
the class, there's no need for it to be on methods unless the methods are
of another version. I think that's the standard javadoc way from Oracle
anyway.
On Thu, Mar 27, 2014 at 10:35 AM, sebb wrote:
> Indeed.
>
> The poi
I don't know if removing @since 1.0 should be pursued. Coming from a
research perspective, the lack of them either indicates (1) since 1.0 or
(2) an omission. There's no way to know how someone would interpret their
omission so I would recommend keeping them so it's clear which methods
existed sinc
I recommend copying the source of the Commons Lang classes you use and
maintain it privately. It is only two classes, right?
On Mar 1, 2014 12:51 PM, "André Diermann" wrote:
> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUt
Because eyes are always on the code (thank you very much commit mailing
list), people want to know the real differences between the files. It's
extremely difficult to know what a developer did if a commit to fix
something also includes cosmetic fixes. Separate the two out always and let
the commit
One thing I would prefer in a BeanUtils 2 is the removal of static utility
classes. I like beans; they allow me to subclass and customize. I can't do
that with static access.
On Wed, Feb 12, 2014 at 2:43 PM, Benedikt Ritter wrote:
> Hell André
>
>
> 2014-02-11 20:01 GMT+01:00 André Diermann :
>
Yes, and Gary's argument is a very high priority driver behind my
alphabetizing. I don't want to maintain groupings. I have concluded a long
time ago that my time is wasted doing that stuff in code.
On Thu, Jan 23, 2014 at 11:18 AM, Gary Gregory wrote:
> Adopting a guideline like this is still a
FWIW, there's no solution that can make someone happy. Personally, I always
alphabetize my methods because it's the most straightforward ordering -- no
one has to guess why things are grouped together and sometimes groupings
can get complex. I simply let people follow the javadocs/comments to make
Splitting with an empty string doesn't make any sense to me. Nothing should
match that -- even an empty string. It's a lack of a token.
On Mon, Jan 13, 2014 at 11:00 AM, Benedikt Ritter wrote:
> ping, any thought on this?
>
>
> 2014/1/11 Benedikt Ritter
>
> > Hi,
> >
> > while looking through t
I think it would be better to make sure this is up to date and link to it
alone:
http://people.apache.org/committers-by-project.html
On Wed, Jan 8, 2014 at 12:37 PM, Phil Steitz wrote:
> Why not just drop it? I would rather see collective energy go
> toward maintaining the individual component
There's nothing wrong with the name. Even the spec experts follow this
convention. See methods getContentLength() vs getContentLengthLong().
tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html
On Thu, Jan 2, 2014 at 4:08 PM, Gary Gregory wrote:
> There is no good shor
I have no problem with copying null to null.
On Mon, Nov 25, 2013 at 2:26 PM, Oliver Heger
wrote:
> Any updates here? Also, I would like to hear what others think about
> BEANUTILS-454 [1].
>
> Thanks
> Oliver
>
> [1] https://issues.apache.org/jira/browse/BEANUTILS-454
>
> Am 10.11.2013 22:36, s
For anyone's observation, I sent this question to the Open JDK list because
I am so surprised how adding default methods can break custom interface
extensions. I was really hoping default methods would be much more subtle
but it turns out this could be a common occurrence going forward. What if
JDK
The thread is here:
http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011397.html
On Wed, Nov 13, 2013 at 7:40 PM, Paul Benedict wrote:
> I will forward a portion of this email to the OpenJDK folks and see what
> they think about compatibility options.
>
>
> On We
I will forward a portion of this email to the OpenJDK folks and see what
they think about compatibility options.
On Wed, Nov 13, 2013 at 3:49 PM, Thomas Neidhart
wrote:
> Hi,
>
> during the vote for collections 4.0 we have discovered a problem wrt the
> MultiMap interface in general and specific
, 2013 at 2:16 PM, Oliver Heger
wrote:
> Hi Paul,
>
> Am 09.11.2013 19:31, schrieb Paul Benedict:
> > Oliver, would you have time to publish a snapshot of 1.9's site so I can
> > browse the javadocs and source xref? I can easily provide feedback if you
> > do that.
Oliver, would you have time to publish a snapshot of 1.9's site so I can
browse the javadocs and source xref? I can easily provide feedback if you
do that.
On Sat, Nov 9, 2013 at 12:07 PM, Oliver Heger
wrote:
> Just a heads-up that I intend to start the preparations for a
> [beanutils] 1.9.0 rel
Same here. I didn't know this existed. Thanks.
On Tue, Nov 5, 2013 at 10:49 PM, Gary Gregory wrote:
> Thank you all for replying.
>
> HPPC looks promising and it's Apache 2 licensed. I'll give it a closer
> look.
>
> Gary
>
>
> On Tue, Nov 5, 2013 at 8:59 PM, Ted Dunning wrote:
>
> > Trove is G
I don't think anything like that exists. If your # of entries were
reasonable, a theoretical implementation could allocate a big long[] array
and hash into that. However, 150,000 is very large for an array; possible
but I never done it. So I think the only thing you can really rely on is
the standa
In my own research on strong crypto, I found out that US law allows strong
crypto to be exported for open source software. That was some provision
recently carved out in the last 10 years. I think there are some
limitations and procedures wrapped around it -- like submitting the URL to
the source c
t;
> > > >> Matt
> > > >>
> > > >>
> > > >> On Tue, Oct 22, 2013 at 2:29 PM, Gary Gregory <
> garydgreg...@gmail.com
> > > >> >wrote:
> > > >>
> > > >> >
> > > >> >
>
If you can subclass, the class will likely be mutable somehow (accessing
protected or package-private data?) -- even introducing new variables
exclusive to the subclass. The "final" keyword is used well here.
On Tue, Oct 22, 2013 at 12:15 PM, sebb wrote:
> On 22 October 2013 18:10, Gary Gregory
I don't think any duplication will occur if we follow simple rules. Unless
the object performs validation -- which can determined if an exception is
thrown on validation failure -- then you have a method for ObjectUtils;
otherwise it belongs in Validate.
On Fri, Oct 18, 2013 at 1:26 PM, Gary Greg
I am glad to hear being "dormant" is not the same thing as being in the
"attic"
I also prefer that being "dormant" doesn't cause a SVN/GitHub folder move.
The projects should just live where they are, even when sleeping. Only move
them if they actually go into an "attic"
On Thu, Oct 17, 2013 at
I don't like the idea of putting inactive components in the attic -- unless
there is some unreasonable length of time that goes by without any
development (3 years?). People who want to get things out of the attic are
usually a sole passionate fellow. Can a sole fellow unilaterally get a
component
The dots aren't decimal separators and version numbers are not true
numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal
numbers, you couldn't have more than one dot.
0.9 to 1.0 is a major version jump. However, 0.X usually indicates
pre-release quality (i.e., not ready for produ
A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html
On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory wrote:
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> wrote:
> > That's a reasonable style of versioning :)
> >
> > I had many issues with binar
Two weeks ago, I mentioned that BeanUtils and Convert heavily overlap. Some
others agreed. Do we want to fold one project into the other? Or can we
find justification to have 2 separate conversion projects?
--
Cheers,
Paul
Emmanuel, yes. Both the CVSParser and Iterator are two distinct designs.
Both are types of parsers here. So it's really a question of design. Do you
want your users to use the parser directly or work through the iterator or
both? But they shouldn't interfere with each other.
Example:
CVSParser p =
The only danger of static methods is that you can't override them.
BeanUtils first suffered from this fate and they then made an instance
version (BeanUtils2). Just said plainly, you can't customize well using
factory classes/methods.
On Wed, Aug 14, 2013 at 3:04 PM, Emmanuel Bourg wrote:
> Le
Perhaps we're going down the wrong path here. I think having an iterator()
and a parser conflict with each other. The former seems like a leaky
abstraction of the latter. I would propose the parser uses an iterator
internally, or there's an API to get an iterator from a data source (but
not expose
I wonder how many were waiting in silence to see if someone else would
speak up for a rename.
On Tue, Aug 6, 2013 at 3:16 PM, Matt Benson wrote:
> Actually I think by "function name" he was referring to the unfortunate
> English-language sexual innuendo incurred by the abbreviation of the word
If Convert and BeanUtils do the same thing, I think Commons needs to figure
out how to solve this dilemma because duplicated functionality is usually
frowned upon here. For example, when Commons Lang began doing math, they
moved that to Commons Math (and the same thing happened for BeanUtils from
L
vert. The applications developer is
> free to create any wrappers/facades necessary to connect the two.
>
> -Adrian
>
>
> On 8/3/2013 9:18 AM, Paul Benedict wrote:
>
>> Adrian, the conversions would be configurable. At least that's how I
>> envisioned it using exist
Adrian, the conversions would be configurable. At least that's how I
envisioned it using existing BeanUtils functionality. Gary has a request
our to me to demo that.
On Aug 3, 2013 11:10 AM, "Adrian Crum"
wrote:
> Inline...
>
> On 8/3/2013 9:05 AM, Gary Gregory wrote:
>
>> On Sat, Aug 3, 2013 at
is going to blow up
> really quickly, by the way (registering new converter types, etc.). I
> don't see how having a few little helper methods in CSV is that big of
> an issue, personally.
>
> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
> wrote:
> > You might want to thin
You might want to think of a conversion addon package using Common
BeanUtils. That project is skilled at conversions from String and has
pluggable capability to customize conversion types.
On Aug 1, 2013 6:51 PM, "Paul Benedict" wrote:
> None of these methods document exce
None of these methods document exceptions if the conversion fails (eg, not
an integer). Also, how strict is the conversion? Can "x" represent boolean
false or is that an exception?
On Aug 1, 2013 9:00 AM, "Gary Gregory" wrote:
> I would like to note this CSVRecord addition I am planning on:
>
>
Because Strings hold onto their internal char[], unreferencing a String
password means it hangs around in memory until the JVM garbage collects it.
If you can ever prevent it from becoming a String, keep it as a char[] or
byte[] -- then zero it all out before the array is unreferenced.
Paul
On M
Don't try to solve how to stop an alpha release from becoming integrated.
If someone does that, there's inherit risk involved. I don't see how this
is any different, per se, a beta or RC release. If you build on unstable
code, the only support advice I'd will get is: upgrade to the latest GA. :-)
AFAIK, a release is a release. If you're voting on a project, a successful
vote creates an Apache artifact that needs to be published to the world.
Maven just released their 3.1.0-alpha. That release will be forever out
there, but since it's not production quality, usage will eventually
drop-off on
I always thought changes.xml was to describe the release package. If the
ticket produced no artifact update, why does it need to be part of the
distribution?
On Tue, Jun 11, 2013 at 10:30 AM, Gary Gregory wrote:
> I see no harm as adding it to changes.xml, it's a doc change that we might
> as we
yes :-)
On Tue, Apr 23, 2013 at 4:58 PM, sebb wrote:
> On 23 April 2013 22:53, Paul Benedict wrote:
>
> > FYI, the site points to non-existent API and user guide. The links are
> > broken on both the LHS navigation and the main content.
> >
> >
> Beans d
FYI, the site points to non-existent API and user guide. The links are
broken on both the LHS navigation and the main content.
Paul
FYI, the website no longer hosts the API and user guide. The links are
broken.
Paul
-0
I think project names are ASF property (like a trademark). Without
clarification from the board or legal, the vote seems premature.
On Dec 22, 2011 5:32 AM, "Mark Thomas" wrote:
> On 19/12/2011 14:54, Gary Gregory wrote:
> > This is a VOTE to [ALL] to rename Commons Sanselan to Commons Image.
Any product called the Gigester gets my +1 vote!
On Sun, Dec 11, 2011 at 10:56 AM, Oliver Heger wrote:
> +1
>
> Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.
>
> One minor nit: In the release notes the following recommended dependencies
> are listed:
> "The Recommend
I think a boolean is a good indicator for whether the operation was
honored or not.
Paul
On Tue, Sep 20, 2011 at 11:41 PM, Gary Gregory wrote:
> On Wed, Sep 21, 2011 at 12:09 AM, Phil Steitz wrote:
>
>> On 9/20/11 8:24 PM, Gary Gregory wrote:
>> > That sounds reasonable.
>> >
>> > Would any cal
l!
>>>> yes it can be done, of course :) I'm not convinced anyway by the heavy
>>>> notation that, modifying the Context, would impact the Command and
>>>> Filter classes. I think it is because just a matter of taste :P
>>>> Feedbacks/suggestion
The basic context should be Context and then use interface
composition to define other things like:
public interface PropertyContext extends Context,
Map
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
wrote:
> Hi Elijah,
> I spent some spare time trying to f
.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict wrote:
>> The purpose of Generics is to provide type safety with the implicit
>> casts. Implicit casts because of typing shouldn't cause a
>> ClassCastEx
nk anyway putting types to Context would make Filter, Command,
> Chain, ... classes over engineered IMHO
>
> best,
> Simo
>
> [1] http://s.apache.org/xfj
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 10:20
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic wrote:
> Specifying Object for V would be the most likely use case.
>
> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict wrote:
>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi
>> wrote:
>>> Hi Paul,
>>> the
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi wrote:
> Hi Paul,
> the use of that method is to automatically infer the assigned type,
> instead of writing
>
> MyPojo myPojo = (MyPojo) context.get( "myKey" );
>
> the retrieve method allows to
>
> MyPojo myPojo = context.retrieve( "myKey" );
ng your thoughts!!!
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic wrote:
>> Paul,
>>
>> You may be right. Which one is more idiomatic?
>>
>>
I go with what I said. Extending from Object is sulfurous since all
type parameters extend at least from Object.
On Fri, Sep 9, 2011 at 1:56 PM, Elijah Zupancic wrote:
> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic wrote:
> Thanks for your comments Nail.
>
> I think that I've come around to see your point after sleeping on it.
> What do you think about this:
>
> Context.java - would be defined as so:
>
> public interface Context extends Map
Isn't that identica
Here's my +1 non-binding.
On Thu, Sep 8, 2011 at 1:38 PM, Simone Tripodi wrote:
> Hi all,
> The proposal of making the 2.0-work brach as proper codebase in /trunk
> for the [chain] component passes with 3 +1 binding votes from
>
> * Simone Tripodi
> * James Carman
> * Matt Benson
>
> no other
Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.
On Tue, Sep 6, 2011 at 8:36 AM, sebb wrote:
> On 6 September 2011 05:44, David Karlsen wrote:
>> I think tying to sun c
Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.
On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta wrote:
> On 09/05/2011 08:51 AM, Simone Tripodi wr
I want to get rid of it extending map. Have it define as asMap()
function instead. Especially since JDK 8 is bringing in extension
methods, which adds new (and default) methods to all collections, it
won't look very nice. Let's make a break now.
On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta wrote:
; Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Aug 31, 2011 at 9:08 PM, Paul Benedict wrote:
>>> At the same time, everybody: do you agree on replacing package.html
>>> with package-info.java?
>>
>> +1
>>
>&g
> At the same time, everybody: do you agree on replacing package.html
> with package-info.java?
+1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On Wed, Aug 31, 2011 at 12:02 PM, Simone Tripodi
wrote:
> Hi Paul,
> if I remember correctly, maven should be able to aggregate submodules
> apidocs, I will ask to mvn ML.
Yes, it can. The javadoc plugin has an aggregate option.
Paul
-
On Wed, Aug 31, 2011 at 9:45 AM, Simone Tripodi
wrote:
> Hi all guys,
> I noticed that properly setting the 1.5 as target compliance level,
> there are some @Override annotations that in cases of interfaces
> methods implementation should be dropped. Do you agree on it?
Yes, @Override from interf
I am curious about the change of normal collections to concurrent
collections. Is there overhead with the concurrent stuff? Most of my
context access is not multithreaded.
On Mon, Aug 29, 2011 at 2:53 PM, Simone Tripodi
wrote:
> Hi all guys,
> I just fixed the clirr report generation and deployed
1 - 100 of 283 matches
Mail list logo
