News and commentary from the cross-platform scripting community.
	Java for Frontier Scripters

By Brent Simmons, bsimmons@wrldpwr.com.

I've been looking at Java recently. My background is largely in Frontier scripting, with some C and C++ programming.

If you're a Frontier scripter, and haven't looked at Java yet, I think you'll find some things to like.

It's not C, not C++

You never have to learn pointer arithmetic, write memory management routines, or grapple with multiple inheritance. There goes half the learning curve!

Composite data types are implemented in classes. Forget about learning structs and unions.

Strings and arrays are objects. For instance, you can concatenate strings as you do in Frontier, using the + operator.

It's object oriented

Though Frontier uses an object database, Frontier is not, strictly speaking, object oriented. Java is.

Object oriented programming has a major flaw: in order to create a new class, you need to know about the class or classes from which it inherits properties and methods. Add this to the learning curve.

That learning curve is not unlike the Frontier learning curve, where one learns about the Frontier environment. In both cases, learning about Java's classes and learning about the Frontier environment, it only seems daunting at first, and with a little patience and work becomes second-nature.

A Frontier example of inheritance

One of the features of object oriented languages is the idea of inheritance. Classes are organized hierarchically, each class inheriting methods and properties from the class above it.

A simple example of inheritance can be found in Frontier. Anyone who's used the web site scripting suite is familiar with the inheritance of web site directives.

A background color directive placed in the top table of a web site is inherited by all tables and pages below it. The background color directive can be overriden at any point, by either a sub-table or a single page.

Imagine also a directive that's a script rather than a small chunk of data, but that still can be overridden in the same way. That gives you an idea of what object oriented programming is about.

But what about storage?

Java doesn't have a built-in persistent storage mechanism. In other words, no Java.root. To the Frontier scripter, this is both a disadvantage and an opportunity.

Can Frontier work with Java? Doug Baron has already shown one method:

http://www.scripting.com/frontier/snippets/javaTree.html

How will Frontier and Java work together in the future? I don't know, but I can think of a dozen things I'd like to see.

Java client, Frontier server

Another way Frontier and Java can work together right now, today, is over the web. I've done some preliminary work on this subject, and I've noted that other software vendors are working to Java-enable Filemaker Pro. Similar idea.

Imagine this: you want your web-page-based Java applet to be able to query your existing server-side databases, whether Frontier, Filemaker, Verona, or whatever you've invested in.

You also want to store, on your server, information entered into your Java applets.

This can be accomplished today, without waiting for Java SDK 1.1, without any modifications to the Frontier application.

Your Java applet simply sends GET and POST requests to your server. CGI scripts in Frontier interpret the requests, do something with them (store data, retrieve data, send Apple events to other apps), and return information to the applet.

The CGI scripts in this case could be called "faceless," in that their output is not designed to be viewed as html, it is designed to be formatted by a Java applet.

What you get with this: a persistent storage mechanism for web-based Java applets, and an ability to extend your current software investments into the world of Java.

Writing Java applets

Java applets are a lot like Frontier CGI scripts, in that you know what to expect and what you have to do. There is a basic structure you can always follow, and within that structure a great deal of freedom.

For instance: you put your Frontier CGI scripts in the suites.webserverScripts table. Similarly, Java applets are public subclasses of java.applet.Applet.

With Frontier CGIs, you know what parameters to expect and what they mean. With Java applets, you have a small list of methods you may or may not override, and you know what these methods are for and what they should do.

Java applets can get information about the environment in which they're running, just as Frontier CGIs can know what kind of browser sent the request and what kind of server software is running.

Your Java applets can do pretty cool things with not very many lines of code, often not more lines of code than in your average Frontier CGI script.

Perhaps best of all, implementing networking in your Java applets is simple. For instance, sending requests to CGIs is very easy, enabling one to implement a Java client/Frontier server system without spending much time writing code for creating URLs and sending http requests.

Conclusion

Java and Frontier can make great friends. Any scripter who's doing web-based content would do well to start learning Java now, even though the Java IDEs and APIs are not yet mature.

Java does not have the learning curve of C or C++. Some of it will be very familiar to Frontier scripters.

Though we can hope to see Frontier and Java work well together in a number of different ways, there are cool things the two can do together right now. The two complement each other very well.

Links

For more information about Java:

Java tools for Macs:

Roaster Technologies make Roaster, the first Java IDE.

Metrowerks CodeWarrior supports Java.

Symantec makes Visual Café, a visual environment for Java development.

Java's Home:

Sun's home page of Java on the web.