Re: porting fixes to v 3.2.X

[Thomas Neidhart]

On 06/19/2015 05:41 PM, Marc-André Chartrand wrote:
> Can bug fixes from version 4.0 be ported to v 3.2.X ?   and also, when is
> the next 3.2.X version coming out ?
> 
> The fix I'm looking at in particular is :
> 
> https://issues.apache.org/jira/browse/COLLECTIONS-294
> 
> Which is only fixed in 4.0 apparently.
> 

Currently, there are no plans to release another 3.x version.

Imho, a 3.2.2 release would only make sense if we really fix a
considerable amount of known bugs present in the 3.2.1 release, but this
would mean a lot of work.

If a *big corp* would sponsor a few working days, I could imagine that a
new release is feasible, otherwise try switching to collections 4 which
has fixed all known bugs in the 3.x branch.

btw. collections 3 and 4 can be used at the same time as they use
different package names.

Thomas

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

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[sebb]

On 20 June 2015 at 06:39, Kristian Rosenvold
 wrote:
> 2015-06-19 21:01 GMT+02:00 sebb :
>
>> On 19 June 2015 at 19:00,   wrote:
>> > +class Java7Support
>> > +{
>> > +
>> > +private static final boolean IS_JAVA7;
>> > +
>> > +private static Method isSymbolicLink;
>> > +
>> > +private static Method delete;
>> > +
>> > +private static Method toPath;
>> > +
>> > +private static Method exists;
>> > +
>> > +private static Method toFile;
>> > +
>> > +private static Method readSymlink;
>> > +
>> > +private static Method createSymlink;
>> > +
>> > +private static Object emptyLinkOpts;
>> > +
>> > +private static Object emptyFileAttributes;
>>
>> The above should all be final, as for IS_JAVA7
>>
>
> Which means I'd have to rewrite the entire construction block (below) and
> make it all more complex. This whole class is private and will be removed
> once java7 minimum is used. I'm not entirely sure I agree.

Final variables are guaranteed to be safely published across threads.
Is that true for non-final variables if they are established in a static block?

>>
>> > +
>> > +static
>> > +{
>> > +boolean isJava7x = true;
>> > +try
>> > +{
>> > +ClassLoader cl =
>> Thread.currentThread().getContextClassLoader();
>> > +Class files = cl.loadClass( "java.nio.file.Files" );
>> > +Class path = cl.loadClass( "java.nio.file.Path" );
>> > +Class fa = cl.loadClass(
>> "java.nio.file.attribute.FileAttribute" );
>> > +Class linkOption = cl.loadClass(
>> "java.nio.file.LinkOption" );
>> > +isSymbolicLink = files.getMethod( "isSymbolicLink", path );
>> > +delete = files.getMethod( "delete", path );
>> > +readSymlink = files.getMethod( "readSymbolicLink", path );
>> > +
>> > +emptyFileAttributes = Array.newInstance( fa, 0 );
>> > +final Object o = emptyFileAttributes;
>>
>> There seems to be no need to create object o.
>>
> Yep. Removed.
>
>
>>
>> > +createSymlink = files.getMethod( "createSymbolicLink",
>> path, path, o.getClass() );
>> > +emptyLinkOpts = Array.newInstance( linkOption, 0 );
>> > +exists = files.getMethod( "exists", path,
>> emptyLinkOpts.getClass() );
>> > +toPath = File.class.getMethod( "toPath" );
>> > +toFile = path.getMethod( "toFile" );
>> > +}
>> > +catch ( ClassNotFoundException e )
>> > +{
>> > +isJava7x = false;
>> > +}
>> > +catch ( NoSuchMethodException e )
>> > +{
>> > +isJava7x = false;
>> > +}
>> > +IS_JAVA7 = isJava7x;
>> > +}
>> > +
>> > +public static boolean isSymLink( File file )
>> > +{
>> > +try
>> > +{
>> > +Object path = toPath.invoke( file );
>> > +return (Boolean) isSymbolicLink.invoke( null, path );
>>
>> The Boolean should be explicitly converted to boolean.
>>
>
> I'm not sure I understand; the equivalent of
>
> Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
> return result.booleanValue();
>
> Gives a style warning (uneccssary unboxing) in IntelliJ.

That warning is wrong.

Unboxing is clearly necessary here; it's just a question of whether it
is implicit or explicit.

I have seen several cases where implicit boxing was associated with a code bug.
For example, a local variable was defined as Boolean but always used as boolean.

So I always set Eclipse to warn where implicit (un)boxing is occurring.
Yes, it requires a bit more work by the developer, but it ensures that
the (un)boxing really is intentional.

> Is there some other mechanism you're thinking of ?

No.

>
> Kristian

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

Re: porting fixes to v 3.2.X

[Marc-Andre Chartrand]

Thanks.   I was wondering why the package names changed. I guess you just gave 
1 reason. 

Marc


> On Jun 21, 2015, at 4:55 AM, Thomas Neidhart  
> wrote:
> 
>> On 06/19/2015 05:41 PM, Marc-André Chartrand wrote:
>> Can bug fixes from version 4.0 be ported to v 3.2.X ?   and also, when is
>> the next 3.2.X version coming out ?
>> 
>> The fix I'm looking at in particular is :
>> 
>> https://issues.apache.org/jira/browse/COLLECTIONS-294
>> 
>> Which is only fixed in 4.0 apparently.
> 
> Currently, there are no plans to release another 3.x version.
> 
> Imho, a 3.2.2 release would only make sense if we really fix a
> considerable amount of known bugs present in the 3.2.1 release, but this
> would mean a lot of work.
> 
> If a *big corp* would sponsor a few working days, I could imagine that a
> new release is feasible, otherwise try switching to collections 4 which
> has fixed all known bugs in the 3.x branch.
> 
> btw. collections 3 and 4 can be used at the same time as they use
> different package names.
> 
> Thomas
> 
> -
> 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: [io] svn commit r1686512

[sebb]

Oops, sorry about that.

Not sure why I overlooked that the test code needs package access.

On 20 June 2015 at 09:36, Kristian Rosenvold  wrote:
> I reverted some of the package protected -> private changes, since the
> tests did not even compile with this change.
>
> Kristian

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

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 13:43 GMT+02:00 sebb :
>
> Final variables are guaranteed to be safely published across threads.
> Is that true for non-final variables if they are established in a static
> block?
>

Yes. All static blocks are guranteed to be visible (all class
initialization is basically a synchronized operation for that class) and as
long as they're effectively immutable it does not really matter. Style wise
I would personally also prefer to make them final, but that would actually
increase the overall footprint of the code somewhat (believe me, I tried
when I initially wrote this code...)

So I think this code is nicer, but it's really only a very subtle
preference and I'm definitely not married to this way of doing it :)

>
> > Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
> > return result.booleanValue();
> >
> > Gives a style warning (uneccssary unboxing) in IntelliJ.
>
> That warning is wrong.


> Unboxing is clearly necessary here; it's just a question of whether it
> is implicit or explicit.


> I have seen several cases where implicit boxing was associated with a code
> bug.
> For example, a local variable was defined as Boolean but always used as
> boolean.
>
> So I always set Eclipse to warn where implicit (un)boxing is occurring.
> Yes, it requires a bit more work by the developer, but it ensures that
> the (un)boxing really is intentional.
>
> > Is there some other mechanism you're thinking of ?
>
> No.
>
> >
> > Kristian
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [io] How picky about backward compatibility ?

[sebb]

The Javadoc for the two constructors says:

>>
org.apache.commons.io.input.BrokenInputStream.BrokenInputStream(IOException
exception)

Creates a new stream that always throws the given exception.

Parameters:
exception the exception to be thrown
<<

and

>>
org.apache.commons.io.input.BrokenInputStream.BrokenInputStream()

Creates a new stream that always throws an IOException
<<

Similarly for the Output version of the class.

In the first case, it is clear that the same exception is thrown.
Though it does not explicitly say that the same *instance* is thrown.

The second case is less clear; it could be argued that any IOE would do.

So I agree that the original patch changed the behaviour in a way that
is contrary to the Javadoc and needed to be reverted.

I think it also broke the behaviour in another way - if the user
provided a sub-class of IOE, close() also ought to throw the same
subclass.

However, it does make sense for the classes to be usable with
try-with-resources.

One possible approach without breaking the behaviour would be to use a
separate close IOE field, and only populate it for the default
constructor.
However that is a bit of a cheat.

Another might be to add a new ctor which has a separate IOE parameter
for the close method.

Is there a genuine use-case which requires that the same IOE instance
be used? (Other than the unit tests!)
If not, then we could look into relaxing the behaviour (and fixing the
Javadoc) for a future release.
If there is a use-case for always using the same instance, then
providing an additional ctor would work.


On 20 June 2015 at 16:58, Gary Gregory  wrote:
> I'd like to look at the change but I get an "Invalid revision" when I click
> on the link.
>
> Do you have a diff or another link?
>
> Gary
>
> On Fri, Jun 19, 2015 at 10:48 PM, Kristian Rosenvold 
> wrote:
>
>> I reverted the fix in
>> http://svn.apache.org/viewvc?view=revision&revision=r1686456 simply
>> because
>> it broke backward compatibility in a subtle way. The BrokenNNStream classes
>> supply the same instance of the IOException on all methods (and there are
>> tests that assert it)
>>
>> Given some of the discussions I've seen about backward compatibility here,
>> I felt it best to revert (even though API-wise I feel this change is within
>> reasonable even for a minor release). WDYT ?
>>
>> Kristian
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 13:43 GMT+02:00 sebb :

>
> > I'm not sure I understand; the equivalent of
> >
> > Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
> > return result.booleanValue();
> >
> > Gives a style warning (uneccssary unboxing) in IntelliJ.
>
> That warning is wrong.
>
> Unboxing is clearly necessary here; it's just a question of whether it
> is implicit or explicit.
>
> I have seen several cases where implicit boxing was associated with a code
> bug.
> For example, a local variable was defined as Boolean but always used as
> boolean.
>

This makes me curious; the only bug I know of in this context is the clasic
NPE you can get in the automatic unboxing. Is there some other scenario
you're thinking of ?  (Uneccessary object allocation is obvious and
something we try to avoid but hardly a bug. In this case I also think the
object is unavoidable...)

Kristian

Re: [io] How picky about backward compatibility ?

[Kristian Rosenvold]

2015-06-21 14:16 GMT+02:00 sebb :
>
>
> Is there a genuine use-case which requires that the same IOE instance
> be used? (Other than the unit tests!)
> If not, then we could look into relaxing the behaviour (and fixing the
> Javadoc) for a future release.
> If there is a use-case for always using the same instance, then
> providing an additional ctor would work.
>
>
As far as I can understand the entire use case for this class is for
testing purposes. hashCode/equals for IOException use the "Object" version.
So any client code that uses == or equals on the thrown exception will
fail. But I really believe this class is designed to provoke a specific
exception behaviour in a testcase. I am not entirely convinced there is
much real-life code that actually would assertSame or assertEquals on the
actual exception thrown. So my personal preference is basically to make it
a documented behavioural change.

Kristian

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[sebb]

On 21 June 2015 at 13:24, Kristian Rosenvold
 wrote:
> 2015-06-21 13:43 GMT+02:00 sebb :
>
>>
>> > I'm not sure I understand; the equivalent of
>> >
>> > Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
>> > return result.booleanValue();
>> >
>> > Gives a style warning (uneccssary unboxing) in IntelliJ.
>>
>> That warning is wrong.
>>
>> Unboxing is clearly necessary here; it's just a question of whether it
>> is implicit or explicit.
>>
>> I have seen several cases where implicit boxing was associated with a code
>> bug.
>> For example, a local variable was defined as Boolean but always used as
>> boolean.
>>
>
> This makes me curious; the only bug I know of in this context is the clasic
> NPE you can get in the automatic unboxing. Is there some other scenario
> you're thinking of ?  (Uneccessary object allocation is obvious and
> something we try to avoid but hardly a bug. In this case I also think the
> object is unavoidable...)

IMO it is a bug to write code that uses unnecessary (un)boxing.
Not a very serious bug in general, though it might well have a
performance impact if done repeatedly.

There was another scenario which I came across a while ago.
Unfortunately I did not keep a note of it, but IIRC it was not just a
performance/NPE issue

> Kristian

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

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 14:53 GMT+02:00 sebb :

> On 21 June 2015 at 13:24, Kristian Rosenvold
>  wrote:
> > 2015-06-21 13:43 GMT+02:00 sebb :
> >
> >>
> >> > I'm not sure I understand; the equivalent of
> >> >
> >> > Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
> >> > return result.booleanValue();
> >> >
> >> > Gives a style warning (uneccssary unboxing) in IntelliJ.
> >>
> >> That warning is wrong.
> >>
> >> Unboxing is clearly necessary here; it's just a question of whether it
> >> is implicit or explicit.
> >>
> >> I have seen several cases where implicit boxing was associated with a
> code
> >> bug.
> >> For example, a local variable was defined as Boolean but always used as
> >> boolean.
> >>
> >
> > This makes me curious; the only bug I know of in this context is the
> clasic
> > NPE you can get in the automatic unboxing. Is there some other scenario
> > you're thinking of ?  (Uneccessary object allocation is obvious and
> > something we try to avoid but hardly a bug. In this case I also think the
> > object is unavoidable...)
>
> IMO it is a bug to write code that uses unnecessary (un)boxing.
> Not a very serious bug in general, though it might well have a
> performance impact if done repeatedly.
>

