spotBugs and JDK-8194978: Javac produces dead code for try-with-resource
Ismael Juma
mlists at juma.me.uk
Fri Nov 9 15:22:29 UTC 2018
Any comments on this? Many people are disabling spotBugs when compiling
with Java 11 due to this issue:
https://github.com/spotbugs/spotbugs/issues/756
Ismael
On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma <mlists at juma.me.uk> wrote:
> Hi all,
>
> JDK-8194978 introduced some changes to the bytecode generated by javac for
> the try with resource construct. In the following code, it seems to
> generate a null check on a reference after invoking a method on it:
>
> public static void readFileAsString(String path) throws IOException {
> try (FileChannel fc = FileChannel.open(Paths.get(path))) {
> fc.size();
> }
>
> }
>
> In line 16 to 22 of the bytecode, it looks like we check for null after
> calling a method on the fc reference:
>
> 16: aload_1
> 17: invokevirtual #6 // Method
> java/nio/channels/FileChannel.size:()J
> 20: pop2
> 21: aload_1
> 22: ifnull 52
> 25: aload_1
> 26: invokevirtual #7 // Method
> java/nio/channels/FileChannel.close:()V
>
> Is this intentional? I ask because this pattern triggers a spotBugs
> warning since it often implies a bug in user's code:
>
> RCN | Nullcheck of fc at line 10 of value previously dereferenced in
> TryTest.readFileAsString(String, Charset)
>
> Note that this works fine in Java versions older than Java 11. Since this
> spotBugs warning is generally useful, it would be handy if javac did not
> trigger it. Alternatively, if there's a good way to detect the code that
> was generated by javac, spotBugs could be updated to ignore it. For
> reference, this was discussed in the spotBugs issue tracker:
>
> https://github.com/spotbugs/spotbugs/issues/756
>
> And method bytecode in full:
>
> public static void readFileAsString(java.lang.String) throws
> java.io.IOException;
> Code:
> 0: aload_0
> 1: iconst_0
> 2: anewarray #2 // class java/lang/String
> 5: invokestatic #3 // Method
> java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;
> 8: iconst_0
> 9: anewarray #4 // class
> java/nio/file/OpenOption
> 12: invokestatic #5 // Method
> java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel;
> 15: astore_1
> 16: aload_1
> 17: invokevirtual #6 // Method
> java/nio/channels/FileChannel.size:()J
> 20: pop2
> 21: aload_1
> 22: ifnull 52
> 25: aload_1
> 26: invokevirtual #7 // Method
> java/nio/channels/FileChannel.close:()V
> 29: goto 52
> 32: astore_2
> 33: aload_1
> 34: ifnull 50
> 37: aload_1
> 38: invokevirtual #7 // Method
> java/nio/channels/FileChannel.close:()V
> 41: goto 50
> 44: astore_3
> 45: aload_2
> 46: aload_3
> 47: invokevirtual #9 // Method
> java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V
> 50: aload_2
> 51: athrow
> 52: return
> Exception table:
> from to target type
> 16 21 32 Class java/lang/Throwable
> 37 41 44 Class java/lang/Throwable
>
> Thanks,
> Ismael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181109/23fe1aa6/attachment.html>
More information about the compiler-dev
mailing list