A Java Development Environment for REAL Apps

As all of us know, Java is great for making tumbling duke do gymnastics on home pages. However, we are on a mission to build real client/server apps for professionals in Java. Real apps that improve a user's productivity. This kind of software demands a robust development environment. With these priorties in mind, this document explores the following questions.

What's here ??, What's coming ??

More importantly, What do we need ??? and What are we doing to buy, steal, or create it ???

And finally, How are we structuring our system to maximize the advantages of Java, but minimize its weaknesses ???

Industry News

Important Dates

Date	Event
Dec. 95	All the bugs out of Netscape 2.0
Jan-Mar. 96	SunSoft supports Java on all platforms: Win95, WinNT, Solaris, MacOS
Nov - Dec. 96	Beta versions of "Workshop" ship.
Jan-Mar. 96	"Workshop" is for real.
Jan-Mar. 96	Supports Sun's NOE (Network Objects Environment). Whatever that is ??

"Workshop": A set of development tools Sun is pushing, including graphical features for setting breakpoints, single stepping, and browsing class structures.

There is also Gamelan the site of Java resources, i.e., a big collection of Applets. And of course Sun's very own Java Home Page

Does anyone else know companies working on tools we could use in the near term ?? If so, send me HELP

Our Environment

Write your applets to the Beta API !!!

Netscape 2.0 on the SGI for runs beta applets. Running remotely rarely works for me.

Sun's JDK is installed at /users/mds/public/JDK. The executables are a compiler (javac), appletviewer, and debugger (javad). There is some other stuff in there too.

Basic building blocks of Java development are packages which consist of related classes. There are a bunch of packages that we can work with and build from: Sun's Packages. These packages help turn Java programs into applets i.e, helps them fit into the HTML and WWW environment. We need to define a set of interfaces and create packages that support our system - "cad:// ".

Our Packages : None Yet

Cautionary Note: Altough hotjava (/users/mds/public/hotjava) works a lot better than Netscape, don't use it. It is for the old-Alpha API. Use the appletviewer in the JDK instead.

Overview of Our System and Where Java Fits In (and Doesn't)

From our discussions we decided that the system will consist of a collection of peers which behave like a widely distributed group of processors and memory. Peers can act as both client as servers.

Functions of peers acting as clients:

Java Interpretation / Virtual Machine
Caching byte code
A boot loader that faults in basic functionality for the client. Of course the functionality is a series of Java programs
If the client is the "CAD Browser", then the Java programs initially run will be on :

Most all the basic features presently in hotjava: network interface, basic ui, file management, etc.
Our protocol "cad:// " that runs on top of http+.
CVS like features if it is a multi-user design environemnt
Smart search tools

Function of peers acting as servers:*

*Freqeuntly, servers must run really fast, handle many requests simultaneously, use bleeding edge hardware ... Thus server side software is not written in Java. However, servers must have as part of their functionality a Java virtual machine, so that they can intepret requests which are Java functions layered over the http+ protocol.
Send and receive messages effeceintly via our protocol which is layered over http+. The extension to http(s) required is for servers sending unrequested messages to clients. This is why I call it http+.
Run predefined batch oriented processes when the server is or behaving like a "tool" server. An example is running a design-rule-check on an uploaded layout file.
Search themselves for information when a query is presented

Java programs fit in the environment as a protable, network friendly, safety-consicous, way of:

Building user-interfaces on a client
Running simple processes (edits,displays,simple-checks...) in real time without suffering the penalty of a network transaction
Describing the set of valid requests and replies that make up our "cad:// " protocol. Part of this is the "dapplets" (data-applets) notion. (An object that is 95% data , 5% program by weight.

Example Scenario: A front end for a batch oriented software package. In this case I picked HSPICE. Here is a really bad drawing of the environment:

Although I drew it on this diagram, I don't think Main-Memory (data files and persistent state) will reside on the "net" at Netcom's disk farm for a long time. There maybe a market for some portable applications, but mostly niche services like email. I agree with many of the arguments of Francis and Serena. However, frequently data will reside on a file server on a LAN in a well protected domain of the net.

I think we also need to be clear that the purpose of the system is to extend the reach, access to time-dependent information, and improve the flexibility/extensibility of the current computing paradigm. For CAD and other professional applications, the current paradigm is the LAN based client/server, workgroup, framework- Very similar to our network here on campus. We are going to allow users to seamlessly cross that boundary more effeceintly and productively than ever before !

Making Java Work, Building Packages ... Next Steps

Experimenting with a front end applet e.g., FSM Editor and interfacing it to a tool server. Perhaps we use a synthesis tool for the server.

Defining the set of messages in the cad:// protocol. Use the protocol to link the FSM editor to a tool server. Develop a complete grasp of critical issues. Learn how to partition applications intelligently.

Improving the caching and linking scheme for java apps. Get a browser that can load/run multiple distinct applets and allow them to run simultaneously and share information. Check out netscape, you can't get 2 applets to run at once. AND If you go "back", your applet dies !