Discover Java

By Dave Mark

This month, the big news from Metrowerks is the release of their long-awaited Java development environment, timed to coincide with the start of WWDC. Metrowerks’ version of Java comes in two flavors. If you already subscribe to CodeWarrior Gold, have no fear, the complete set of Java tools is included with the just released CW9. The complete Java toolset will also be packaged without all the C, C++, and Pascal tools under the name Discover Programming with Java.

I had a chance to speak with some of the engineers behind Metrowerks’ Java effort. Without further ado, here’s my conversation with Marcus Jager, Clint Popetz, Peter N Lewis, Tim Freehill, and Mike Lockwood...

Dave: Let’s start off by talking about CodeWarrior. Can you explain the process of building, compiling, and running a Java project?

Marcus: Our primary goal with supporting Java on the Macintosh was to make the experience as Mac-like as possible. This means that we had to remove from Java the over-dependence on file system hierarchy and environment variables. The user shouldn’t have to do anything more than add a pile of Java source files to a project and hit Command-R.

Peter: We tried to make working with Java almost exactly the same as any other CodeWarrior target. So you make a new project (using a Java stationery document, or just select Java as the target). Then drag in your Java source files, and any zip files you need (you can weak link these if you know they will be available). Like the other targets, you use the Java project panel and select the type of output and other options. Then you can debug your program using the same source level debugger that CodeWarriors are used to.

Tim: Java has really fit smoothly into the IDE. The language-specific features were altered to support Java, so now you have Java keyword highlighting, and Java methods are parsed for the function popup. But using CodeWarrior to program Java really is not much different from using CodeWarrior to program C++.

Dave: What is the difference between an applet and an application? What does a Java application look like on the Mac?

Marcus: This is where something like Java causes terminal confusion in the naming of things. For the record: An applet is just a sub-class of the applet Java class, nothing special. Applet objects are what Web browsers use to embed Java code in web pages; this is what most people mean when they talk about Java. A Java application is a complete self-contained program that runs independently from the network and Web browsers. Currently these are executed in the standalone Java interpreter application, but there are better ways of doing this.

Clint: An applet can only be viewed within an “applet context”. This context can be provided by a browser like Netscape, or a simple program like the AppletViewer. Applets are intended to be embedded in HTML pages. Since they are meant for dispersion via the internet, they are placed under pretty strong security restrictions with respect to disk access, loading native code, or accessing the network.

Peter: Using CodeWarrior you can build several other kinds of outputs. My favorite is a Macintosh droplet - this is just a tiny 68K application that asks the Java interpreter to execute the zip file stored in its data fork. If your target is a droplet then you can just choose Run from the Project menu, the project will be brought up to date and your code will be executed in the interpreter. If you add a BNDL resource you can then drag and drop files onto your droplet. Also, you may be able to include some native shared libraries and then use native classes to do processor-intensive or hardware-specific Mac-only solutions. So, for example, you might write some C code to interface to a scanner, package it up as a Java class and a shared library, and then do all the rest of the code using Java, perhaps using AWT as the interface, or writing some more native Mac code. I think this is going to be a lot of fun.

Dave: The standard user interface in the Java universe is defined by AWT (the advanced windowing toolkit). The AWT interface is definitely different than the standard Mac interface. For example, under AWT, each window has its own menubar. How is AWT implemented on the Mac?

Clint: Well, I mapped the AWT components onto PowerPlant LPane subclasses. So AWT buttons look like LStdButtons, etc. Since each AWT Frame (window) can have its own set of menus, I have each window put its menus in the bar when activated, and pull them out when deactivated. A bigger problem is that there is no equivalent of the Mac Human Interface Guidelines for the AWT; you can make your “OK” button say “Yessir,” put it in the top left corner of the window, make it mauve, and make its font italic. And since many people writing Java code will not be used to the Mac, you can expect a lot of weird-looking Mac windows.

Dave: Do you think we’ll ever see a mainstream Macintosh application written in Java? Perhaps based on a more Mac-like AWT with its own version of Constructor?

