On 20 June 2015 at 06:39, Kristian Rosenvold
<kristian.rosenv...@gmail.com> wrote:
> 2015-06-19 21:01 GMT+02:00 sebb <seb...@gmail.com>:
>
>> On 19 June 2015 at 19:00, <krosenv...@apache.org> 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
