Re: [Math] Moving on or not?

[Luc Maisonobe]

Le 08/02/2013 03:21, Konstantin Berlin a écrit :
> Sorry, but not of this is making sense to me. We had a long discussion
> about how the library doesn't test for large scale problem
> performance. A lot of algorithms probably do not scale well as the
> result. There was talk of dropping sparse support in linear algebra.
> So instead of fixing that, you jump to parallelization, which is
> needed only for large scale problems, which this library does not
> handle well even in single thread right now.
> 
> The most significant impact you can have is fixing the linear algebra
> component.

I agree with this. Also in order to avoid spreading our attention too
much on keeping several branches in sync, I would suggest to not create
a new component but directly decide we will not support Java 5 anymore
as of Apache Commons Math 4.0, so people can progressively use the new
features of the language and experiment directly on the trunk.

best regards,
Luc

> 
> On Feb 7, 2013, at 5:06 PM, Gilles  wrote:
> 
>> On Thu, 07 Feb 2013 08:32:46 -0800, Phil Steitz wrote:
>>> On 2/7/13 8:04 AM, Gilles wrote:
 On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote:
> On 2/7/13 4:58 AM, Gilles wrote:
>> On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote:
>>> On 2/6/13 9:03 AM, Gilles wrote:
 On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote:
> On 2/5/13 6:08 AM, Gilles wrote:
>> Hi.
>>
>> In the thread about "static import", Stephen noted that
>> decisions
>> on a
>> component's evolution are dependent on whether the future of
>> the
>> Java
>> language is taken into account, or not.
>> A question on the same theme also arose after the
>> presentation of
>> Commons
>> Math in FOSDEM 2013.
>>
>> If we assume that efficiency is among the important
>> qualities for
>> Commons
>> Math, the future is to allow usage of the tools provided by the
>> standard
>> Java library in order to ease the development of multi-threaded
>> algorithms.
>>
>> Maintaining Java 1.5 source compatibility for the reason
>> that we
>> may need
>> to support legacy applications will turn out to be
>> self-defeating:
>> 1. New users will not consider Commons Math's features that are
>> notably
>>   apt to parallel processing.
>> 2. Current users might at some point simply switch to another
>> library if
>>   it proves more efficient (because it actually uses
>> multi-threading).
>> 3. New Java developers will be turned away because they will
>> want
>> to use
>>   the more convenient features of the language in order to
>> provide
>>   potential contributions.
>>
>> If maintaining 1.5 source compatibility is kept as a
>> requirement, the
>> consequence is that Commons Math will _become_ a legacy
>> library.
>> In that perspective, implementing/improving algorithms for
>> which a
>> parallel version is known to be more efficient is plainly a
>> waste of
>> development and maintenance time.
>>
>> In order to mitigate the risks (both of upgrading and of not
>> upgrading
>> the source compatibility requirement), I would propose to
>> create a
>> new
>> project (say, "Commons Math MT") where we could implement new
>> features[1]
>> without being encumbered with the 1.5 requirement.[2]
>> The "Commons Math MT" would depend on "Commons Math" where we
>> would
>> continue developing single-thread (and thread-safe) "tasks",
>> i.e.
>> independent units of processing that could be used in
>> algorithms
>> located in "Commons Math MT".
>>
>> In summary:
>> - Commons Math (as usual):
>>  * single-thread (sequential) algorithms,
>>  * (pure) Java 5,
>>  * no dependencies.
>> - Commons Math MT:
>>  * multi-thread (parallel) algorithms,
>>  * Java 7 and beyond,
>>  * JNI allowed,
>>  * dependencies allowed (jCuda).
>>
>> What do you think?
>
> There are several other possibilities to consider:
>
> 0) Implement multithreading using JDK 1.5 primitives
> 1) Set things up within [math] to support parallel execution in
> JDK
> 1.7, Hadoop or other frameworks
> 2) Instead of a new project, start a 4.x branch targeting JDK
> 1.7
>
> I think we should maintain a version that has no dependencies
> and no
> JNI in any case.
>
> Starting a branch and getting concrete about how to parallelize
> some
>

Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

[Benedikt Ritter]

Hi Simo,


2013/2/8 Simone Tripodi 

> > How do you feel about this? Checkstyle complains about this, and I think
> it
> > is sufficient to tell users that an argument must not be null.
>
> sorry, which one?
>

