# Wednesday, 29 October 2014
New Development Snapshot

I've been busy with other things, but there have been enough fixes to warrant a new snapshot.

Changes:

  • Bug fix. When reading a .class resource from an assembly (to attempt to dynamically define it), read all the bytes.
  • Bug fix. Reading/writing java.nio.file attributes of non-existing file should throw NoSuchFileException.
  • Bug fix. Fixed bitmap synchronization in java.awt.image.BufferedImage and com.sun.imageio.plugins.jpeg.JPEGImageWriter.
  • Ignore -Xmn and -XX: Oracle Java specific command line options in ikvm.exe.
  • Enabled pack200 unpacking algorithm.
  • IKVM.Reflection: Bug fix. If custom attribute named argument parsing fails due to missing type, ConstructorArguments should still work.

Binaries available here: ikvmbin-8.0.5415.zip

Wednesday, 29 October 2014 13:24:17 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
# Wednesday, 16 July 2014
Java Method Overriding Is FUBAR Part 10 of ∞

Yesterday's JDK 7u65 and 8u11 updates changed method overriding yet again and, of course, it is still broken.

Take this example:

package pkg1;

public class A {
  { foo(); }
  void foo() { System.out.println("A.foo"); }
}

package pkg2;

public class B extends pkg1.A {
  { foo(); }
  void foo() { System.out.println("B.foo"); }
}

package pkg1;

public class C extends pkg2.B {
  { foo(); }
  void foo() { System.out.println("C.foo"); }
}

package pkg2;

public class D extends pkg1.C {
  { foo(); }
  void foo() { System.out.println("D.foo"); }
}

public class test {
  public static void main(String[] args) {
    new pkg2.D();
  }
}

Running this with JDK 8u5 yields:

D.foo
D.foo
D.foo
D.foo

Which is, of course, wrong. In yesterday's updates they tried to fix this, but only partially succeeded:

D.foo
D.foo
C.foo
D.foo

The sensible output would be:

C.foo
D.foo
C.foo
D.foo

Wednesday, 16 July 2014 13:27:41 (W. Europe Daylight Time, UTC+02:00)  #    Comments [2]
Java Security Fixes

In Februari I reported two Java vulnerabilities to Oracle. Yesterday they released the update that fixed them, so here are the descriptions of the two issues.

@java.lang.invoke.LambdaForm.Compiled

Internally, the JDK uses the LambdaForm.Compiled annotation to mark methods that should be skipped in a security stack walk. In JDK 7 it was possible to apply this annotation to untrusted code. Here's an example:

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@interface java_lang_invoke_LambdaForm$Compiled { }

class test {
  @java_lang_invoke_LambdaForm$Compiled
  public static void main(String[] args) throws Throwable {
    System.out.println(Class.forName("sun.misc.Unsafe"));
  }
}

If you compile and run this with JDK 1.7.0_60 with a security manager, you get the appropriate AccessControlException. However, if you edit test.class to replace java_lang_invoke_LambdaForm with java/lang/invoke/LambdaForm and run it again, you see that the main method is now skipped in the security check and hence is allowed to access a privileged class.

The fix can be seen here.

MaxArityBug

This example demonstrates that the JDK 1.7.0_60 LambdaForm method handle implementation has a type safety bug when dealing with method signatures with the maximum number of parameters.

Wednesday, 16 July 2014 08:53:16 (W. Europe Daylight Time, UTC+02:00)  #    Comments [2]
# Sunday, 13 July 2014
Blog Update

I updated my ancient version of dasBlog. Please let me know if something isn't working properly.

Sunday, 13 July 2014 10:18:00 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Friday, 11 July 2014
New Development Snapshot

Completed LambdaMetafactory intrinsification.

Changes:

  • Fixed several LambdaMetafactory.metafactory() intrinsic bug.
  • Implemented LambdaMetafactory.altMetafactory() intrinsic.
  • Include full class name of anonymous classes in stack trace.
  • Added method and field reflection support for lambda classes.

Binaries available here: ikvmbin-8.0.5305.zip

Friday, 11 July 2014 10:08:05 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]