Marcus: Time for some marketing speak: “Metrowerks considers these to be important future directions.” Java has opened up a world of possibilities, and it will be a while before it’s clear what its true strengths will be. I think that Java is much more than the Internet and the Web. I would love to see mainstream Macintosh applications written in Java. I think the very strong type safety and automatic garbage collection would be a big step forward in programming practice and lead to better quality programs.

Dave: Can you call C code from inside a Java applet? If so, what is the binding mechanism that makes this possible? What security implications does this have?

Clint: Applets can use native C code, but only if it is has already been loaded by the Java virtual machine. So the virtual machine decides what native code is safe (like the native code that implements the AWT), and the applets can use this.

Marcus: The Java virtual machine calls C code from Java by linking to a shared library and calling the C functions contained in it. Since the virtual machine has no way of verifying what the shared library does, it relies on the user to install only libraries that they know are safe, and provides no automatic system for downloading them.

Dave: What impact will mixing Java and C/C++ have on my ability to debug my programs?

Mike: The CodeWarrior debugger will support debugging both C/C++ code and Java code simultaneously. The CW8 debugger can already debug 68K and PowerPC code simultaneously, and in CW9 we are adding Java support as a third target. You will be able to single-step through both C++ and Java code, display C++ and Java objects, and see both Java and C stack frames in the stack crawl window, all at the same time.

Dave: How will Java affect the world of web site management? Will CGI/Perl programming go away?

Marcus: One of the problems that people are starting to realize about Java is that you still need professional programmers to write applets. All Java does is increase the maximum power of expression available to web page creators; it does not make their task easier. JavaScript will likely have a greater impact on the use of CGI/Perl than Java. Also, web site management needs more powerful but simple-to-use tools. Adobe PageMill is a step in this direction, but there is a long way to go.

Clint: Perl programming will never go away. But the use of CGI/Perl solutions in web pages may dwindle as applets become easier to write, and as standard suites of applets become available to web page authors.

Dave: What is “just in time” compilation? Does Metrowerks support it?

Clint: JIT is on-the-fly compilation of Java bytecodes to native instructions, providing an enormous speed jump while not breaking the platform-neutrality of the binary. Our VM has hooks in it in order to support this.

Marcus: Marketing speak again: “Improving the execution speed of Java is an important future direction.” Obviously, the success of Java depends a great deal on its speed. The faster the interpreter, the more powerful and complex the programs that can be written.

Dave: How would you compare Java to other object programming languages you’ve worked with?

Tim: Because they’ve ripped out a lot of the “features” of C++ that cause problems, like pointers and direct memory manipulation, and have added features to make the programmer’s life easier, like automatic garbage collection, I can see Java becoming a very popular development language. In any development, how many crashing bugs are the result of writing to the wrong piece of memory? That won’t happen in Java: a big headache is gone. In addition, Java code is more readable and maintainable than most C++ code, because Java was written from the ground up as an object-oriented language, and has no feature compatibility to maintain with a cryptic language like C. All of the stuff that shouldn’t be there isn’t. The resulting code is clean and well organized, because Java pretty much has to be written that way. So bring on the Java-heads!

Clint: Java is a much cleaner language than C++, as it eliminates unsafe constructs like pointers, and provides automatic storage reclamation. It is statically typed (like C++), but is dynamically linked and loaded (like Smalltalk), thus providing for a much more loosely coupled language, which lends itself to a faster prototyping cycle. It has a whole slew of cool features, including typed exceptions and synchronization primitives. It also has a pretty complete set of language libraries. On the downside, Java does not support parametric polymorphism, and it does not provide for multiple inheritance of implementation. Overall, I consider it to be a very cool language that collects the better parts of a lot of existing languages. The best point in Java’s favor is that it is designed to be a production language. And we’re doing our best to help Mac programmers produce with it.

Marcus: I think Java has the right features for success. Its greatest trick is that on the surface it looks like C/C++, but is in fact a well designed object-oriented programming language. This means that all those C/C++ programmers out there who are biased against a properly designed language will use it because it seems to be a C++ derivative. Not used to looking deeply at the languages they use, they will be lured by the syntactic sugar of Java; beguiled by the surface similarities, they will become seduced by the garbage collection and type safety. Finally the world may start to use a “real” programming language and we can leave the dark ages behind.