|
Writing Java on the BeOS |
MARK GONZALES: I will just do a quick introduction here. Somebody is running back to the microphone really quickly.
As Greg Galanos mentioned today, we have had a relationship with Metrowerks for quite some time. And as I said last January when we did a developer conference, and I will say it again today, because they continue to amaze us, John Watte and his team have done an amazing job at providing developer tools for the Be Operating System, for putting the CodeWarrior development department over, and this session is dedicated to the next level of that.
So without further ado, John Watte from Metrowerks.
(Applause.)
A SPEAKER: You're a rock star, John!
JOHN WATTE: What?
A SPEAKER: You are a rock star?
JOHN WATTE: Yes, this conference has grown. Last time I was here it was like 300 people and the first conference was like a hundred people. I wonder if I will just prestart the applause in a couple of years just to get everybody to lay down.
So, why should you be interested in Java? And that's a good question. And I can't really tell you the answer. A better question would be; what is Java? You know, I can answer that. At least, in my personal view.
Java is a language. It is a new language that has seen some interest in the developer community, really just the last year or so. The language has existed in different shapes for a couple of years. It is a dynamic language, which means that when you have an object you don't really know what it is, all method lookups and all dispatches happen on that object, kind of like in LISP or Objective C as opposed to the well-known dispatching and static linking of C++, so it's easier to just load a class and do something to it in Java than it is in C++. I don't know if you guys have tried putting C++ classes in shared libraries, but it's no fun.
It's garbage collected, which means you don't need to worry about memory, you create your objects and you use them and then you just ignore them, forget about them when you are done with them, and the system will itself figure out when you are not referencing objects anymore, and just silently sweep them under the carpet. So you have an entire class of bugs, like calling free twice or calling delete twice, that never happens in Java because you basically are not aware of how the system is taking care of memory, it just does it for you, which is very nice.
It is of course object oriented, like everything these days. It does not support multiple inheritance, like C++ does, but it supports inheritance of interfaces, which is, you cannot inherit functionality but you can inherit protocols, you can say I support these four protocols but you cannot inherit from more than one class actual functionality.
And Java is of course catching on. We are starting to see a lot of developers who use Java. I would personally think that it is about as popular as Pascal already. And for a language that has only been out for like a year, that's a pretty good track record.
Java is also an execution environment. When Sun, who came up with Java in the first place, they defined virtual machine, they say this is the environment that a Java program will execute in. These are the byte codes that it executes. The instruction stream for Java is very compact, it's like single byte free instructions. These are the services the system provides. And is it's the same everywhere. So each platform implements the same services for a Java program, which means that you can write your Java program once and it will run theoretically on any platform. And of course you use a user interface in most programs, then those services include the abstract windowing tool kit, which is a class library with classes for doing windows and use text fields, those things that you do with user interfaces.
And what are the benefits of this? Well, you get containment; I call it containment, some people call it security. Because the Java byte code is interpreted and it's a well-known, well designed instruction set you can actually make sure that a Java program cannot go outside the box. You can execute in a known environment and there is no way for a Java program to patch themselves into the system or modify something it cannot modify.
So if the environment is well written, and we like to think that we do that at Metrowerks, you can be sure that a Java program cannot do more than what you tell it that it can do. If you say this program cannot modify files on the hard disk, then that program will not wipe your hard disk. There is an extensive set of checks and verifications that happen to make sure that is what's happening.
And of course you can write once, since it's the same environment everywhere it can deploy everywhere, supposedly, including over the Internet. Java, most of you may have heard about Java from seeing applets in web browsers; we have a little Java program that blinks an advertisement or stutters some text or does some stupid stuff like that. That is not really what I think Java is about, but Java over the Internet is nice because it's trusted, it's contained, that means that you can run and execute an untrusted program and just not give it all the permissions that a regular C++ application would get. So you can just get it from anywhere and still your machine is fairly safe.
So, I want to go on to a little demo. Of course, I kind of like the Be Bounce program, so I decided to implement that in Java. And we are going to see if this works or not now.
Running Java programs are still not as nice as running regular applications, you get an info command line right now, we are working on that as well, we want you to be able to run a program just by double clicking it.
And as I was saying, there appears to be a bug in the network server on this particular hardware.
Since Java is a multi-platform language, you cannot really use the native Be API.
Oh, this is really good. Excuse me.
Yes. No slides, good.
Since Java -- where was I, it's a crossplatform thing that looks the same everywhere, you cannot use the native Be things, you cannot call spawn thread, you cannot call new Be window, you cannot call, create a port or pipe or anything like that, you have to use the Java primitives that are provided for you in this little Java containment box. And those primitives are for interprocess communications, only networking you only have TCP/IP and UNIX-y network processing, which is, it works, I don't think it's as nice as the B port system, but, you know, to each their own.
Okay. So what do we do in CodeWarrior to support Java when you want to develop? Well, of course we have the Java compiler, currently we are shipping version 1.0.2 based on the Sun JDK 1.0.2, but we have some fixes in the compiler to make it a little more efficient, a little faster. We have an editor that supports syntax highlighting, so when you say class something, extends something, implements something, that will come up in blue or whatever your preferrred the keyword color is. And we support running, when you develop your program you make it and you run it from the IDE, which is kind of nice, you don't actually have to go to the command line and type the name of the program to run it, and as I said, we are working on getting just double clicking in Java, a Java file or Java class file to start that application.
For debugging, right now it's println or in Java it's System.out.printlnSystem.out.println. That is suboptimal and debugging is a high priority. We basically have a choice of doing debugging or something called just in time compilations that I will get to, and we decided just in time compilation was better. So debugging had to take a back seat to that. But don't despair, there will be a debugger soon.
And as you can see, this DR9 Advanced Access preview release, it came together just the last couple of weeks before this conference, so we have not had extensive testing of all our Java stuff. We worked under DR8 for a long time and got it up and it was fairly stable and with the move to DR9 one or two things did not get ironed out yet. That will be, of course, fixed as soon as we can.
I already said that we have the Sun JDK version 1.0.2 with Metrowerks enhancements, one of those enhancements is using real Be threads, Java has a threading model but it's not, it doesn't look the same as the Be threading model. Actually on the Java model even on Sun machines, Sun wrote the Java system, they do not use real threads, they use a cooperative threading system and they do on the Mac and many platforms. We use real Be threads, which makes the system really useable. On a Sparc when you do a read from standard in and the entire machine stops, the entire Java machine stops, but on the BeOS you can have your stuff happening in the background while you are reading and writing to the console, which we think is a good thing.
Of course we have IDE support, I already talked about. There are some obvious future directions, we are going to support JDK 1.1.1, I think it is now. As soon as we get debugging working we will move on to 1.1, which introduces more support in the abstract windowing tool kit. Right now there is no support for printing or clipboard, those things that you actually need to write a real application. But all that stuff is appearing, starting to appear in version 1.1. We will give you real debugger support so you can step through the code, and give you real threads and all that good stuff, that's all going to happen in the third quarter of '97, my guess is August, but sometime around then.
So Java is this virtual machine, it is not Power PC code, it is very complex Java byte code that has to be read and interpreted to actually execute what the program is doing. And a lot of the people have been saying that Java is a dog, Java is slow, when you interpret bytes like this you can't make it go fast. That kind of depends on what you are doing. Of course it depends on your hardware. Dual 604, 250 Megahertz machines run Java faster than dual 66 Megahertz 603s, but it also depends on the software you are running it with. And we will see a demo of that later.
It also depends what you do. If what you are doing is drawing dialogs on screen and little buttons and check boxes that you send out a request to a server somewhere and display the results, you don't really need that much speed, most of the speed is in this graphics drawing, which is retargeted to call through to the native C++ API, so a text field in Java is not slower than a text field in a BeOS, when the Java program asks for a text field we give it a Be text field.
And there is benchmark program called the CaffeineMark, which is the standard benchmark for the performance of Java virtual machines. And with a little luck it will run better than the Be Bounce demo.
So I don't know how many of you are familiar with the CaffeineMark, but it goes through and does thing like calculate primes and it's kind of like the drystone and the wetstone on C, it does different kinds of things and calculates how fast it is and scores an implementation based on that.
This is the basic byte code interpreter, it doesn't do anything special, it reads a byte, it does a big switch, a really big switch statement, and it does whatever the byte means and then it goes to the next byte. It's not all that hot, but it's kind of a basic implementation. And as you can see, it's -- I don't know how many of you are familiar with what typical scores are, but these are kind of reasonable scores to see but they are nothing to write home about. Oh.
(Laughter.)
JOHN WATTE: So the interpreted CaffeineMark on this particular machine, which I think is a 200 Megahertz computing machine, is 235, which is, 100 is kind of the base level for what's useable. So you don't go to sleep. So this is not too exciting but at least we are on the CaffeineMark, which is, you know, it shows that the Java stuff works. And it kind of shows the distribution between where we get the performance on the Be system.
I'm a little sad that they don't use threading in the CaffeineMark because our threading performance is really astounding, the Be thread system is great. I think I've said that before.
So where were we?
So what can we do about the speed? 300 CaffeineMarks, a year ago that wasn't too bad but now it's not all that hot. You could do native compilation, like Greg my boss said this morning, you can take Java and you can compile it to real par PC code, real EBCDIC code or what have you, and just treat it as a language, as any other language. I kind of like that, I like the Java language, but when you move away from the Java byte codes you suddenly do not have all of the security that comes from the well designed byte code. Machine code can do anything to your system, it can link files and there is nothing in the way, stopping it from doing that if you don't want it to.
You can also improve the virtual machine that interprets these byte codes, and one technique is called just in time compilation. Basically you do all the verification and make sure that the Java byte code is well behaved before you compile it when you download the program. Then you compile the byte code when it's actually needed, when the message is called you interpret, you translate the byte code into real machine code and jump to that machine code when it's actually needed. And you can also, right now we use the Sun conservative garbage collector and we are looking at different ways of using garbage collector that has better memory, virtual memory characteristics, that's probably a ways off because it's kind of a complicated area, it's fun but complicated.
So we try to do something about this using the just in time compilation.
So now we are running the same thing but with just in time compilation here where it actually gets translated on the fly to the machine code. You saw the first score was 320 with interpreter, now we are look at oh, look, 27,000 for the loop score. Some things translate better than others. But as I'm sure you see from these numbers, just in time compilation helps, especially with those more complicated math like things, whereas as you will see the graphics we don't gain all that much from the graphics because that's hardware dependent on the underlying app server that we called. Oh, no. This is Monday.
Trust me, we get 3600 CaffeineMarks.
(Applause.)
Seems you are actually familiar with the CaffeineMark program.
So, I just had to put this in here, it's one of my favorite Dilbert jargonisms, we are trying to leverage synergies from different platforms to improve the capabilities of our Java virtual machine. What's happening, for instance, our just in time currently is -- tries to translate the code fast, but what happens is you execute code, you get a byte code and you translate it to machine code, you don't want to spend all that much time translating it because the user is sitting there waiting. You are actually translating while you are running the program. Well, for the CaffieneMark, it turns out that the CaffieneMark runs the codes for lots of iterations, so if you spend more time on the translation phase and generate better machine code, you actually get better CaffieneMark figures, and we want to have really good CaffieneMark numbers, not just good CaffeineMark numbers, but really good.
So we are going to spend some time on optimization in the translation to leverage our optimizer technology that we have in the compiler and use the same techniques in on the fly translation, which may or may not give real world performance. But, hey, benchmarks are good for marketing.
So, I'm at questions and answers already. I suppose I didn't spend more than 30 minutes on boring you, so I will just take questions.
Can we get the house lights up a little? Great, okay.
So the man in the hair.
A SPEAKER: What is the frequency and latency of the garbage collector you have now?
JOHN WATTE: It's a conservative garbage collector. Actually that's kind of interesting, because what happens is that we stop all threads to be able to mark their stacks, but when the thread gets stopped, it had about ten threads in the kernel stack, we had our friends at Be add a system call to get the kernel stack of the thread so we could mark it. Currently we use an 8 megabyte default block, and when we run out we call stop and collect and when we don't reclaim enough memory, we start growing this heap of 8 megabytes, so it's more on demand thing, it's not that -- I can't -- it depends on what your program is doing.
A SPEAKER: I would put the priority of JDK 1.1.1 support higher than the priority of debugger support just because it has a better windowing tool kit. I would like to see someone raise their hand to see what other people think.
JOHN WATTE: Basically it's, while that would be nice, I do the debugger and another guy does 1.1, so the priority is not going to change all that much even if we wanted it to. We are hoping to ship both the debugger and the 1.1 on CodeWarrior 4 for the BeOS, which is slated for Q3 '97, so yes, I hear what you are saying. But I think that you will get both.
A SPEAKER: It looks like you're capable of making stand-alone applications, that's something that I wasn't really aware that you were able to do in this version of Java system.
JOHN WATTE: Yes.
A SPEAKER: Is that -- can you tell us about the Java platform? We have been hearing about it for the last couple years.
JOHN WATTE: The question was Java platform. Is that as in Sun's Java platform?
A SPEAKER: Yes.
JOHN WATTE: I am not very familiar with that at all. So I really shouldn't talk about it. Sorry.
A SPEAKER: Yesterday I asked does support, mentioning when you use the Java language, I think the language worked with the API and I don't want to do that because Java is Internet -- Java is a very nice language to develop on. I was wondering, once we get the compiler done can we do that, use Java as --
JOHN WATTE: So the question is Java is a nice language, why can't we call the native BeOS services? And basically I agree; why can't we? But Metrowerks is a compiler provider, we do not write the headers, our friends in the black shirts write the headers and the libraries. So all they need to do is provide a native system calling interface that lets Java call into the BeOS and you would be able to write real Be applications using the nice Java language. I have been talking to some people there about how to do it. It's complicated. So, you know, they would have to talk about if, when, what, how. But I agree, you know. We should all lobby them to do that. Yes.
A SPEAKER: Is there a method right now for having Java function as the scripting language in the scripting API? I figure a lot of people have been arguing about default scripting language, the fact is you are shipping a language, you know, that is going to be available. So the question is, how hard is it to derive a scripting API from Java?
JOHN WATTE: Okay, you want to use Java for a scripting application using DR9 scripting API, which means sending Be messages. That is a good idea. I kind of like that. Right now you cannot create BMessages from Java because we don't support the native Be headers, that is one of the first things I would do if I ever started working on the Be headers for Java myself. (That's not going to happen.)
Another problem is that the Java language does not come with a Be operating system. We only sell it as part of the Metrowerks CodeWarrior development kit. So all users would not have the ability to write Java programs. However, we also, when you buy CodeWarrior, you implicitly buy a license to ship our Java VM with your application. If that application was shipped with all BeOS systems by default, there would be a Java virtual machine in the operating system that comes with Net Positive.
Actually, I didn't go into that in the slides but we have a quick and dirty way for any Be application to host Java applets and applications. Basically we provide three classes, a Windows class, a view class, and an application class. You derive from those instead of Be system classes and then you magically have the capabilities of loading and running applets. If you are writing a web browser, send me e-mail and I will tell you how to do that.
Is that all?
Well, thanks for coming.
(Applause.)
Home | About Be | Be Products | BeWare | Purchase | Events | Developers | Be User Groups | Support