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
t out how to comment on a JEP? The 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
>
> O
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
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 djo...@apache.org wrote:
Hi folks,
Currently the Review Patch fix version seems to be applied whenever
code has
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 benerit...@gmail.com wrote:
Send from my mobile device
Am 05.01.2015 um
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,
.
On Fri, Dec 5, 2014 at 6:33 AM, Paul Benedict pbened...@apache.org
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 your code contribution to the community
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
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 oliver.he...@oliver-heger.de
wrote:
There was no reaction on my comment so
, sebb seb...@gmail.com a écrit :
On 17 October 2014 21:57, Paul Benedict pbened...@apache.org 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 compiler problems due to API
You are not including duplicate artifacts, they are totally distinct.
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 seb...@gmail.com wrote:
On 17 October 2014 21:37,
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 seb...@gmail.com wrote:
On 9 September 2014 15:32, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Sep 9, 2014 at 9:17 AM, sebb seb...@gmail.com
on the
release process, and report any findings. At least at that point, we'll
have learned enough from the process to make an informed decision.
Regards,
Mark
On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 09/09/2014 16:52, Paul Benedict a écrit :
Is there an itch
Gary, 1.2 of what?
Cheers,
Paul
On Mon, Jul 7, 2014 at 3:38 PM, Gary Gregory garydgreg...@gmail.com wrote:
Note that 1.2 is about to be released.
Gary
div Original message /divdivFrom: brit...@apache.org
/divdivDate:07/07/2014 15:36 (GMT-05:00) /divdivTo:
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
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
.
Cheers,
Paul
On Tue, May 6, 2014 at 3:50 PM, Duncan Jones dun...@wortharead.com wrote:
On 6 May 2014 19:19, Paul Benedict pbened...@apache.org 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 do with the JDK
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 dun...@wortharead.com wrote:
On 6 May 2014
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
because
is going the other direction.
Paul
Cheers,
Paul
On Tue, May 6, 2014 at 6:27 PM, sebb seb...@gmail.com wrote:
On 6 May 2014 22:54, Paul Benedict pbened...@apache.org 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 follow them
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 strub...@yahoo.de wrote:
Actually the ',' causes a bug in the
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
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
something is properly
formatted HTML in an HTML document.
Cheers,
Paul
On Thu, May 1, 2014 at 5:02 PM, Gilles gil...@harfang.homelinux.org wrote:
On Thu, 1 May 2014 16:31:13 -0500, Paul Benedict wrote:
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML fragment
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 phil.ste...@gmail.com wrote:
On 5/1/14, 2:31 PM, Paul Benedict wrote:
Gilles,
Javadoc
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 garydgreg...@gmail.comwrote:
Bernd,
For paragraphs I use pla di da/p, never the
That's actually a really good point :-)
On Tue, Apr 29, 2014 at 8:50 PM, Gary Gregory garydgreg...@gmail.comwrote:
Well, it does not support HTML in the sense that you MUST close all tags.
No lonely ps...
Gary
On Tue, Apr 29, 2014 at 9:35 PM, Paul Benedict pbened...@apache.org
wrote
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 thomas.neidh...@gmail.com
wrote:
On 04/30/2014 03:50 AM, Gary Gregory
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 gudnabr...@gmail.com wrote:
Note that you can use [lang] v2 and v3 together in the same
FYI, for anyone maintaining the site, the javadoc is not present from the
site's links.
--
Cheers,
Paul
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
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 seb...@gmail.com wrote:
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 seb...@gmail.com wrote:
On 27 March 2014 15:47, 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
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 andre.dierm...@gmail.com wrote:
But will upgrading to 1.7 will solve the core issue, that some features
(in detail: Assertions,
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 brit...@apache.org wrote:
Hell André
2014-02-11 20:01 GMT+01:00
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
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 garydgreg...@gmail.comwrote:
Adopting a
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 brit...@apache.orgwrote:
ping, any thought on this?
2014/1/11 Benedikt Ritter brit...@apache.org
Hi,
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 phil.ste...@gmail.com wrote:
Why not just drop it? I would rather see collective energy go
toward maintaining the
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 garydgreg...@gmail.com wrote:
I have no problem with copying null to null.
On Mon, Nov 25, 2013 at 2:26 PM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
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
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
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
thomas.neidh...@gmail.comwrote:
Hi,
during the vote for collections 4.0 we have discovered a problem wrt the
MultiMap interface
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 pbened...@apache.org wrote:
I will forward a portion of this email to the OpenJDK folks and see what
they think about compatibility options.
On Wed
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
oliver.he...@oliver-heger.dewrote:
Just a heads-up that I intend to start the preparations
9, 2013 at 2:16 PM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
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.
thanks
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
Same here. I didn't know this existed. Thanks.
On Tue, Nov 5, 2013 at 10:49 PM, Gary Gregory garydgreg...@gmail.comwrote:
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
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
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 seb...@gmail.com wrote:
On 22 October 2013
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
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
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 garydgreg...@gmail.com wrote:
On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
siegfried.goes...@it20one.at wrote:
That's a reasonable style of
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
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
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
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
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 gudnabr...@gmail.com wrote:
Actually I think by function name he was referring to the unfortunate
English-language sexual innuendo incurred by the
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 adrian.c...@sandglass-software.com
wrote:
Inline...
On 8/3/2013 9:05 AM, Gary Gregory
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 existing BeanUtils functionality. Gary has a request
our to me to demo that.
On Aug 3, 2013 11
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
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 garydgreg...@gmail.com wrote:
I would like to note this CSVRecord addition I am
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 pbened...@apache.org wrote:
None of these methods document exceptions
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
paulus.benedic...@gmail.com wrote:
You might want to think of a conversion
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
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
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. :-)
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 garydgreg...@gmail.comwrote:
I see no harm as adding it to changes.xml, it's a doc change
FYI, the website no longer hosts the API and user guide. The links are
broken.
Paul
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
yes :-)
On Tue, Apr 23, 2013 at 4:58 PM, sebb seb...@gmail.com wrote:
On 23 April 2013 22:53, Paul Benedict pbened...@apache.org 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 does not exist
-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 ma...@apache.org wrote:
On 19/12/2011 14:54, Gary Gregory wrote:
This is a VOTE to [ALL] to rename Commons Sanselan to
Any product called the Gigester gets my +1 vote!
On Sun, Dec 11, 2011 at 10:56 AM, Oliver Heger oliver.he...@oliver-heger.de
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
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 garydgreg...@gmail.com wrote:
On Wed, Sep 21, 2011 at 12:09 AM, Phil Steitz phil.ste...@gmail.com wrote:
On 9/20/11 8:24 PM, Gary Gregory wrote:
That
to provide a
solution feel free to fill an issue and attach a patch!!
TIA, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 16, 2011 at 11:05 PM, Paul Benedict pbened...@apache.org
wrote:
The basic context should be ContextK, V and then use
The basic context should be ContextK, V and then use interface
composition to define other things like:
public interface PropertyContext extends ContextString, Object,
MapString, Object
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
simonetrip...@apache.org
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic eli...@zupancic.name 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 ContextK extends Object, V
, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic eli...@zupancic.name 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
!!!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic eli...@zupancic.name wrote:
Paul,
You may be right. Which one is more idiomatic?
Thanks,
-Elijah
On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict pbened
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi simonetrip...@apache.org 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 =
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic eli...@zupancic.name wrote:
Specifying Object for V would be the most likely use case.
On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi simonetrip...@apache.org
wrote:
Hi
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 PM, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 3:15 PM
/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict pbened...@apache.org wrote:
The purpose of Generics is to provide type safety with the implicit
casts. Implicit casts because of typing shouldn't cause a
ClassCastException. That would break an important
Here's my +1 non-binding.
On Thu, Sep 8, 2011 at 1:38 PM, Simone Tripodi simonetrip...@apache.org 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
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 seb...@gmail.com wrote:
On 6 September 2011 05:44, David Karlsen
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 rocketra...@fastmail.fm wrote:
On 09/05/2011
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
On Wed, Aug 31, 2011 at 9:45 AM, Simone Tripodi
simonetrip...@apache.org 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,
On Wed, Aug 31, 2011 at 12:02 PM, Simone Tripodi
simonetrip...@apache.org 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
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
://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Aug 31, 2011 at 9:08 PM, Paul Benedict pbened...@apache.org wrote:
At the same time, everybody: do you agree on replacing package.html
with package-info.java?
+1
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
simonetrip...@apache.org wrote:
Hi all guys,
I just fixed the clirr report
Any thoughts on dumping the checked exception?
public interface CommandT extends Context { ... boolean execute(T
context) throws Exception; }
Paul
On Mon, Aug 22, 2011 at 9:46 AM, Matt Benson gudnabr...@gmail.com wrote:
I am generally in favor. I think it could be good to apply his patch
on a
I may have missed the discussion... but are we releasing a Java 5
genericized version first before major refactoring?
On Tue, Aug 16, 2011 at 3:35 PM, Elijah Zupancic eli...@zupancic.name wrote:
Hi Simo,
Yes, the patch is binary compatible with the old chain with one exception:
refactoring?
Thanks,
-Elijah
On Tue, Aug 16, 2011 at 1:42 PM, Paul Benedict pbened...@apache.org wrote:
I may have missed the discussion... but are we releasing a Java 5
genericized version first before major refactoring?
On Tue, Aug 16, 2011 at 3:35 PM, Elijah Zupancic eli...@zupancic.name
wrote
1 - 100 of 253 matches
Mail list logo
