This time recorded on Ubuntu. Did I mention 64bit already?
Do not miss my session at FOTB for a live demo.
Tag Archive for 'java'
My talk at FITC San Francisco is over and I want to share some of the anouncements from today with you. At the end of my talk I was showing JITB.
What you see in the YouTube video I posted a while ago is a Java program executing a SWF. For FITC I added some more code and an OpenGL based Display List renderer. In other words: I wrote a Flash Player.
However I should rephrase that statement and say I am attempting to build a Flash Player. The current state is available in the sf2010-sprint clone of Apparat. I will merge the changes into the main Apparat branch when I am back home in Germany.
JITB is currently able to translate a subset of ActionScript code at runtime into Java bytecode and runs nearly at the same speed as native Java. This is a really huge improvement compared to standard ActionScript performance. A lot of smart people worked on the JVM and made it really fast. Apparat will allow you to leverage all this hard work in the future. I am also shooting for Java interoperability at some level so that you can call Java classes from within ActionScript. Hopefully you will be able to use JITB on your desktop machine, on a server or on an Android phone. Basically everywhere Java runs.
There are still a lot of things missing. The whole Flash API needs to be implemented. And the Display List rendering needs a proper OpenGL implementation. However I thought this might be some cool stuff to share with you in its early stages.
My hope is that more people start contributing to the project. Maybe some OpenGL guru wants to take care of the Display List rendering or someone else likes to help implement the Flash API in Java.
I also showed a Raytracer by Nico Zimmermann during my presentation and promised to put the URL on my blog so here it is. His company is called Britzpetermann and the address is http://www.britzpetermann.com/.
Update: Please do not think that this implementation is 30x faster than the Flash Player developed by Adobe. One(!) microbenchmark is never a number you should count on. I would like to make clear that I never said this.
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
That is so right. The first thing that comes to my mind is Java on the Mac: sub-standard, castrated and broken. The second argument is even better. Intermediate layers can hinder the progress of a platform. So true. Apple, the intermediate layer between you and the iPhone, stops you from improving the platform. You have built something cool — like Unity3D — and can empower creative people with better tools? Sorry, you are out.
The only way to improve the progress of a platform is by opening it up. Yes, I think we have been there before.
Take some time and think about this tweet for a moment. It took me a while to realize that Joel Hooks is right. I was embaressed of myself. How could I forget about that? But I had also a big smile on my face at the same same time. Let me explain why.
The Java to SWF compiler does not compile Java sourcecode but JVM bytecode to ActionScript bytecode. This means I do not have to teach my program the Java language. It only understands JVM bytecode. This seems like an akward decision on the one hand since working on the bytecode level implies lots of problems. But it turns out that this was a really cool decision on the other hand. “Java to SWF compiler” is maybe the wrong description. “any language that compiles to JVM bytecode to SWF compiler” is maybe better.
So what does any language mean? Here is a list of JVM languages. Now you feel maybe like I did after reading that tweet. And I am really looking forward to get Scala up and running.
Some problems still exist. Threading is one issue and I will basically have to do what Scott Peterson did for Alchemy. But reflections, annotations and method overloading have to be solved as well. Some glitches may exist even after figuring everything out. Stacktraces will look pretty weird. However I think this is a really cool project.
Update: I forgot to mention something important. Java supports native code. This means you can build a library that works with OpenGL for instance. Those native methods can not be converted. There are also some other things that do not work. File access is just one of them.
At the end of my Leaving the Sandbox session I showed two projects I have been working on without telling anyone. The first was a compiler that could compile C# to SWF. The second was another compiling being able to compile Java to SWF. First of all I have to say that both tools are far from being finished. They are a so called proof-of-concept. For me it is enough to know that this is possible. I am also not sure if I will finish one of those tools.
So how does this work? Because I am now working on the AudioTool backend for our highly anticipated launch I had to switch to fulltime Java development. In order to understand the JVM better I started to search for the optimizations that the HotSpot VM performs and stumbled upon a framework called Soot. Voilà. Reading about Soot made me question why nobody is working on such a framework for ActionScript. Probably because universities see Flash just as a toy. For us developers being dependent on the Flash Platform it is of course more than that.
I will quickly explain what Soot does. It reads compiled Java class files and converts the machine code they contain into a three address code representaiton. This code is then heavily optimized. TAAS is basically doing the same. I also want to note that Soot is by far more complex and complete than TAAS right now. It would be megalomania saying that TAAS is Soot for ActionScript. But you get the idea. The one framework converts Java to three address code and the other framework converts ActionScript to three address code. Maybe it is possible to connect them.
This is what I did for the Java compiler. The whole pipeline looks like this:
- Compile Java sourcecode with the Java compiler of your choise
- Use Soot to get the three address code representation of a compiled binary
- Create TAAS expressions for the expressions that Soot uses
- Connect the TAAS graph the same way the Soot graph is connected
- Compile the TAAS graph to a SWF
This is about it. There is some glue-code involved here and there and I did not implement all Java expressions yet. I did also not bother about threads. Basically one could do what Scott has done for Alchemy. The cool thing is that we get highly optimized Java code because of the Java compiler and Soot. Then the TAAS compiler can run a second time after linking is done and perform platform specific optimizations like inlining and loop invariant code motion for certain expressions.
I already wrote a couple of classes and packed them in a SWC. Those mimic the behaviour of the Java classes like java.lang.System or java.util.LinkedList. On the Java side I implemented the Flash classes like flash.display.Sprite and flash.events.EventDispatcher. The interesting part is that all the methods those classes contain are marked native which means they have no implementation since they are native to the Flash Player.
This is also a great advantage. It is slow in Alchemy to call Flash methods and to communicate with Flash classes. The Java approach does not have this tradeoff. I also do not have to trigger the ActionScript compiler. The conversion form class to swf is entirely done using Soot and TAAS.
So far for the Java compiler. But in order to show a little bit more of the potential I wanted to have a C# compiler working as well. The great thing about advanced languages and a large community is that people have already built a lot of tools. It did not take too long to find an advanced framework that converts C# to Java. Actually this is not be the best approach. But I could not find the “Soot for C#” the evening before my FOTB session.
So I am using net2java to convert .NET code like C# or VisualBasic to Java. That code is then compiled using the Java compiler and I am using Soot again to convert the code to TAAS without much stress.
For me the most important part is to know that it is possible to compile .NET source code and Java binaries to SWF. To complete those tools one just has to implement all the missing expressions and the standard Java library in Flash. Everything could also work the other way around. Compiling from TAAS to .NET, Silverlight and Java is another option.
Everyone who worked with Java and MIDI was having problems when it comes to MIDI support on Mac OS X. It is simply not supported. So we were running into the same issue. Luckily Java has two nice features. The first is called Service Provider Interface (SPI) which allows you to create your own provider of MIDI devices for instance. The second feature is called Java Native Interface (JNI) which allows you to execute platform specific code.
Now I do not really know why there is no MIDI support on the Mac because the implementation is fairly simple. OS X comes with a lot of easy-to-use system libraries. One of those libraries is CoreMIDI. Now the only thing you have to do is wire everything together. Use SPI to talk over JNI with CoreMIDI and you are set.
I am not a Java programmer and not a Mac user at all. But I think I learned some common things during the last days.
- Synergy is awesome. A good friend told me about it half a year ago and now I finally tried it. One mouse and keyboard to control four screens which are connected to my Laptop and Macbook is pure luxury — but for free! Synergy is open-source and absolutely superior to a VNC solution.
- JNI is not hard to handle. It was not my first time using it but when it comes to threading you have to keep in mind that references to Java objects have to be marked global and everything from the call to your JNI method becomes invalid. Keeping a reference to the JVM and attaching the thread to it works very well.
- The Ant Jar task has a bug. Defining a service using the <service/> tag does not work because the folder in the jar will be named “service” and not “services“.
I am definitly not an expert when it comes to this kind of stuff but I had my problems especially with the Ant bug and calling a Java method from a different thread. The result is very nice on the one hand because it works for all kinds of MIDI messages now but on the other hand I still have to ask myself why nobody included this feature for the OS X Java VM in the first place.
The good news is that we will have a very robust MIDI implementation which will work crossplatform without the need to install any additional libraries.
Last night I spent about 9 hours writing a build script for the AudioTool allowing us to compile each plugin into its own SWF container. I think it is the first time a Flash project is taking more than 5 minutes for me to compile completly.
I figured out that it is definitly not easy to handle the mxmlc or compc in a way we needed it to be. The point is that we have for each plugin three modules A, B, C and a library D. A depends on D. B depends on A and D. C depends on A, B and D. Now to make it even more complex we have A, B, C and D in one project so that developing in this environment stays still simple. The solution to compile all modules in a way we need them to be was first generating unique entry points for the SWF files because we do not want to work with SWC libraries (or the SWF inside the SWC package). After having the unique entry points we compile D (and its dependencies as well) without including the source of A, B or C. Afterwards we can compile A. But B is dependent on A so we have to compile a SWF for A and then a SWC for A so B can link to A as an external library. C is also analog to this but needs B as a library as well. In the end it was 5am and I was happy to have the complete build working which generates a lot of SWF files and SWC libraries.
Since it is very hard to configure Ant for this (I was using XSL in the beginning for automated code generation) I started developing my own Ant tasks. I have to say that it is really simple and saved us hours of work. We have now one single XML file containing the dependencies and the Ant task will do the rest (code generation, compile tasks, etc.).
This evening Kai-Philipp and me were playing around with the Hobnox Audiotool to test some of the upcomming Midi features.
In the middle of the performance we lost the connection to the little cubes and had to restart the Midi bridge between Flash and the devices. It is still in an early stage but a whole load of fun.
The little cubes were provided by our colleague Oliver who is currently reviewing them. They are comming from percussa.com and are able to send CC values based on their orientation.
FlashHunter is a neat Eclipse plug-in I wrote that allows you to kill all running Flash player instances with a single click. Two days ago I was implementing the fast Fourier transformation in Flash and I had a stupid error that caused an endless loop. Since I am testing with the standalone player the only way to get rid of it was Ctrl+Alt+Del and killing it. This is not really a nice workflow so I wrote the plug-in.
I am not a Java developer and definitly not an Eclpise platform developer so the plugin itself is very basic. I experimented a little bit with JNI and wrote most of the plugin in C++ because it still is my language of choice.
The plugin is Windows only. I think you could also do something like that as an external tool for OS X (“killall Flash\ Player”).
