GNU Classpath

I wrote a quick fuzzer for libiberty’s demangler this morning. Here’s how to get and use it: $ mkdir workdir $ cd workdir $ git clone [email protected]:gbenson/binutils-gdb.git src ... $ cd src $ git co demangler $ cd .. $ mkdir build $ cd build $ ... [More] CFLAGS="-g -O0" ../src/configure --with-separate-debug-dir=/usr/lib/debug ... $ make ... $ ../src/fuzzer.sh ... + /home/gary/workdir/build/fuzzer ../src/fuzzer.sh: line 12: 22482 Segmentation fault (core dumped) $fuzzer # copy the executable and PID from the two lines above $ gdb -batch /home/gary/workdir/build/fuzzer core.22482 -ex "bt" ... Core was generated by `/home/gary/workdir/build/fuzzer'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000040d5f2 in op_is_new_cast (op=0x7ffffac19930) at libiberty/cp-demangle.c:3064 3064 const char *code = op->u.s_operator.op->code; #0 0x000000000040d5f2 in op_is_new_cast (op=0x7ffffac19930) at libiberty/cp-demangle.c:3064 #1 0x000000000040dc6f in d_expression_1 (di=0x7ffffac19c90) at libiberty/cp-demangle.c:3232 #2 0x000000000040dfbc in d_expression (di=0x7ffffac19c90) at libiberty/cp-demangle.c:3315 #3 0x000000000040cff6 in d_array_type (di=0x7ffffac19c90) at libiberty/cp-demangle.c:2821 #4 0x000000000040c260 in cplus_demangle_type (di=0x7ffffac19c90) at libiberty/cp-demangle.c:2330 #5 0x000000000040cd70 in d_parmlist (di=0x7ffffac19c90) at libiberty/cp-demangle.c:2718 #6 0x000000000040ceb8 in d_bare_function_type (di=0x7ffffac19c90, has_return_type=0) at libiberty/cp-demangle.c:2772 #7 0x000000000040a9b2 in d_encoding (di=0x7ffffac19c90, top_level=1) at libiberty/cp-demangle.c:1287 #8 0x000000000040a6be in cplus_demangle_mangled_name (di=0x7ffffac19c90, top_level=1) at libiberty/cp-demangle.c:1164 #9 0x0000000000413131 in d_demangle_callback (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259, callback=0x40ed11 , opaque=0x7ffffac19d70) at libiberty/cp-demangle.c:5862 #10 0x0000000000413267 in d_demangle (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259, palc=0x7ffffac19dd8) at libiberty/cp-demangle.c:5913 #11 0x00000000004132d6 in cplus_demangle_v3 (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259) at libiberty/cp-demangle.c:6070 #12 0x0000000000401a87 in cplus_demangle (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259) at libiberty/cplus-dem.c:858 #13 0x0000000000400ea0 in main (argc=1, argv=0x7ffffac1a0a8) at /home/gary/workdir/src/fuzzer.c:26 The symbol that crashed it is one frame up from the bottom of the backtrace. [Less]

Java 8 introduces default and static interface methods. Here's an example Java 8 interface: public interface Foo {   default void m1() {     System.out.println("Hello from default ... [More] interface method");   }   static void m2() {     System.out.println("Hello from static interface method");   } } When this interface is compiled by ikvmc,  it produces the approximate equivalent of the following pseudo C# code: public interface Foo {   public static class __DefaultMethods {     public static void m1(Foo obj) {       if (obj == null) throw new NullReferenceException();       Foo.<default>m1(obj);     }   }   public static class __Methods {     public static void m2() {       Foo.m2();     }   }   public static void <default>m1(Foo obj) {     System.out.println("Hello from default interface method");   }   public abstract void m1();   public static void m2() {     System.out.println("Hello from static interface method");   } } There are a number of things going on here, so let's go over them one by one. __DefaultMethods This nested type exists to allow C# code to call the default method implemenation. So when your C# class implements the Foo interface, it may implement the m1 method by calling the default method. The reason it is a nested type is to avoid method name clashes and because the current C# compiler doesn't allow access to static interface members. __Methods This only exists because the current C# compiler doesn't allow access to static interface members (the new Roslyn C# compiler does). It is similar to the nested __Fields type that already exists to expose interface fields. <default>m1 This is a static method that contains the body of the default interface method. Its name is mangled to avoid conflict with the "real" abstract method. Internally ikvmc calls this method when a class inherits the default method. m1 Regular abstract interface method. m2 Regular static method. The result of this implementation choice is that it can be quite painful to implement a Java 8 interface in C#, because you manually have to forward each default method. Given the large number of default methods introduced in Java 8 this is going to make interop quite a bit more inconvenient. A partial workaround for this is to write more interop code in Java or create a Java base class that implements the interface so that it can inherit the default methods and then write the implementation as a C# subclass. I'm considering changing ikvmc to automatically generate a __BaseClass nested type inside all public interfaces to at least make it easy to write a class that implements a single Java interface. JVM interfaces can also have private methods. The current C# compiler doesn't like interfaces with non-public members, so the private methods are put into another nested type by ikvmc (and instance methods are compiled as static methods). [Less]

It was pretty easy to write a new graphical backend for Jainja using the Pepper Plugin API. So it's possible to write Java graphical user interfaces on NaCl now !A demo is available on the Chrome Web Store.

It was pretty easy to write a new graphical backend for Jainja using the Pepper Plugin API. So it's possible to write Java graphical user interfaces on NaCl now !A demo is available on the Chrome Web Store.

It was pretty easy to write a new graphical backend for Jainja using the Pepper Plugin API. So it's possible to write Java graphical user interfaces on NaCl now !A demo is available on the Chrome Web Store.