But there is no unnecessary unboxing here, hence no bug. I work on way too
many projects with way too many code styles to care about arguing these
matters. If old-style explicit unboxing is how you want it around here,
that's what I'll write.



> There was another scenario which I came across a while ago.
> Unfortunately I did not keep a note of it, but IIRC it was not just a
> performance/NPE issue
>

That would be interesting to hear about if you remember. Selection of
different overloads is the only one I can think of.

Kristian

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[sebb]

On 21 June 2015 at 14:16, Kristian Rosenvold
 wrote:
> 2015-06-21 14:53 GMT+02:00 sebb :
>
>> On 21 June 2015 at 13:24, Kristian Rosenvold
>>  wrote:
>> > 2015-06-21 13:43 GMT+02:00 sebb :
>> >
>> >>
>> >> > I'm not sure I understand; the equivalent of
>> >> >
>> >> > Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
>> >> > return result.booleanValue();
>> >> >
>> >> > Gives a style warning (uneccssary unboxing) in IntelliJ.
>> >>
>> >> That warning is wrong.
>> >>
>> >> Unboxing is clearly necessary here; it's just a question of whether it
>> >> is implicit or explicit.
>> >>
>> >> I have seen several cases where implicit boxing was associated with a
>> code
>> >> bug.
>> >> For example, a local variable was defined as Boolean but always used as
>> >> boolean.
>> >>
>> >
>> > This makes me curious; the only bug I know of in this context is the
>> clasic
>> > NPE you can get in the automatic unboxing. Is there some other scenario
>> > you're thinking of ?  (Uneccessary object allocation is obvious and
>> > something we try to avoid but hardly a bug. In this case I also think the
>> > object is unavoidable...)
>>
>> IMO it is a bug to write code that uses unnecessary (un)boxing.
>> Not a very serious bug in general, though it might well have a
>> performance impact if done repeatedly.
>>
>
> But there is no unnecessary unboxing here, hence no bug.

