My one hour session (in the REXX area) was scheduled for a room which would have held about 40 people. Ten minutes before the start there were people queued up outside and we moved to a room with 100 seats. By the time the talks started the room was completely full with people standing in the doorways etc. I talked to someone about this and they pointed out that there had been tremendous interest in all things Web/Internet related and most of the sessions had been "sold-out". The talk was presented in real-time using my Powerbook and Netscape and appeared to be well received. There were a healthy number of questions which had to be curtailed due to lack of time. Many people came up to me afterwards and commented that they found it useful and thanked me for making the library of REXX functions available.
Mike gave an excellent overview of the various components of what is colloquially known as Java. Because of the current interest in Java at SLAC, I will try and reproduce what I heard from Mike since it may benefit others with interest in Java. The components include a portable (hardware independent) machine spec, an intruction set (bytecodes) for an abstract stack-based machine (similar to the old P-code definition from the 80's), a concrete spec for a runnable Java module (class file), a compiled language (a simplified C++ with many little used, dangerous, or difficult features removed), and a browser (e.g. HotJava). The virtual machine components consists of the instruction set (bytecodes), a stack, state registers (program counter, stack pointer, method environment pointer etc.), no general purpose registers, a data area with automatic garbage collection, a method area for storing methods and a constants pool. Java language programs are compiled to Java bytecodes and (I think) the programs are know as Applets. The syntax is 'C' oriented with some C++ object-oriented constructs.
A Java enabled Web browser can run Java Applets which are invoked by the HTML in the page and and are downloaded on demand. This allows animation and audio. The audio in today's Java is rather weak (Mike felt this was due to its origin in the Unix communitity). It allows local interactions (e.g. mouse and keyboard), TCP/IP connections to other applications. There are a lot of security considerations, in particular the Applets run in a padded cell, the bytecode is assured by a code verifier.
Typical Java packages include a Java bytecode interpreter and kernel, a Java language compiler (JavaC), a disassembler (JavaP), Applet viewer, class files for the base, windowing, net, audio and tools. Typical package sizes are: 25 Kloc for the Java virtual machine, 38 Kloc for the Java compiler and tools, 16 Kloc Hotava alpha browser, 12 Kloc for net classes, 16 Kloc for the windowing classes. On top of this there is the machine dependent part which is something like 20 Kloc.
Mike identified the following current Java weeknesses. Garbage collection is troublesome (I think he meant it causes hiccups in the interaction as perceived by the user). Richness of the native classes caused by the lowest common denominator effect that it has to run on all platforms. Mike mused that this was not that serious today since most of today's GUIs which Java would translate to, provide similar features.. Multimedia (audio and video) support - there is work in progress on this. The language is aimed at professional programmers. In Mike's view this identifies a need for a REXX for Java!
Since Xmas Mike has been working on a REXX + Java blend. This will preserve the syntax, philosophy, arithmetic and ease o f use of REXX. It will generate Java bytecodes for cross-network portability and efficiency, extend keyword safety further into REXX to allow safe interpretation from the source in future. This will be a dialect of REXX which will translate the REXX program into Java. An example of a NetREXX program would be:
addr=InetAddress.letLocalHost hostnameaddr=addr.getHostName say "address is:" hostnameMike has completed the first phase which is the language design and initial translator (in REXX for OS/2), together with a NetRexx string class. He is working on user testing, feedback, and refinement. Next he has to port the translator to netRexx, then get the translator to generate bytecodes directly. This is a research project and not a committed IBM project.
Other NetRexx features include: all the Java types and classes are supported, I/O is provided by Java (this simplifies NetRexx language), some simplifications and enhancements to REXX (line comments, hyphen for continuation, LOOP keyword as opposed to overloading DO), the Java and NetREXX classes are completely interchangeable with no loss of efficiency, a binary option that allows high-speed native arithmetic.
Raw speed of Java today is about a factor 10 slower than native code. This is fast enough for most needs, but is too slow for MPEG. Work is in progress for improving this and it is hoped to get within a factor of 2 (of C++) within a year or so. Also silicon implementations of Java have been announced.