Bradley M. Kuhn wrote an analysis on the recent Appeals Court Decision in Oracle v. Google. Pointing out who the real winners are and that it will now take years before we will have more clarity: The case is remanded, so a new jury will first sit ... [More] down and consider the fair use question. If that jury finds fair use and thus no infringement, Oracle’s next appeal will be quite weak, and the Appeals Court likely won’t reexamine the question in any detail. In that outcome, very little has changed overall: we’ll have certainty that API’s aren’t copyrightable, as long as any textual copying that occurs during reimplementation is easily called fair use. By contrast, if the new jury rejects Google’s fair use defense, I suspect Google will have to appeal all the way to SCOTUS. It’s thus going to be at least two years before anything definitive is decided, and the big winners will be wealthy litigation attorneys — as usual. You will want to read the whole thing to know why from a copyleft perspective this decision will give that strange feeling of simultaneous annoyance and contentment. [Less]

Orson Charts 3D / Enhanced SVG Export The source version of this blog entry can be found at http://www.object-refinery.com/blog/blog-20140509.html. Overview In April, we released Orson Charts version 1.3. This release brings exciting new interactive ... [More] features, including mouse events that can identify all chart elements (titles, axis labels, legend items, data items, etc.) and provide links back to the chart's source data. This gives developers endless possibilities to create dynamic and interactive visualisations in Java applications, whether it be for item selections, popup info (dialogs and/or tooltips) or drill-down data displays. With Orson Charts 1.3 it is now even easier to let your users explore their data. This post highlights a less visible feature in the 1.3 release---the enhanced SVG export---which also supports interactivity (mouse events and tooltips) for server-side generated charts displayed in modern web browsers. Enhanced SVG Export The enhanced SVG export adds a custom attribute to the SVG elements it generates to identify the chart element (or data item) that the SVG element corresponds to. This custom attribute can be picked up by mouse event handlers in JavaScript to provide interactive features in web clients for charts that are generated on the server-side. This feature is implemented using special rendering hints that get recognised by JFreeSVG but ignored by other Graphics2D implementations. This allows you to use the same code, unchanged, with any output target. In this post, we provide a few examples to illustrate---the source code for these demos is included in the Orson Charts download (you can also view the HTML page source here). Configuration To enable the enhanced SVG export feature, you simply need to call the setElementHinting(boolean) method on your chart instance prior to drawing the chart to the SVGGraphics2D instance provided by JFreeSVG: SVGGraphics2D g2 = new SVGGraphics2D(width, height); chart.setElementHinting(true); chart.draw(g2, new Rectangle(width, height)); return g2.getSVGElement(chart.getID()); That's all that needs to be done in terms of the SVG generation (for an overview of creating a chart using Orson Charts, refer to an earlier blog post 'Creating 3D Charts in Java'). Client Side On the client side, you need to add mouse (or touch) event handlers in JavaScript that perform the required actions when the user interacts with the chart. You can view the page source for this page to see how we've implemented these handlers for the examples. You have complete freedom to use a different approach on the client side, the key is simply to extract the chart ID and item reference from the SVG element that is the source of the event. Orson Charts provides some utility functions in JavaScript that you can use to grab the chart ID and link reference, and dataset classes if you require the full dataset on the client-side (for example, to generate tooltips as we do in these examples). Examples See the examples at http://www.object-refinery.com/blog/blog-20140509.html. Summary In this post we showed how Orson Charts and JFreeSVG integrate to provide both high quality vector rendering in modern web browsers plus the ability to support interactive features such as tooltips and mouse selection. The source code for these examples is included in the Orson Charts download. [Less]

Java browser plugin has been here for a very long time, and for many years it was available on lots of machines. Yet, there were relatively few reports about somebody successfully using any security holes ever discovered. We are currently under ... [More] heavy rain of reports about Java applet security exploits on the wild. Some of these are, most likely, true. How this could be? If some security bug (or fundamental platform weakness whatsoever) already existed for more than a decade, why nobody used if for exploit before? Why intruders spend so much of they time writing exploits of the now rather legacy platform? Where were they using this time before, instead of attacking the platform that at that time was significantly more widespread and relevant? [Less]

Debugging build tools...I was long plagued GNUstep's IDE ProjectCenter had problems with parsing the compiler's output. This made "clicking" on the warning or error often impossible. I never dug into the details, but it happened more and more often ... [More] and was worse on different systems than others.Yesterday, while working on another projects I got so annoyed that I debug until deep into the night to fix them and found two different sources:On all OS recent versions of gcc (gcc 4.x) have a "fatal error" that was not being correctly parsed and assimilated to an error OpenBSD was using egcc and this was causing the build files not to be recognized, so the error was parsed, but opening the correct editor was impossibleI fixed both! Using modern gcc is thus now fine as using OpenBSD that works now like Linux. GNUstep's cross-platform support thus continues!Happy hacking. [Less]

Java 8 introduces default methods. In the current HotSpot implementation this makes adding a private method to a non-final class a binary breaking change (contrary to what the JLS says about this). Here's an ... [More] example. Suppose you have two separate code bases Lib and App, shipped by different parties. App depends on Lib. Lib defines a class B: public class B { } App defines an interface I and a class D: public interface I {   default void m() {     System.out.println("I.m");   } } public class D extends B implements I {   public static void main(String[] args) {     D d = new D();     d.m();   } } All is well in the world. Now Lib ships a new version that includes a new version of class B: public class B {   private void m() { } } Now when you run D the output is: Exception in thread "main" java.lang.IllegalAccessError: tried to access method B.m()V from class D         at D.main(D.java:4) You could argue that this is "just" an implementation bug, but I posted it as part of this series because it is symptomatic of the mess that is Java's method dispatch story. [Less]