Exactly, so the IntelliJ warning is wrong.

> I work on way too
> many projects with way too many code styles to care about arguing these
> matters. If old-style explicit unboxing is how you want it around here,
> that's what I'll write.
>
>
>
>> There was another scenario which I came across a while ago.
>> Unfortunately I did not keep a note of it, but IIRC it was not just a
>> performance/NPE issue
>>
>
> That would be interesting to hear about if you remember. Selection of
> different overloads is the only one I can think of.

It could have been that.
I'm pretty sure it was a Commons component that had the issue.

> Kristian

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

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 16:14 GMT+02:00 sebb :

>
> > But there is no unnecessary unboxing here, hence no bug.
>
> >Exactly, so the IntelliJ warning is wrong.
>
> No. I added the redundant call back since that's the way you seem to
prefer round here.

Kristian

VOTE (lazy consensus) Commons Parent 38 from RC2

[sebb]

Hello All,

The Apache Commons Parent POM provides common settings for all Apache
Commons components.


This is a VOTE to release Commons Parent 38 from RC2.

The main reason for this release is to fix the bug in site.xml
discovered recently.

This VOTE by LAZY-CONSENSUS is open for at least 72 hours until

June 24 16:00 UTC.


Changes in this version include:

Changes:
o   Fix URL for Security link
o   Update Assembly Plugin : 2.5.3 => 2.5.5
o   Update Cobertura Plugin : 2.6 => 2.7
o   Update Jacoco Plugin : 0.7.2 => 0.7.4
o   Update Javadoc Plugin : 2.10.1 => 2.10.2
o   Update Surefire Plugin : 2.18 => 2.18.1

