spotBugs and JDK-8194978: Javac produces dead code for try-with-resource (original) (raw)
Ismael Juma mlists at juma.me.uk
Fri Nov 9 15:22:29 UTC 2018
- Previous message: RFR: 8211450: UndetVar::dup is not copying the kind field to the duplicated instance
- Next message: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: aload1 17: invokevirtual #6 // Method java/nio/channels/FileChannel.size:()J 20: pop2 21: aload1 22: ifnull 52 25: aload1 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: aload0 1: iconst0 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: iconst0_ _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: astore1_ _16: aload1_ _17: invokevirtual #6 // Method_ _java/nio/channels/FileChannel.size:()J_ _20: pop2_ _21: aload1_ _22: ifnull 52_ _25: aload1_ _26: invokevirtual #7 // Method_ _java/nio/channels/FileChannel.close:()V_ _29: goto 52_ _32: astore2_ _33: aload1_ _34: ifnull 50_ _37: aload1_ _38: invokevirtual #7 // Method_ _java/nio/channels/FileChannel.close:()V_ _41: goto 50_ _44: astore3_ _45: aload2_ _46: aload3_ _47: invokevirtual #9 // Method_ _java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V_ _50: aload2_ _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>
- Previous message: RFR: 8211450: UndetVar::dup is not copying the kind field to the duplicated instance
- Next message: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]