Practice English Speaking&Listening with: Developing iPhone Applications using Java

Difficulty: 0

>> 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; 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.

The Description of Developing iPhone Applications using Java