The files:
 https://repository.apache.org/content/repositories/orgapachecommons-1100/

/org/apache/commons/commons-parent/38/commons-parent-38.pom
(SHA1: b1fe2a39dc1f76d14fbc402982938ffb5ba1043a)

/org/apache/commons/commons-parent/38/commons-parent-38-site.xml
(SHA1: 4d6ee815f328527d2cf5319c0f7a00414ef1ffab)

KEYS:
http://www.apache.org/dist/commons/KEYS

The tag:

https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-38-RC2/
  Revision:  1686733

The site: None.

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

Need permissions to make release....

[Kristian Rosenvold]

As already mentioned, I'm missing jira permissions. I'm also missing
permissions to add my key to the KEYS file (my key is in
https://dist.apache.org/repos/dist/release/maven/KEYS is someone wants to
do this)

I also suspect that I'll fully be lacking any permissions to publish to
repository.apache.org.

I can commit, but I suspect i need an extra "er" to be able to do releases
properly :)

K

[ALL] re-organise dist directory layout?

[sebb]

I wonder whether the current directory layout is the most convenient.

At present, binaries and source are held in separate areas, and all
versions of each type are combined.

I think it might simplify matters to use a single directory per
version, with both source and binary together.

The current arrangement makes it a bit awkward when uploading the
files, as the different files have to be moved into the appropriate
folders. It also makes it awkward to delete obsolete versions, and
harder to rename files from the dist/dev to the dist/release area.
It's also a bit more awkard when checking releases, as two directorie
have to be downloaded.

