>> BEN: Hello there guys. Thanks for joining us. Today, we have Arno Puder here. He is
a professor as SFSU. Today he's going to talk about cross compiling by code. He is the creator
of a language called XMLVM. And today he's going to talk about cross compiling code for
the iPhone. So here he is. >> PUDER: Thanks Ben for the introduction,
and, well, thank you very much for inviting me out here to this Google Tech Talk. It's
actually my second Google Tech Talk here. So it's nice to be back again in building
42. And today, I wanted to talk about, as Ben already mentioned, about my latest project,
Cross-Compiling Java applications for the iPhone. And it's kind of a project that is
part of a bigger project that we--that I call XMLVM. And I will talk about a bit more about
that during my presentation. But, you know, when you--and the iPhone is very hip device
nowadays and you see many people having an iPhone. Now, unfortunately, Apple is very
restrictive when it comes to opening up their--the hardware. They create such beautiful tools
and products but then they're very restrictive when it comes to opening up. As a matter of
fact, I'm not even quite sure if I had used the official SDK for doing my work. I probably
wouldn't even be allowed to stand here in front of you, to give this presentation. So
fortunately, I've only used open source tools, of course also using a jailbroken device so
I can talk in public about what I've done. For today, I--the agenda is, I will tell you
a little bit about Objective-C. Objective-C is the language of choice of--from Apple.
Not much used outside of Apple. But since not many people have seen it before, I have
a few slides to give you at least a quick introduction on Objective-C. And then basically,
I talk about how we cross compile a Java to Objective-C, to create native iPhone applications.
And I have a bunch of demos throughout, so I hope that you can also see some of the code
that we've been working on in action and in effect. Okay. The quick rundown of history
of Objective-C. So it was designed in the early 80's by a guy called Brad Cox. And Objective-C
is just like C++, an objective--an object oriented extension to C, just like a C++,
except that it has taken more inspiration from Smalltalk. So it's a dynamic language,
and you will shortly on--how that works. In the late 80's, there was a company called
NeXT Software that was--that licensed Objective-C and they used that language to develop a user
interface called NEXTSTEP. And around that time also, I believe Steve Jobs while he left
Apple for some time and he joined this company NeXT Software and also got exposed to Objective-C
during that time. And when he returned to Apple, I think it was reason that he brought
then NEXTSTEP and also Objective-C over to Apple. But anyways, so in my little timeline
slide here, you can see that then in '92 would be Free Software Foundation added Objective-C
support to the GCC compiler suite. Then in '94, it's been standardized by Sun Microsystems
and NeXT to something called, OPENSTEP. I do know that GNU also has an implementation
of NEXTSTEP they called GNUstep. Well, and then, in '96, Apple acquires NeXT Software
and from since on, Objective-C is heavily used inside of Apple. So Micro Wise [INDISTINCT]
is based on Objective-C and OPENSTEP is now called Cocoa. So it's the GUI library used
for developing Mac applications and also used to develop iPhone Applications. Okay. Let
me give you a little quick rundown here. Let me show you some codes, Objective-C codes,
and a better idea of what if feels like actually to write an Objective-C application. So now,
Objective-C, you have strict separation between interface and implementation. And on this
slide here, you see an interface definition in Objective-C. And you can see there's an
interface called Fraction and it inherits from a base class, a base interface called
NSObject. Now, in this, you can already tell by this prefix stands for NEXTSTEP. So, even
though we're now talking about modern iPhone applications here, Objective-C, the base class
libraries still has these class that came from the original NeXT computer company. But
you see there are two members for fraction, a numerator and denominator and there are
some instant methods here. And you can see instant methods are prefixed by a minus sign.
Whenever you see this minus sign that tells you that you actually have an instant method.
The return type is in [INDISTINCT] brackets and--while the signature is a little bit different
from what you used to in--from C++ and Java. Basically, they call it a selector. So if
you take something like set numerator, then it's actually called a selector. And then
the actual parameters or the formal parameters, I mentioned again, after the selector. So
you can see, kind of it's--if you have done any kind of programming, I'm sure that you
can immediately understand how to read this. Okay, once you have the interface definition,
you have to implement it. So have to brought in implementation. So on this slide here,
you'll see how to implement that. So there's a new key work now called [INDISTINCT] implementation
and here's how you implement class fraction. And while you provide the implementation and
call it brackets, no big surprise here, and you can also see by the implementation of
method print that you have full access to the C runtime libraries. So we just used print
f to print out the fraction. And the other methods here for accessing and rating the
members are just like--as you would expect it from any language. So then once you have
created this class called fraction, and here's how we can use it. So the main entry point
of an Objective-C program is, again, the main function, just as it is for C and C++. And
I guess the first thing that looks a little bit strange now is the square bracket here
on the first line of code. And what happens here is basically, you have fraction as the
name of the class and you send it--the method called alloc. So basically, those square brackets
denote sending a message to an object. So what happens here is--in this first line that
you send fraction, the alloc method, and that would correspond to allocating memory for
a class fraction. And then what you get returned is appointed to this new object and then in
it would be the constructor. So you do alloc to allocate memory and then in it to actually
initialize the object. And then you can see how to--how to use the selectors that have
defined for class fraction by sending enumerator and denominator, and I can--I can print it.
So basically, that kind of--is a little bit different syntax but I think you can immediately
see how this works. On the bottom, you'll see how to release an object. So there is
a method called or a message called release you can send to an object that will basically
dealloctae the object. If multiple parameters--and here is bit of a departure from other languages.
I mentioned already before that they don't really call it a method name that, they call
it a selector. And a selector determines method dispatch. So that determines which implementation
you're invoking. And if you have multiple parameters, so for example, if in my class
fraction, I want it to have a method that sets numerator and denominator at the same
time. And here's how you would do an Objective-C. And I think the intention of Objective-C was
that, they were trying to create some kind of readable interfaces. So if you just look
at the--at the bottom of this slide here, so I have this [INDISTINCT] and I send it--I
say "set numerator one and denominator five". So even like in choosing the selector, you
kind of--you can almost read it like in English sentence. So you say, I have a fraction here
and I set the numerator and denominator. And--so that basically, is a little bit of a departure
from just the method name and the list of formal argument types that you have in other
languages. Now, it should mention here that overloading is not allowed of--for selectors.
So if you have two selectors and then you get selectors that only differ in the formal
argument type, it is not permitted in Objective-C. So which of course, has some repercussion
when you try to cross compile from Java to Objective-C because you do have overloading
based on formal argument types. And, well, I'll talk about that a little bit later. Let
me talk a bit about garbage collection because just like C++, Objective-C does not have a
garbage collector. It relies on reference counting. So if you implement your own class
from--if you derive from your own class from NS object, you inherit some basic message--reference
counting functionality. So what you can see here is, again, I initialize or I create a
new object. I initialize it, and then there are three message that--three messages you
can send this object. There's one message called retain count and that just returns
the current reference count for that object. So after you immediately create the object,
the reference count would be one. And you can send an object, the retained message,
and then would just simply increase the reference count by one. So you can see how the reference
count would just be bombed up twice here by sending the retained message twice and then
release just decreases the reference count. And once the reference count drops down to
zero, then of course, the object is going to be deallocated. So now, it's your responsibility
as a programmer to call these retain and release messages. Now, I heard that Apple is planning
on doing a new version of Objective-C where they actually integrate a garbage collector
into Objective-C. But that is still on the road map. So, as for now, if you want to write
an Objective-C application, you will have to do your own--clean up after yourself. There
is one thing that they have added to the runtime library that makes a little bit easier for
garbage collection. So on this slide here; I'll explain to you a thing called the autorelease
pool. So the autorelease pool is just a class that can do a little bit of--while managing
a bulk of objects. So basically what happens is, if you create an Autorelease pool, any
object that is being sent, the Autorelease message will be added to that Autorelease
pool. So if you look at the code on the bottom here, so first of all in the first line of
code, I do create a new Autorelease pool. And you can see just like an instance of a
class called NSAutorelease pool. Now then here, the next thing is I, again, create an
instance of class fraction. Now notice that I not only call alloc and init, but also I
send yet another message called Autorelease. That's a message that is also inherited from
the base class in this object. But by invoking autorelease, what will happen is that this
fraction is going to be added to the autorelease pool. Now, when the--when the release pool
itself is released, so on the last line of this code sample here, you see that I'm actually
releasing the autorelease pool. And the autorelease pool as part of it's cleaning up process,
will release all the object it has accumulated over its lifetime. So basically, by releasing
the autorelease pool, as indicated on this comment here, you will also automatically
delete that frac instance. More precisely what happens is here, that the autorelease
pool is decrementing the reference count by one. So, of course, the autorelease pool in
that example, only deletes the frac instance because the retained count is equal to one,
for this example here. Now Cocoa, as the GUI library for Apple is making heavy use of the
autorelease pool. So if you create like widgets in the Cocoa library, then they automatically
added to the current autorelease pool. You can also nest autorelease pools. You can have
like an autorelease pool inside an autorelease pool, it's also possible. So one more thing
that you have in Objective-C and that's kind of a radical departure from C++ and Java and
is more in tune with what do you had in Smalltalk, the [INDISTINCT] invocations. So basically,
you can send any object, any method, and the compiler will simply take it. So here, I have
an object like a variable OBG object and I send it some method. And the compiler may
say, "Well, you know what? I don't really see that method in your inheritance hierarchy
but I just trust that you know what you're doing here." So if the object should not implement
this method--some method, then it would cause a runtime exception. But the nice thing is
that you don't have to have, like a strict inheritance relationships. So the bad thing
is you have no strong static runtime--compiled time type checking, but the good thing is
that you have a very flexible dynamic invocation scheme here. And it's also heavily used for
the Cocoa library, for example, there is a widget called UI table that implements a little
table widget for the iPhone and the way they connect to a data source. So a data source
just has to implement a few methods. But you do not have to derive your data source from
an interface. Okay. So, so much for Objective-C. So now I want to jump into how actually to
develop a little iPhone application. And here on this slide, you see the infamous Hello
World application for the iPhone. And, of course, since it's for the iPhone, what you
see on this slide is of course Objective-C code making use of the Cocoa library. And
if I just quickly walk through this piece of code here--so, of course, you first have
to define an interface and the--your interface, if you want to write for the iPhone, you have
to derive it from something called UI application. And you have to overload a method called "applicationDidFinishLaunching".
So, of course, it's nothing that I came up with, that's a method that came form the Cocoa
library or it comes from the Cocoa library. So that's basically your main entry points.
So once the application is finished loading, well, that is then what the iPhone will call
in order to launch your application. Now, in the implementation, you see what the application
is doing here. So basically, you--what happens in the first line here is, you use class UI
hardware to retrieve the full screen coordinates of the iPhone. So that basically would give
you something called a CGRect that gives you the full screen resolution of the iPhone.
And then the next line, you instantiate something called the UIWindow, basically giving you
the full size of your screen. So UIWindow, if you've done any swing coding would somewhat
correspond to a--to a JFrame. So here, you basically just create a basic container for
adding your own widgets. Then you do some things, like you put it to the front and you
set it to visible. The next big thing that happens in this code here, you instantiate
a class called UIView, and that would correspond roughly to a Jpanel if you're familiar with
swing programming. And again, you give the UIView with a complete size of the full screen
resolution of the iPhone. And then you see then one line saying "window setContentView".
It's where you add the view to a window. So that's the same thing what you do also in
swing, you just say "JFrame add to JPanel". The next thing that happens here is you instantiate
UITextlabel. And, well that roughly, very roughly corresponds to a JLabel. It's just
basically a TextLabel, although you can do much, much more in the Cocoa library. And
you can see--that you set that--you set the text by saying "Hello World." And then you
add the TextLabel over to the UIView. And that's it. And that would just pope--pop open
a window and horizontally aligned, say, "Hello World" on the iPhone. Okay. So what is--on
this slide again, is the objective-C version of that. Now remember what we're trying to
do. We're trying to allow developers to write an iPhone application using Java. So the first
thing that we have to do is we have to kind of map the API that is defined by Cocoa over
to Java. So which means all these base classes that you see on this slide here, UI application,
UIWindow, we have to create some kind of corresponding classes in the Java world. So the first thing
that we did is actually to do that. And what I show you on the next slide here is now "Hello
World" in Java. And you see it follows exactly the flow that you saw for the Objective-C
version, except now we're using Java. And of course, now I have to create some Java
classes that implement UI application and UI Hotware. So actually what--for the first
demo and that's kind of like the--a little teaser, but I have a bit more fun demo at
the end of this presentation. And I want to show you how actually this "Hello World" runs
on the iPhone. It's not a big show off, but again, there's something more impressive,
it's coming up shortly. And basically, what I'm going to show you here is--while we have
a "Hello World" application, and I have not yet told you how we do cross-compilation but
just believe me for now that we can cross-compile this "hello World" over to Objective-C. Now,
if you use the Objective-C compiler and you just link it with a native Cocoa library to
create a native iPhone application, you can run that on the iPhone. And what you can also
do is, of course--now you've seen this Java class called UI application, so how about
now actually creating a Java implementation of this UI application, for example, based
on swing, which means no that I could run my Java based iPhone application as a pure
Java application on my desktop, okay? That's going to be the firs demo I'm going to show
you. So I switch over to eclipse. And here on this window, you see actually the--you
see this "Hello World" application I've had on the slides. And you can see I have this
UI text label here, and if I click on that, and if I open this class, you can actually
see there's an implementation that goes along with it here. And if you go a little bit down
here, there's a method called the drawRect and that is just using Java 2D to actually
do this rendering of this UI label. So what I can do, is I can actually run this application
here as a pure Java application and when I--when I do that, well, it added a little bit of
eye candy here. So you have--I put a little chassy snapshot in the background. But basically
that's how it would look like as a pure Java application running on a desktop. Now, I have
an iPod touch up here, so I can now run the cross-compiled version and of course that
just does the same thing here so it looks exactly the same as the Java version. So that's
not much of a showoff and like I said, I promised you somewhat more interesting demo and you
can already see there's some scroll bars here called accelerometer, so that will give you
some indication on what's coming up here. But let me go back to my presentation here.
And as the next thing explained to you how we actually do the cross-compilation. And
that basically comes closer to the XMLVM project that where we got this name from. Before I
do that, I just want to point out some of the challenges when cross-compiling Objective-C
to Java. We mentioned a few things, but just kind of reiterate and also to refine some
of these points. Well, Objective-C has no name space support. So we have everything
in the global namespace, I mean of course there's a namespace introduced by [INDISTINCT]
definitions, but there's no package thing. There's no way of defining modules in Objective-C.
Also, I mentioned there is no method overloading so you cannot have like two methods at the
same selector, but only differ in their formal argument types. Not possible in Objective-C.
Now, if you have a Java program that is doing that, then, well, I guess, at least how we
do it, we use name mangling. So we just append the signature to the method name and then
we avoid these problems. There is no garbage collection. So Java has garbage collector,
Objective-C does not. So of course, we have to deal with that somehow. We do make use
of reference counting but it also means, of course, we cannot do certain things in--we
cannot reclaim certain kind of data structure. If you have a [INDISTINCT] data structure,
we would not be able to clean it up. Also very interesting, Objective-C has no static
member variables. So we have no choice but to create Global variables, kind of like a
very awkward thing but that's just the way things are in Objective-C. So, again, you
have to be very careful by using name mangling of not to have any collisions. And the other
challenges that you have on a language side when you talk about cross-compilation, you
also have some challenges from the Cocoa side, from the GUI library. And if you look a little
bit closer at Apple's API, they make use of C functions. So they are like--there's a function,
for example, called CGColorCreate, that's a C function. It's not like what you should
have if you do a proper design--[INDISTINCT] design. It's not like it's a [INDISTINCT]
member of a class, no, it's actually a C function. Now--so of course you have to think of how
can you map that API over to the Java world where there is no function, there is--at best
ascetic member--ascetic method, but not another function. Objective-C has value types. So
in C++, struct and class are almost identical, except for the default visibility of its members.
In Objective-C, a struct is actually a value type. So when you pass a struct around, it
actually--that's a deep copy of all its members. And is also being used in Cocoa, for example,
the CGRect I mentioned before ahead on the "Hello World" program, that actually is a
struct. So we mean--which means it does not do copying of references to pass it around,
but actually is copying that whole struct. So you have to be very careful when you pass
these values around because then we have different semantics with call by value called by reference.
It also uses like this old, old C programming trick of using pointers to add additional
output parameters. So basically, you know what? If you've ever done any systems programming,
you have a point to something and you use that to point it to a pointer to add addition
output parameters. So they also do that in Cocoa and, you know, since we don't have it
in Java, of course we have to be a little bit creative on that. And last but not least,
they're using delegation here, making use of this dynamic invocation already pointed
out as UITable where a data sources just simply has to implement certain methods but does
not have to be derived from an interface. So, that again, we can only [INDISTINCT] with
big problems mimic in Java. So, let me start talking about the cross-compilation because
that's, I think, the most interesting part of this project. And like already mentioned
there is an umbrella project called XMLVM that's--we use for doing very flexible manipulations
of--on a byte code level. And just to mention it upfront, we do not cross compile on a source
code level. So we do not take Java source code, but actually what we do is we take a
class file as the first input to our tool chain. So on the next few slides, I give you
some--I'll give a little demo here by basically walking you through that. So, I'm going to
make use of this class here. So take a very close look at this class because I'm going
to kind of single step on byte code level through this class here. So just take a quick
look at this here. So you have a Java class called Calc, it has one member called X of
type int, and you have method add with one formal parameter Y and all of that happens
in the implementation, we add the parameter to X, so X += Y. On a very exciting class
but just enough to just explain to you how we do the cross compilation. Now, our tool
chain, the first thing it does is, it takes the class file of this class here. So first,
you run it through a regular Java compiler. So take eclipse, Java eclipse compiler take
the Sun's JDK compiler and you end up with a class file. Now that is the thing that we
feed into our two-word chain, and the first thing we do is we create an XML document out
of it. It may sound a little bit awkward, but you will see shortly then what we do with
XML document and it also--is where the--this product gets its name from. So XMLVM, XML.
Well, that's obvious in VM virtual machine. So on the next slide, I'm going to show you
what is XML document looks like for this class Calc. And that's a lot of ugly XML code. Now,
once again, as a reminder, this XML that you see here has the same information as the binary
class file. So there is a [INDISTINCT] directional mapping between a class file and this XML
document. So I can also use XML document and map it back to a binary class file. So all
the information you find in a class file created by a JAVA compiler, you will find in this
XML document. It always begins with the root note XMLVM, that's the name of the project,
and then on the next level you have a class tag that defines a new class. And you can
see, well, there's a--the name of the class and the children of class, the finders class.
So you have an XML tag called field that defines the member X of type int. And then you have
this method add you see mentioning of [INDISTINCT] and local, so basically how much stec space
does this method need, how many local variables does this method need. The method has a signature
so it has a return typed void. It has one formal parameter of type int. And then, I
guess, the meat of this XML document would then be the code tag. And that contains actually
the byte code instructions that you would find in a class file. And that is what the
JAVA version machine would execute step-by-step in running this class here. So what I want
to do on the next few slides, actually since it's something that most people have not really
seen, like what really happens inside a Java virtual machine, I want to single step through
this piece of code here. So actually, I'm going to zoom into this code segment here
and I'm going to just single step through each of this byte codes instruction. You have
a better idea actually on what happens inside the Java virtual machine. So the set up for
this example is here. That's--I have an object that has member X, and I assume that it's
initialized with 11. And these two local variables, you can access them through an array, so local
index zero is always this pointer. So pointing to the object itself and then starting from
locals index one to locals index N are the--the argument are being passed the method. Now
since my little [INDISTINCT] example, he has only one input argument, there is only locals
index one that corresponds to the actual parameter. So that's the initial set up. So the first
byte code instruction that will be executed of this method is the--is the load instruction.
And what load is doing, it is pushing the local index zero onto the stack. So at this
point, I should mention that the Java virtual machine is a stack based machine. So everything
is done over a stack. And that's similar to the way also .net has defined its virtual
machine. So by executing the first byte code instruction, what would happen is that locals
index zero will pushed on to the stack. Now I'm an old fashioned guy, you know, I still
do a lot of assembly, so my stack grows from top to bottom, just to mention that. Sometimes
my students get a little bit confused because they kind of think stack should grow from
bottom up, but I do the other way around. So the next instruction is called dup, which
is a short form for duplicate. Well they just simply duplicate the top of the stack. So
we have now one this on the stack and after executing that we have now this twice on the
stack, pushed a second time. The next instruction is called getfield. And you can just look
at by the XML that we're trying to read a member from an object. And you can see while
we're trying to read member X over class calc, well, that's is--that tells the virtual machine
what member to read. But of course what getfield needs to know from which object it's supposed
to read this member X. Since, of course, we can have multiple instances of class calc.
And so getfield gets that information from the stack. So what getfield is going to do,
it is going to pop off the top of the stack, is going to use that pointer to address the
object, is going to read the content of variable X, member X, and it will push that content
of variable X onto the stack. So with the next instruction getfield, it will pop off
this one this and it will push 11 which is the current value of X. And we have another
load instruction. So load to index while they will push locals index one onto the stack.
And that is now the actual parameter. So that is what we are passing to the method. And
so now, we will just push 31 onto the stack. So now we actually have the maximum stack
size that we need for this particular method here. The next instruction is called iadd
while I integer add were that just adds two integers. And since we're talking about a
stack based machine, what does it do? Well, it just pops up the last two integers, computes
the sum and then pushes the sum back onto the stack. So 11 + 31 is 42. So, you can see
I big fan of--well, okay, you guys know what I'm talking about, right? 42. So the next
instruction putfield is then the reverse of getfield. So it actually writes now a value
back to a member. So again, you can see putfield, again, says, "Well, I want to write back to
member X of class calc." Now, what does putfield need in terms of parameters? Well, it needs,
first of all, just like getfiled, it needs to know to which object. So it needs a pointer,
it needs a reference to the object and of course needs to know the value that's supposed
to be written back. Well--and guess what? Exactly those two things are, right now, on
the top of the stack. So putfield is going to pop off two elements of the stack and it
will then use this point to access the object and it will write 42 back to X. So now, in
the next instruction, you will see that X now will become 42. And that, of course, return
is I'm going to leave the scope of this method but that basically shows--it gives you rough
idea on what happens inside the Java virtual machine. But just, again, to point out, that
the Java virtual machine is a stack based machine. So everything happens over a stack.
That makes instructions very, very simple. So just a matter of pushing and popping some
data off the stack. Okay. So that's all the good and fine. So I've explained to you in
great detail on what does XMLVM looks like. Now--but how do we go from here to Objective-C?
And, well, actually what we do is, and that may look a little bit awkward, we're making
a use of XSLT sheet. So, since now we have this byte code program represented through
an XML document, we actually have written the tile sheet that now cross compiles or
generates based on this XML document Objective-C source code. And we do that by just simply
mimicking the stack machine and the target language, which in our case now, is Objective-C.
Now, if you look on this little code sample on the bottom here, and let me first direct
your attention to this XSLT template on the bottom. So you see, there's an XSLT template
match iadd. So this tiled sheet, this particular template, is going to fire whenever it comes
across the iadd instruction in my XMLVM document. Now, whenever I see the iadd instruction,
it is going simply to spit out the code that you see in black here. Now, the code in black
is Objective-C source code. And if you take close look at what this code is doing, it
actually implements the behavior, the semantics of the iadd instruction. So, you see, I have
some helper variables. I have a variable called _stack that just represents my runtime stack.
I have a variable called _SP for stack pointer. I'm using a pre-decrement to mimic a pop.
I use a polish increment to mimic a push. So, what these three lines of Objective-C
code are doing is exactly what would happen in the Java virtual machine. It pops off two
integers and pushes the sum back on to the stack. Now, those variables op1, op2 and stack
are based on a tight [INDISTINCT] that you can see a little bit above this code segment
here. So, it's a union basically. That is a union of all the primitive types that are
supported by Objective-C. So I can--I have typed, say, if access to whatever a data type
I have on the type of the top of the stack. Now, of course, I'm relying on the fact that
Java C--the Java compiler is producing correct code. So when I know that when I execute the
iadd instruction, I know there are two integers on the stack. So I know that I can access
the top of the stack using the--that I remember of this union here. Now, what I show you on
the following slide, I show you actually what this class calc looks like completely cross-compiled
to Objective-C. So, well, that's a lot more code than my original one liner here, X +
= Y. But basically, that--the code you see on this slide here, first of all, is Objective-C
code. And you can see on the right-hand side, I have these curly brackets here that show
you the respective code, what kind of byte code instruction they implement. So some on
the bottom you see iadd, you can see those three lines of code that I just explained
to you on the previous slide. But you can see, those are the--these handful of bi-code
instructions that I just singled step through. And you can see like how every of these byte
code instructions just results in very, very simple piece of code that just does a little
bit of stack manipulation. So you can see how the dup thing is just simply taken the
top of the stack and just pushing it one more time. Now, of course, there's a bit of boil
up plate code that we have to create. For example, this helper variables, stack and
stack point are--and op1, op2. So those are created by the tiled sheet for the method
tag. If you remember from XMLVM, there is an XML tag called method. So the tiled sheet
for that XML tag would emit the boil up plate code to initialize these helper variables.
A few more things I want to point out here. So, you can see method add, we use name mangling
here, so we name mangle the formal argument types into the method name in order to avoid
this method overloading problem that we don't have in Objective-C. And one more thing, I
also want to point out here, is you can see that the way we do garbage collection is that,
every--at the entrance of every method, we create an autorelease pool that we release
upon exiting the method. Now, of course, just a crude approach here. So if you have like
a very light weight little method, of course creating an autorelease pool is kind of overweight,
is kind of overshooting. Likewise, if you have like a big four loop, it just simply
creates objects before you exit the method. Of course you would also commit a lot of garbage
that would take a long time to clean up. But that--at least is a first approach to garbage
collection, we use reference counting and every method gets its own autorelease pool.
So, whatever object are created inside that method, as long as their retain count is larger
than one, the moment you exit the method, that is the time when the objects would be
reclaimed. Okay. I think it's time for some--somewhat more cooler, a little bit cooler demo here.
So let me show you a little bit more complicated application. And in the XMLVM project is become
kind of customary to do a little application we call "Fireworks." And this application
is just implementing a little fireworks thing here and you can see what it does. It just
simply lets these sparks fly. Now, that is of course a little bit more complicated than
"Hello World." So that is using a lot more of the Cocoa library, reloading images here,
we do animation, we have timers, we move things around on the screen. But what you see right
now is, again, the 100 percent Java applications. For all these Cocoa--Cocoa classes that I'm
using here, I've actually implemented a Java version. So I can run this as a pure Java
application. So we're making use of the Java to do all this animation. So that is the application
that we have. Now, this application can be cross-compiled and if I run it now on my iPod
Touch here, of course, you see the same thing here. So it's exact the same application.
I did not have to change one line of source code to make it run here on the iPod Touch.
Now, the iPod touch has some special hardware. Just like the iPhone, it has a thing called
the accelerometer which means that you can sense change of orientation. So the way the
application is written, is that the sparks always follow gravity. So if I turn--if I
turn my iPod touch around, you will see that the sparks follow gravity and always go to
the bottom. And, well, how can I--how can I mimic that in my little Java emulator? Well,
you know, I can use, that's what I have this scroll bar for. If I use my mouse here to
use these scroll bars, I can also change the orientations. So by pushing Y down here, I
can make the sparks go fly up here. If I go with X here, I can make them go to the northeast
corner of the display. So that's kind of like--with the accelerometer, you can just do three scroll
bars for the three access. So it's kind of like a little trick. Now, the iPhone also
has more advanced things. It has the mighty touch interface. So probably all have seen
this famous pinch for zooming in, so you take two fingers and you'll push them apart to
zoom into, for example, Google maps that is running on the iPhone. Now on my laptop here,
I only have one mouse. So how can I--how can I simulate that piece of hardware this mighty
touch interface if I only have once mouse? Well, what we have decided to do is, you know,
we realized that we actually--well, why don't we use iPod Touch here as a remote control.
I mean, I have a mighty touch interface on the iPod Touch here. So, what I've--what we
have done is, we have create little application that runs on the iPod touch that is simply
transmits the information of the accelerometer over to my simulator. So let me call this
application now. I'm typing the IP address, turn on, okay. So actually what happens now
is, I run this application, there's nothing you can see on the application on the iPod
touch. But observe the scroll bars of my--of my simulator. When I turn my iPod Touch here,
it's kind of by magic almost, it's changing the orientation of the--of the scroll bars,
okay? So--and also then, of course, as a consequence, it's changing the orientation of where the
sparks fly because that's what I wanted to show you. So, sorry for the little glitch
here. Now, this application I just showed you that I used as a remote control, we have
also created using the same technology. So this application I just showed you, we have
written as a Java application and cross compiled it over to the iPhone. So what I can do now
is I can actually launch this application in a second simulator. So let me do that now.
So this is the application I was just using to type-in the IP address. So now I have two
simulators open, and let me just--oops, sorry. Let me move this down here. And what I'll
do now is I just type-in the IP address which of course is local housed here on my laptop.
I turn on the on switch and now if I use the scroll bars here in the second simulator of
course this is going to control then the first simulator. So you can see that we already
have actually pushed the--or a little Java Cocoa Library to some extent here. So you
can see, there are some user interface elements that we already implemented to your, you know,
that makes the iPhone so famous like all these little cool sliders and tables and preferences
and headings and so forth. So, you know, even spend some time to do like the same color
gradient, you know, to make a little bit look like you actually would--you would expect
it from the iPhone. But basically, that a little bit more complicated application because
it's also using remote communication. So it's also actually doing a HTTP request to upload
the sensor data to the second simulator so that's actually a lot more complicated than
the fireworks application here. Well, that's the demo. Let me run through a couple more
slides to wrap up here. So XMLVM is an umbrella project as I mentioned for bytecode manipulation.
And on this slide here, I just show you some of the other things that we have done as part
of this project. And what you see on the top here are the different bytecodes we can feed
into XMLVM. So I've shown you here a Java bytecode instruction that was the whole demo
I was showing you here. But we can actually also feeds .NET bytecode into XMLVM so you
can take a .NET executable. And you can also create this XML file or all of it. And as
of recently, we also support the Ruby version machine. Ruby 1.9 has its own version of machine
at its funny name, YARV, I don't know, Ruby was done by Japanese guys so they have like
this interesting acronyms but YARV is the name of the Ruby bytecode. And we can also
feed it into XMLVM. Now, on the code generation side, we can create different--different languages
so first of all, we can map it back to Java bytecode. We can map it back to .NET bytecode.
We can map it JavaScript, to Python. And we can map it to Objective C & C++. Let me just
make a few points here. So one thing we can do is we can take .NET bytecode and we can
write out a Java Clouds File. So we have also a bytecode level across compilation from .NET
bytecode to Java bytecode. Base that with the beckon for Objective-C as I have shown
you, it would also be possible to buy an iPhone application in C#. So if we have the Cocoa
Library based on a .NET API, you would be able to also write iPhone application using
C#. We can cross compile from all these bytecodes down to JavaScript so actually the earlier
Google Talk, I mentioned that I gave here two years ago was actually just focusing on
how to cross compile Java bytecode to JavaScript. So that, you know, we were actually good for
doing AJAX application so it's similar to the Google web dual kit so we take Java source
code and we compile it to bytecode instructions and we can create JavaScript out of it. So
actually, if you go to our home page, you will see some demos and what we can do there.
We actually have that reminds me this fireworks now in JavaScript, so oops, that is--so here
you can see like here's an index of XTML files. If I double click on that, it will fire up
Firefox here. And what you can see now is actually fireworks running as native JavaScript
code inside of--inside of a Firefox. Now if I use animated [INDISTINCT] for the sparks
here because it looks a little bit nice on a big screen here, so now use the color to
sparks I've used for the iPhone version. But that the same algorithm that is now--is now
being cross-compiled over to JavaScript to run as a JavaScript application inside the
Firefox. So we use that to develop AJAX applications. By the way, this window, don't be fooled,
we're using an AJAX Library called qooxdoo. And they gave you like a desktop look and
feel inside the browser of yours. So this window is actually just a dif that just do,
you know, I can move it around. If I close the tap here in Firefox, you can see that
it actually then also closes the application. So it's also a good moment to introduce some
of the members of my team here. So I have one student who joined me today, Joshua. Joshua
Macon, he has done a lot of work on the .NET to Java bytecode cross compilation. Then another
student, Jessica Lipp, who also has done some work on that part. Joshua is also going to
spend some time for his Master thesis trying to cross compile Android applications to the
iPhone since Android is Java based, we think it's quite possible that you should also be
able to cross compile Android application over to--to the iPhone and there is one colleague
of yours actually, a former student of mine, Sasha Hebaling, he's based in Zurich, Switzerland.
He did a lot of work in the early days of XMLVM for this Ajax framework. So he worked
a lot on the cross compiling Java to JavaScripts. So before I--I wrap up my presentation, I
wanted to just--kind of pitch you one more idea, you know, I am academic so I do not
do really like products, I do some--some--some prototypes and demonstrators but I try to
push the envelope in terms of developing new ideas and--and one idea I'm--I'm kind of toying
with right now is, XMLVM at the moment as you have seen on the previous slide has various
flavors so we have XMLVM for Java bytecode instructions. We have one flavor of XMLVM
for .NET by constructions and yet as of lately, a third version that has Ruby bytecode instructions.
But at this point in time, XMLV and XMLVM document only contains bytecode instructions
of one virtual machine. So either you have a XMLVM document only with by--Java bytecode
or only .NET bytecode or only Ruby bytecode. So the--the use case that I am working on
right now is how about if you take--if you take [INDISTINCT] program, AOP. In--in [INDISTINCT]
programming, what you do is you have an aspect, you weave into an application. You all are
smart Google guys so I am sure that you're very familiar with that. AspectJ is like the
big--the big "A" or "P" framework in Java. Now how about if you have a C# Application
and you weave in a Java Aspect. So basically, you achieve reuse on for Aspects on a--on
a source code level by--by being able to leverage your--your Aspects written in Java and weaving
them into C# Application. Now what would happen in that case is that you end up with a version
of XMLVM that has not...bytecode instructions from one machine but kind of like the interleaf
so you basically have bytecode instructions from two different virtual machines. But the
question is, "What do you do in that case?" I mean, you what--what you do for example
if you--if you have Ayad instruction from Java that I have explained to you earlier
and you let it lose on an unsigned data type that is available in .NET but you don't have
in Java. Java does not--does not unsigned [INDISTINCT] I call this the Abstract Virtual
Machine. It's kind of like a super virtual machine and what we would have to do for that
is we have to define the semantics of--of this virtual machine in order to define these
cases, you know, what happens if--if you mix--if you mix bytecode instruction from two different
virtual machines. But again, the benefit would be then--then for AOP, I think that would
be a very interesting project. So that is the latest thing that--that we're working
on. So to--to wrap up here as--as an outlook of course, you know, like I mentioned before,
we don't do products, we just do prototypes. Now everything we have done here is available
on an open source license. So I mentioned--put the--the homepage xmlvm.org; easy to remember.
It's hosted on source [INDISTINCT] and everything is available in an open source license. Now
there's still lots to do. I mean just for the iPhone part, I mean, we have implemented
some of the Cocoa classes for the user interface elements for Java but there is still of course
a lot more. I mean, the iPhone is famous for its user interface elements and--and of course
if you want to write Java [INDISTINCT] classes, you would have to do a lot more work on that,
and as I have also mentioned one thing that Joshua has just began to work on the Android
to iPhone cross compilation. Well, guys, that--that wraps up my presentation. I would thank you
for you attention for coming here today and if you have any questions, I guess I would
be happy to answer them now. The mic. >> Yeah. This stuff's pretty awesome. Thanks
for--for bringing it in. I'm thinking--I was thinking about the Android to iPhone cross
compilation during the talk and it seems like the--the UI would be somewhat different between
the two phones but it does make a lot of sense if you were coding an app and you wanted to
be able to be able to have an iPhone version and an Android version to share some code
would be really cool. How close is the--how close is the library for--for sort of non-UI
elements, would you be able to share some--some Java classes that have less dependencies between
an iPhone app that you--that you wrote in--using XMLVM and--and--and Android app?
>> PUDER: Yes. And we--we are--like for the--for the Fireworks application for example, now,
one--one classic example is we have a random number generator. Right, to--to place these
bugs by random on the screen. I mean, there is a class in the Java runtime that implements
a random number generator and of course if possible, we try to let--we do leverage functionality
we already in the Java runtime library. Now when it comes to mobile devices, of course,
the--it does not make any sense to cross compile Swing application, I mean, Swing is meant
for desktop application. It would not make any sense to write any compatibility classes
for Swing for the iPhone. Now when it comes to Android, again, we're just beginning with
that product so I can not talk too much about it and I'm also waiting for you guys to open
source it properly or I don't know exactly what the status is of that now but the thing
is that Android is, you know, the very least I do know is also targeting mobile devices
so I am fairly confident whatever the--the abstraction is that we have a better leverage
on cross compiling that to the iPhone and then for example, you know, Swing to--to the
iPhone. So to answer your question, yes. We try to leverage as much of the native library
if--if we can to make it easy for the Java developers so they can use what they are used
to, you know, data structures for example HashMaps and support but for the UIElement,
we stick with the native API. >> Yeah. Can you talk a little bit about the
performance matrix, especially I am interested in Java to JavaScript compiler and also compare
or contrast it with hand code to Java to JavaScript compiler in...
>> PUDER: Compare it with what? >> Compare it with--like a hand coded Java
to JavaScript compiler in GWT, Google Web Toolkit.
>> PUDER: Yes. Okay. So--so the question was about the performance of--of cross compilation
I mean, if you look--if you remember this piece of code, let me just go back to this
one slide here at, I mean this like is--is a lot of overhead, right, I mean--I mean,
that is by no means as efficient as like there's one line x+=y of my original Java program.
Now this here is Objective-C and we're using and objective C compiler to compile it down
to--to machine code. Actually we have observed that the GCC compiler is very smart. It can
actually optimize a way a lot of this boilerplate code. So if you look at the generated machine
code, you would not--you would not see the stack anymore. The stack goes away. It still
not quite as efficient as the--as the original Java program but the native Objective-C compiler
can optimize a way, a lot of this boilerplate code here. So for the Objective-C, I am not
concerned at all. And you also have buy JavaScript, that is different thing because JavaScript
is an interpreted language and of course, you know, there we can not do any kind of
optimizations, I mean, JavaScript would look like just as ugly, you know, if I ran this
through our JavaScript backend, it would look something similar like this here--of course,
I'm using JavaScript as--as the target language. Now that of course is a lot more inefficient
than--than a native writ--a natively written JavaScript application and of course, I also
have to admit that Google Web Toolkit since they begin on source code level--they have
a source code level cross compiler--they can do a lot more optimizations. So they are code,
yes, of course would be a lot more efficient than our generated codes. You know, okay.
Yes, that the thing is, you know, I am academic, I have only very little resources, you know,
I'm not Google, you know, like you guys have like a whole team of program as you can tackle
all the Java source code level but doing that what--what DWT that they have done is very
complicated. A lot of work. Know by code level is--is a little bit more simplistic. Now,
I have also given you the Fireworks demo for JavaScript for the purpose to show you that
actually, you know, it runs pretty cool, you know, I mean, that application is--is a few--thousand
lines of JavaScript code and very bloated compared to a natively written application
if I would do it a native JavaScript but it's still be--performs quite okay. Now--now when
you specifically ask for Ajax application, you know, my response here would be--well
for Ajax, you would not want to do any number crunching applications anyways inside the
browser. What I mean, you do UI applications and for those performance is not that big
of an issue. So even though I completely agree that the way we create JavaScript code is
not as efficient as for example, Google's Web Toolkit, I think for--for the kind of
application that you would do or you will do for Ajax is preferably okay. And actually
if you go to the XMLVM homepage, you--you will see also a little bit more complex application
that we have done for Ajax and it works like--like a charm. I think the question to front here.
Anymore? >> I was asking about the [INDISTINCT]
>> PUDER: Okay. [INDISTINCT] question. Any other questions? Well, then again, thank you.
Again for your--for your attention. Now just to come back to my little thing here that
as an academic, I have only very few resource to my disposal, I know you guys have your--your
20% project, you know, so maybe you might want to consider using one of those idea I
pitched you today as--as your 20% project so, you know, talk to me if you--if you're
interested in that. Anyway, thanks for coming today.