should have made that clearer :)
I removed the @throws NullpointerException from the JavaDoc because check
style complains about this (NPE is not declared in the method's signature).
I think it is enough to tell users that an argument must not be null. WDYT?

Benedikt


>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Daemon 1.0.13

[Gary Gregory]

+1

Using SVN tag.

BUILD SUCCESS with "mvn test", "mvn site" and "mvn deploy -Prelease
-Ptest-deploy" with:

Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_38, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_38\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Site looks good, Clirr report OK, RAT has the usual warnings it seems.

nmake OK for both windows programs with:

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

The C compiler produces the same old warning on procrun.

Gary



On Fri, Feb 8, 2013 at 2:57 AM, Luc Maisonobe  wrote:

> Le 07/02/2013 06:37, Mladen Turk a écrit :
> >
> > Apache Commons Daemon 1.0.13 based on RC1 is ready.
> > It contains a fix for regression found in previous release(s).
> >
> > Binaries and sources for testing are at [1], dist layout is at [2],
> > generated site can be found at [3]. Tag is [4] which will be renamed to
> > COMMONS_DAEMON_1_0_13 if voted.
> >
> > Please vote (vote will remain open for at least 72 hours).
> >
> > Apache Commons Daemon 1.0.13 is
> >   [X] +1 Release
>
> Luc
>
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> >
> > [1]
> > https://repository.apache.org/content/repositories/orgapachecommons-214/
> > [2] http://people.apache.org/~mturk/daemon-1.0.13/
> > [3] http://people.apache.org/~mturk/daemon-1.0.13-site/
> > [4]
> >
> https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_13_RC1/
> >
> >
> >
> > Regards
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Moving on or not?

[Phil Steitz]

On 2/8/13 12:04 AM, Luc Maisonobe wrote:
> Le 08/02/2013 03:21, Konstantin Berlin a écrit :
>> Sorry, but not of this is making sense to me. We had a long discussion
>> about how the library doesn't test for large scale problem
>> performance. A lot of algorithms probably do not scale well as the
>> result. There was talk of dropping sparse support in linear algebra.
>> So instead of fixing that, you jump to parallelization, which is
>> needed only for large scale problems, which this library does not
>> handle well even in single thread right now.
>>
>> The most significant impact you can have is fixing the linear algebra
>> component.
> I agree with this. Also in order to avoid spreading our attention too
> much on keeping several branches in sync, I would suggest to not create
> a new component but directly decide we will not support Java 5 anymore
> as of Apache Commons Math 4.0, so people can progressively use the new
> features of the language and experiment directly on the trunk.

Actually, to get anything, you would need to bump to 1.7, abandoning
1.6 as well.  That would effectively mean abandoning a large segment
(likely the majority) of the user base.  I would not like to do
that.  So if we don't have the energy to maintain two lines, I would
say hold off requiring Java 7 until we have stabilized the API and
fixed things like above.  

Phil
>
> best regards,
> Luc
>
>> On Feb 7, 2013, at 5:06 PM, Gilles  wrote:
>>
>>> On Thu, 07 Feb 2013 08:32:46 -0800, Phil Steitz wrote:
 On 2/7/13 8:04 AM, Gilles wrote:
> On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote:
>> On 2/7/13 4:58 AM, Gilles wrote:
>>> On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote:
 On 2/6/13 9:03 AM, Gilles wrote:
> On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote:
>> On 2/5/13 6:08 AM, Gilles wrote:
>>> Hi.
>>>
>>> In the thread about "static import", Stephen noted that
>>> decisions
>>> on a
>>> component's evolution are dependent on whether the future of
>>> the
>>> Java
>>> language is taken into account, or not.
>>> A question on the same theme also arose after the
>>> presentation of
>>> Commons
>>> Math in FOSDEM 2013.
>>>
>>> If we assume that efficiency is among the important
>>> qualities for
>>> Commons
>>> Math, the future is to allow usage of the tools provided by the
>>> standard
>>> Java library in order to ease the development of multi-threaded
>>> algorithms.
>>>
>>> Maintaining Java 1.5 source compatibility for the reason
>>> that we
>>> may need
>>> to support legacy applications will turn out to be
>>> self-defeating:
>>> 1. New users will not consider Commons Math's features that are
>>> notably
>>>   apt to parallel processing.
>>> 2. Current users might at some point simply switch to another
>>> library if
>>>   it proves more efficient (because it actually uses
>>> multi-threading).
>>> 3. New Java developers will be turned away because they will
>>> want
>>> to use
>>>   the more convenient features of the language in order to
>>> provide
>>>   potential contributions.
>>>
>>> If maintaining 1.5 source compatibility is kept as a
>>> requirement, the
>>> consequence is that Commons Math will _become_ a legacy
>>> library.
>>> In that perspective, implementing/improving algorithms for
>>> which a
>>> parallel version is known to be more efficient is plainly a
>>> waste of
>>> development and maintenance time.
>>>
>>> In order to mitigate the risks (both of upgrading and of not
>>> upgrading
>>> the source compatibility requirement), I would propose to
>>> create a
>>> new
>>> project (say, "Commons Math MT") where we could implement new
>>> features[1]
>>> without being encumbered with the 1.5 requirement.[2]
>>> The "Commons Math MT" would depend on "Commons Math" where we
>>> would
>>> continue developing single-thread (and thread-safe) "tasks",
>>> i.e.
>>> independent units of processing that could be used in
>>> algorithms
>>> located in "Commons Math MT".
>>>
>>> In summary:
>>> - Commons Math (as usual):
>>>  * single-thread (sequential) algorithms,
>>>  * (pure) Java 5,
>>>  * no dependencies.
>>> - Commons Math MT:
>>>  * multi-thread (parallel) algorithms,
>>>  * Java 7 and beyond,
>>>  * JNI allowed,
>>>  * dependencies allowed (jCuda).
>>>
>>> What do you think?
>> There are several other possibilities to consider:

Re: [Math] Moving on or not?

[Sébastien Brisard]

Hello,


2013/2/6 Konstantin Berlin 

> >
> > As for efficiency (or faster execution, if you want), I don't see the
> > point in doubting that tasks like global search (e.g. in a genetic
> > algorithm) will complete in less time when run in parallel...
>
>
> Just a quick note. This statement is incorrect. Parallelization should be
> done at the coarsest level. So if the program is already parallel, and each
> thread is executing your parallel math function, it could indeed be worse.
>

I think *this* statement is incorrect. Whether or not you need
parallelization is pretty much dependent on the application. For example,
if I'm dealing with a stack of 2D images, having a single thread
implementation is probably best. That way, I can decide to treat different
images in different threads (parallelization would then occur at the
coarsest level). On the other hand, if I'm dealing with a 3D image, maybe I
would appreciate that each operation is parallelized. If that's not done at
the finest level, then the user is stuck with a computation which takes for
ever.

S

Re: [Math] Moving on or not?

[Sébastien Brisard]

Large does not necessarily mean sparse. And please note that iterative
linear solvers was I think a big step towards large scale problems.

Of course, you are very welcome to contribute a robust implementation for
sparse matrices. The reason why we dropped it (momentarily, hopefully) was
that the current implementation was broken, in the sense that the same
computation carried out with sparse and non sparse implementations would
not lead to the same result. While this might seem perfectly acceptable (it
probably is in most applications), people who took part to the
corresponding discussion (you were not among those!) decided that it was
*not* acceptable.

I've spent a lot of time on this issue, and could not come up with a
satisfactory solution. I think the best we could do is
1. Restore the broken implementation, clean it up, and put a lot of
warnings in the javadoc.
2. Create a sub-project for sparse implementations, with lower expectations
regarding boundary cases (1.0 / +0.0, 1.0 / -0.0, ...).

Since people are reluctant with Gilles' proposal, I think that 1. is
probably the best solution, but the javadoc must be very clear about all
possible issues.

As a side note, if I remember correctly, people complained about the
implementation of sparse matrices not being very efficient.
S


2013/2/8 Konstantin Berlin 

> Sorry, but not of this is making sense to me. We had a long discussion
> about how the library doesn't test for large scale problem
> performance. A lot of algorithms probably do not scale well as the
> result. There was talk of dropping sparse support in linear algebra.
> So instead of fixing that, you jump to parallelization, which is
> needed only for large scale problems, which this library does not
> handle well even in single thread right now.
>
> The most significant impact you can have is fixing the linear algebra
> component.
>
> On Feb 7, 2013, at 5:06 PM, Gilles  wrote:
>
> > On Thu, 07 Feb 2013 08:32:46 -0800, Phil Steitz wrote:
> >> On 2/7/13 8:04 AM, Gilles wrote:
> >>> On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote:
>  On 2/7/13 4:58 AM, Gilles wrote:
> > On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote:
> >> On 2/6/13 9:03 AM, Gilles wrote:
> >>> On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote:
>  On 2/5/13 6:08 AM, Gilles wrote:
> > Hi.
> >
> > In the thread about "static import", Stephen noted that
> > decisions
> > on a
> > component's evolution are dependent on whether the future of
> > the
> > Java
> > language is taken into account, or not.
> > A question on the same theme also arose after the
> > presentation of
> > Commons
> > Math in FOSDEM 2013.
> >
> > If we assume that efficiency is among the important
> > qualities for
> > Commons
> > Math, the future is to allow usage of the tools provided by the
> > standard
> > Java library in order to ease the development of multi-threaded
> > algorithms.
> >
> > Maintaining Java 1.5 source compatibility for the reason
> > that we
> > may need
> > to support legacy applications will turn out to be
> > self-defeating:
> > 1. New users will not consider Commons Math's features that are
> > notably
> >   apt to parallel processing.
> > 2. Current users might at some point simply switch to another
> > library if
> >   it proves more efficient (because it actually uses
> > multi-threading).
> > 3. New Java developers will be turned away because they will
> > want
> > to use
> >   the more convenient features of the language in order to
> > provide
> >   potential contributions.
> >
> > If maintaining 1.5 source compatibility is kept as a
> > requirement, the
> > consequence is that Commons Math will _become_ a legacy
> > library.
> > In that perspective, implementing/improving algorithms for
> > which a
> > parallel version is known to be more efficient is plainly a
> > waste of
> > development and maintenance time.
> >
> > In order to mitigate the risks (both of upgrading and of not
> > upgrading
> > the source compatibility requirement), I would propose to
> > create a
> > new
> > project (say, "Commons Math MT") where we could implement new
> > features[1]
> > without being encumbered with the 1.5 requirement.[2]
> > The "Commons Math MT" would depend on "Commons Math" where we
> > would
> > continue developing single-thread (and thread-safe) "tasks",
> > i.e.
> > independent units of processing that could be used in
> > algorithms
> > located in "Commons Math MT".
> 

Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

[Oliver Heger]

Am 08.02.2013 09:26, schrieb Benedikt Ritter:

Hi Simo,


2013/2/8 Simone Tripodi 


How do you feel about this? Checkstyle complains about this, and I think

it

is sufficient to tell users that an argument must not be null.


sorry, which one?



should have made that clearer :)
I removed the @throws NullpointerException from the JavaDoc because check
style complains about this (NPE is not declared in the method's signature).
I think it is enough to tell users that an argument must not be null. WDYT?

Benedikt


In his "Effective Java" Josh Bloch recommends the following related to 
runtime exceptions:

- Don't declare them using a throws clause
- Document them in JavaDocs using @throws

In [configuration] I do it this way. I am wondering why checkstyle 
complains about the Javadocs declaration. Maybe its configuration should 
be tweaked?


Oliver






http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

[Duncan Jones]

In this specific case, I think a "..., not null" caveat is sufficient.
But in the general case, I think documenting interesting runtime
exceptions in the javadoc is good practice. Does the CheckStyle config
need tweaking?

On 8 February 2013 08:26, Benedikt Ritter  wrote:
> Hi Simo,
>
>
> 2013/2/8 Simone Tripodi 
>
>> > How do you feel about this? Checkstyle complains about this, and I think
>> it
>> > is sufficient to tell users that an argument must not be null.
>>
>> sorry, which one?
>>
>
> should have made that clearer :)
> I removed the @throws NullpointerException from the JavaDoc because check
> style complains about this (NPE is not declared in the method's signature).
> I think it is enough to tell users that an argument must not be null. WDYT?
>
> Benedikt
>
>
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Moving on or not?

[Luc Maisonobe]

Hi Phil,

Le 08/02/2013 15:20, Phil Steitz a écrit :
> On 2/8/13 12:04 AM, Luc Maisonobe wrote:
>> Le 08/02/2013 03:21, Konstantin Berlin a écrit :
>>> Sorry, but not of this is making sense to me. We had a long discussion
>>> about how the library doesn't test for large scale problem
>>> performance. A lot of algorithms probably do not scale well as the
>>> result. There was talk of dropping sparse support in linear algebra.
>>> So instead of fixing that, you jump to parallelization, which is
>>> needed only for large scale problems, which this library does not
>>> handle well even in single thread right now.
>>>
>>> The most significant impact you can have is fixing the linear algebra
>>> component.
>> I agree with this. Also in order to avoid spreading our attention too
>> much on keeping several branches in sync, I would suggest to not create
>> a new component but directly decide we will not support Java 5 anymore
>> as of Apache Commons Math 4.0, so people can progressively use the new
>> features of the language and experiment directly on the trunk.
> 
> Actually, to get anything, you would need to bump to 1.7, abandoning
> 1.6 as well.

I did not knew that. I don't know yet the Java 7 specificities, as the
projects I deal with are stuck to Java 6 at most.

> That would effectively mean abandoning a large segment
> (likely the majority) of the user base.  I would not like to do
> that.

I agree with this, Java 6 is important for now (but of course it will
not be true anymore in a few years). So I veto my own proposal.

> So if we don't have the energy to maintain two lines, I would
> say hold off requiring Java 7 until we have stabilized the API and
> fixed things like above.

Then I think Gilles proposal to have an experimental version is the best
way to go. This could be done exactly as was done for the BSP trees: a
sandbox component is started (Gilles can do that as any commons
committer can start a new sandbox component) and experiment with Java 7
for some parallel algorithms (which may duplicate algorithms already in
[math] or be totally different and even address other use cases).

The decision about merging [math-MT] and [math] later on can be
postponed until the component is mature enough. If we decide to merge
them, it will be a new major version that could require Java 7. If we
decide not to merge, the Java version used for [math] would be
independent (but could also be Java 7 due to other needs that may arise).

This does not mean we ignore large scale problems, it simply means we
also explore the way Gilles suggest.

Konstantin, it would be nice if you could contribute some concrete ideas
and code if possible. As you have seen, we lack contributors in several
domains and this has led us to do some mistakes. Help is welcome.

best regards,
Luc

> 
> Phil
>>
>> best regards,
>> Luc
>>
>>> On Feb 7, 2013, at 5:06 PM, Gilles  wrote:
>>>
 On Thu, 07 Feb 2013 08:32:46 -0800, Phil Steitz wrote:
> On 2/7/13 8:04 AM, Gilles wrote:
>> On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote:
>>> On 2/7/13 4:58 AM, Gilles wrote:
 On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote:
> On 2/6/13 9:03 AM, Gilles wrote:
>> On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote:
>>> On 2/5/13 6:08 AM, Gilles wrote:
 Hi.

 In the thread about "static import", Stephen noted that
 decisions
 on a
 component's evolution are dependent on whether the future of
 the
 Java
 language is taken into account, or not.
 A question on the same theme also arose after the
 presentation of
 Commons
 Math in FOSDEM 2013.

 If we assume that efficiency is among the important
 qualities for
 Commons
 Math, the future is to allow usage of the tools provided by the
 standard
 Java library in order to ease the development of multi-threaded
 algorithms.

 Maintaining Java 1.5 source compatibility for the reason
 that we
 may need
 to support legacy applications will turn out to be
 self-defeating:
 1. New users will not consider Commons Math's features that are
 notably
   apt to parallel processing.
 2. Current users might at some point simply switch to another
 library if
   it proves more efficient (because it actually uses
 multi-threading).
 3. New Java developers will be turned away because they will
 want
 to use
   the more convenient features of the language in order to
 provide
   potential contributions.

 If maintaining 1.5 source compatibility is kept as a
 requir

Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

[Benedikt Ritter]

Hi,


2013/2/8 Duncan Jones 

> In this specific case, I think a "..., not null" caveat is sufficient.
> But in the general case, I think documenting interesting runtime
> exceptions in the javadoc is good practice.

Okay, I guess that's what we will do with the BeanReflectionException base
class.


> Does the CheckStyle config
> need tweaking?
>
I think so. I'll try to have a look ASAP.

thanks!
Benedikt


>
> On 8 February 2013 08:26, Benedikt Ritter  wrote:
> > Hi Simo,
> >
> >
> > 2013/2/8 Simone Tripodi 
> >
> >> > How do you feel about this? Checkstyle complains about this, and I
> think
> >> it
> >> > is sufficient to tell users that an argument must not be null.
> >>
> >> sorry, which one?
> >>
> >
> > should have made that clearer :)
> > I removed the @throws NullpointerException from the JavaDoc because check
> > style complains about this (NPE is not declared in the method's
> signature).
> > I think it is enough to tell users that an argument must not be null.
> WDYT?
> >
> > Benedikt
> >
> >
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VFS] Support for File System Roots?