Changing the mirror layout would not affect people using the download pages.
It would look a bit different for users who browse the mirror folders,
but this will be a small minority of users, and it's pretty easy to
distinguish the source archives from the binary ones.

Thoughts?

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

Re: svn commit: r1686747 [1/3] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/filefilter/ main/java/org/apache/commons/io/input/ main/java/org/apac

[sebb]

On 21 June 2015 at 19:44,   wrote:
> Author: krosenvold
> Date: Sun Jun 21 18:44:49 2015
> New Revision: 1686747
>
> URL: http://svn.apache.org/r1686747
> Log:
> Fixed all checkstyle errors and a findbugs error
>

What was the Findbugs error?

Best not to mix these in a single commit.

Also looks like many of the checkstyle fixes are just line-wraps; I
thought we allowed a longer line length?
Screens tend to be used in landscape mode so it's easier to read code
if is not wrapped unnecessarily

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

[MATH] Is Math 2.2 still current?

[sebb]

The Math download page still lists 2.2 (Java 1.5+)

However it also lists 3.5 (Java 1.5+)

Do we really still intend to develop the 2.x line?

If not, it ought to be removed from the download page and the mirrors.

There are also a lot of other old Math3 versions on the mirrors.
The Math RMs have not been tidying up after new releases ...

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

RE: [ALL] re-organise dist directory layout?

[Gary Gregory]

I'm OK with a different layout.
Gary 

 Original message 
From: sebb  
Date: 06/21/2015  17:09  (GMT-08:00) 
To: dev@commons.apache.org 
Subject: [ALL] re-organise dist directory layout? 

I wonder whether the current directory layout is the most convenient.

At present, binaries and source are held in separate areas, and all
versions of each type are combined.

I think it might simplify matters to use a single directory per
version, with both source and binary together.

The current arrangement makes it a bit awkward when uploading the
files, as the different files have to be moved into the appropriate
folders. It also makes it awkward to delete obsolete versions, and
harder to rename files from the dist/dev to the dist/release area.
It's also a bit more awkard when checking releases, as two directorie
have to be downloaded.

Changing the mirror layout would not affect people using the download pages.
It would look a bit different for users who browse the mirror folders,
but this will be a small minority of users, and it's pretty easy to
distinguish the source archives from the binary ones.

Thoughts?

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

Re: svn commit: r1686747 [1/3] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/filefilter/ main/java/org/apache/commons/io/input/ main/java/org/apac

[Kristian Rosenvold]