[Mark Fortner]

Gary,
I'm not aware of the tilde being used for any other purpose in any other
file system. If a user had specified a directory like "~/mu~noz" as a home
directory it should resolve to the appropriate directory i.e. "/mu~noz".

As for it being optional on a per file system basis, I suppose that's
possible. Is there a way of storing/registering file system configurations
(ala Spring Context)?

I hadn't really thought about it's use for other file systems.  Merely for
use with the local file system.  How would you use this in a distributed
file system?  What would happen if the remote file system did not have a
home directory (or equivalent) for the current user?

Mark

Cheers,

Mark



On Sun, Jan 6, 2013 at 10:24 PM, Gary Gregory wrote:

> Ok, that sounds interesting. Can you give us some examples? I sounds like
> it makes sense for file:// only. Did you have it in mind for other file
> systems?
>
> Should the treatment of '~' be optional? Is there a chance of it being
> confused with any kind of legal file reference on any OS?
>
> Gary
>
>
> On Sun, Jan 6, 2013 at 7:50 PM, Mark Fortner  wrote:
>
> > Gary,
> > The File#getRoots() method that you mentioned gets the file system roots
> > and not user-specific directories like Documents, Downloads, Photos,
> Music,
> > etc.
> >
> > I ended up creating a solution with maps of directories for each
> operating
> > system (or relevant OS version in the case of Windows).  I also
> implemented
> > a solution for resolving "~" as the home directory in URLs.  I can check
> > these into my project and send you the URLs for the files if you're
> > interested.
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> > On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb <
> > roger.whitc...@actian.com
> > > wrote:
> >
> > > I'm actually working on a similar project to make a new version of the
> > > Apache Pivot File Browser to use VFS.  So, I'd also be interested to
> see
> > > what suggestions the developers here have.
> > >
> > > ~Roger Whitcomb
> > >
> > > -Original Message-
> > > From: Mark Fortner [mailto:phidia...@gmail.com]
> > > Sent: Friday, December 28, 2012 11:54 AM
> > > To: Commons Developers List
> > > Subject: Re: [VFS] Support for File System Roots?
> > >
> > > Hi Gary,
> > > This would be per operating system.  So, if I call
> > > *RootFactory.getRoot(RootNames.HOME)
> > > *from a Linux box, that would resolve to */home/*, on a
> > > Windows box that might be */Users/*.  It would be driven by
> > > the *
> > > System.getProperty("user.home")* variable.  The other roots, are OS
> > > dependent and are subdirectories of the home directory.  You might also
> > > have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
> > > let you get the value for Linux, even if you aren't on a Linux box.
> > >
> > > The URIs might look like "/Documents" which would resolve to
> > > "file:///home//Documents".
> > >
> > > This came up because I'm reworking a Swing file manager using JavaFX
> and
> > > I wanted to clean up the API some and minimize any VFS specific
> > > workarounds I was doing.
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > >
> > >
> > > On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
> > > wrote:
> > >
> > > > Would this only be for Windows? What do URIs look like?
> > > >
> > > > Gary
> > > >
> > > > On Dec 28, 2012, at 14:18, Mark Fortner  wrote:
> > > >
> > > > > I was wondering if there were any plans (or currently any way) to
> > > > > support File System Roots.  In addition to the standard sorts of
> > > > > roots, there are roots like your home directory, the Documents,
> > > > > Photos, Music, Downloads, etc.
> > > > >
> > > > > At a minimum it would be useful to have an Enum of the different
> > > > directory
> > > > > names, with some way of resolving them.  Something like:
> > > > >
> > > > > FileObject root = RootFactory.getRoot(RootNames.HOME);
> > > > >
> > > > > and
> > > > >
> > > > > Map rootMap = RootFactory.getRoots();
> > > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Mark
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>