2015-06-22 2:53 GMT+02:00 sebb :

> >What was the Findbugs error?
>
> Best not to mix these in a single commit.
>
Sorry about that.

org.apache.commons.io.output.DeferredFileOutputStream#thresholdReached
possible file handle leak upon exception



>
> Also looks like many of the checkstyle fixes are just line-wraps; I
> thought we allowed a longer line length?
> Screens tend to be used in landscape mode so it's easier to read code
> if is not wrapped unnecessarily
>

Most of it is just feeding the OCD. 0 checkstyle errors is the one ring to
rule them all :)

Would it make sense to change the checkstyle column width to something like
160 ?

Kristian

Re: Apache Commons Configuration & Bean Scripting Framework (BSF) - dependencies on JDK-Internal APIs

[Rory O'Donnell]

Hi Rony,

Thanks for that!

Rgds,Rory

On 20/06/2015 17:27, Rony G. Flatscher (Apache) wrote:

Hi Rory,

just ran "jdeps -jdkinternals" on both, BSF 2.4.0 and BSF 3.1, both have no 
internal dependencies.

Best regards,

---rony



On 15.06.2015 14:19, Rony G. Flatscher (Apache) wrote:

On 15.06.2015 10:04, Rory O'Donnell wrote:

Hi Benedict,

I'm contacting you in relation to Apache Commons Configuration & Bean Scripting 
Framework (BSF),
both projects seems to be  very popular dependencies for other open source 
projects.

As part of the preparations for JDK 9, Oracle’s engineers have been analyzing 
open source projects
like yours to understand usage. One area of concern involves identifying 
compatibility problems,
such as reliance on JDK-internal APIs.

Our engineers have already prepared guidance on migrating some of the more 
common usage patterns
of JDK-internal APIs to supported public interfaces.  The list is on the 
OpenJDK wiki [0].

As part of the ongoing development of JDK 9, I would like to inquire about your 
usage of
JDK-internal APIs and to encourage migration towards supported Java APIs if 
necessary.

The first step is to identify if your application(s) is leveraging internal 
APIs.

/Step 1: Download JDeps. /

Just download a preview release of JDK8(JDeps Download
). You do not need to actually
test or run your application on JDK8. JDeps(Docs
)
looks through JAR files and identifies which JAR files use internal
APIs and then lists those APIs.

/Step 2: To run JDeps against an application/. The command looks like:

jdk8/bin/jdeps -P -jdkinternals *.jar > your-application.jdeps.txt

The output inside your-application.jdeps.txt will look like:

your.package (Filename.jar)
   -> com.sun.corba.seJDK internal API (rt.jar)

_3rd party library using Internal APIs:_
If your analysis uncovers a third-party component that you rely on, you can 
contact the provider
and let them know of the upcoming changes. You can then either work with the 
provider to get an
updated library that won't rely on Internal APIs, or you can find an 
alternative provider for the
capabilities that the offending library provides.

_Dynamic use of Internal APIs:_
JDeps can not detect dynamic use of internal APIs, for example through 
reflection, service loaders
and similar mechanisms.

Rgds,Rory

[0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool


Maybe a few remarks: there are two different packages, one BSF 2.x and one BSF 
3.x. BSF 2.x is an
opensource scripting framework for Java, BSF 3.x is an Apache implementation of 
JSR-223
(javax.script, which was influenced by BSF 2.x). The Java baseline is 1.4, if I 
am not mistaken,
such that pre Java 1.6 (when javax.script appeared for the first time) 
installations could use
either framework. BSF 3.x uses the package name "javax.script" such that 
starting with Java 1.6, due
to the class loading rules, the Java supplied "javax.script" will be found and 
used, even if BSF 3
is installed.

Having said that, I would plan to analyze at least BSF 2.x (and also apply a few, 
"last" updates,
including supplying a "javax.script.BSF ScriptEngine" implementation to ease 
creating a javax.script
ScriptEngine for BSF 2.x script engines, as there may be som BSF 2.x scripting 
languages that could
be then deployed via the javax.script framework) with jdeps. In case it is using 
"JDK-internal APIs"
it will be interesting to learn whether (and how) one could use different APIs 
that are available in
the 1.4 world (unless we lift that baseline to Java 7 or 8).

---rony





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



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


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