Notes for Nick's Java Presentation

Topics Covered

1. Intro - Java is a big subject

• Java language
  Java is a 3GL programming language, with its own syntax and rules. It is quite c-like in appearance.
• Object Oriented Programming (OOP)
  Unlike C++, where you can disregard the "object-orientedness" of the language and use it as "a better C"(?), the Java language has OO built into it.
• Java development cycle
  It's not the same compile/link/run as you may be used to with other languages
• Development tools
  Sun supplies a set of tools that can be used to develop; it is useful to have a knowledge of these although 3rd party IDEs provide a much more pleasant environment (but then you have to learn how to use them)
• Deployment
  Differs from other languages (although theoretically simpler)
• Java run-time environment
  How does it work?
• Standard Java libraries
  You thought Win32 had a lot of APIs...
• GUI libraries
  Libraries that do all the boxes/buttons/etc.., similar sort of concept to Motif
• Sun is very active in moving Java forward and building new functionality
  There are loads of optional libraries (e.g. JNDI, JSSE) as well as other technologies (e.g. Java implementations for palms etc.) that people keep inventing. It's not possible to keep up with all the new stuff that's appearing.
• There is a ton of information on Sun's web pages.
• Summary: expect to be intimidated
2. History (so far as I can work out)

• Public announcement 1996
• Original design - network devices/embedded systems
  Seems like the original idea was to design a platform-neutral environment which they envisaged being deployed in a range of devices.
• WWW
  WWW took off about this time, and they redirected efforts to branding Java as a web-based technology. First GUI implementation was put together hastily and is very limited (AWT). "Applets" was the name given to Java applications that could run inside a web browser.
• Where we are now
  Problems with browsers/security meant that WWW approach didn't really come off, and Java now seems to be moving back to the original concept, albeit with loads more bells and whistles (and a much improved GUI library - Swing).
3. Design goals
• Architecture Neutral and Portable
• Primitive data types are always implemented the same way (IEEE float format mandated, which is the main reason you don't get Java on VAX)
• No "sizeof()"
• No "endian" issues
• No "#ifdef __osf__"...
• No pointers
• Familiar (borrows syntactic style from C)
• Simple (conscious effort to improve on C and C++)
• No preprocessor
• No conditional compilation
• No "#defines"
• No header files
• No typedef's
• No "structs" or "unions"
• No "goto"
• No automatic type coercions
• No multiple inheritance
• No pointers (==>no pointer arithmetic)
• No templates
• No operator overloading
• Proper String class available (==>no more null-terminated character arrays)
• Language support for array types
• Interpreted
• Makes for a faster development cycle (this means it's slower at runtime, but they seem to have similar ideas as the people who designed IA-64, viz. assume that software will get very clever at optimizing things)
• Object Oriented
• Designed in, not bolted on to the side like C++
• Threaded
• Designed in to the language, rather than being implemented as a separate library
• Robust
• No pointers
• Garbage collection; programmers don't have to chase memory leaks
• Strict compile-time checks
• Run time checks for array bounds, casts etc..
• Exception handling
• Dynamic
• Full RTTI
• run-time class activation
4. Example code

Here are two programs which do the same thing, one written in C and the other in Java:

• probe_server.c
• ProbeServer.java

Things to notice:

• Java version is slower than the C version
• Java program is shorter than C program
• Java language has a C "flavour" to it
• No "includes" in Java. "import" is used but just a way of saving typing; we could do away with it. On C, we need different "include" files depening on what platform is being used.
• C program has to use "htons" at one stage. This overcomes endian-issues, so you'd never do this in Java
• Java program uses "Strings". Also String concatenation (in "println" calls, which does the right thing with "int"s)
• Both programs run on W32, Unix and VMS. But no conditional compilation in Java (necessary for different includes as well as WIN32 API differences)
• Java libraries provide "Socket" class which makes using sockets quite a bit easier
• Java uses exceptions rather than error status to indicate problems. C tends to use different mechanisms to indicate problems depending on the routine you're using (contrast "gethostbyname()" call with "InetAddress.getByName()". Exceptions contain error text as well as identity
• Java program dynamically allocates objects ("new") but never deallocates them. This is the job of the garbage collector.
• Java, like C++, allows declaration of variables anywhere ("for int port...")
5. Components
• Compiler
• Generates generic "bytecode". This is the Java equivalent of machine code. The bytecode generated by a compiler on one computer can be taken to any other computer that has a JVM and can run without recompilation.
• Java compiler is provided by Sun and is used pretty much as-is by all the IDEs. Since it's output is platform neutral, there's not so much incentive for individual vendors to produce an "optimising" java compiler. The Sun compiler does have an "optimise" switch which is currently non-functional.
• Java Virtual Machine (JVM)
• The Java equivalent of a CPU. This is a program which interprets Java bytecode
• Needs to be implemented for each platform, because it turns the generic bytecode into the specific machine code for whatever platform it's running on.
• Sun provides JVMs for Solaris, Win32 and Mac. Other vendors (e.g. Compaq) have to write their own. Since the JVMs are tied to platform, a lot more effort goes into optimizing these. For example, Compaq has "FastVM", Sun has "Hotspot", and you often see mention of "JIT" technology, where the VM attempts to anticipate which bits of the program will run in order to be able to interpret and optimize them just before they are needed. Similar concepts to FX!32.
• Sun has a set of tests which are used to validate conformance of a JVM to their official specifications.
• Standard Java libraries and JFC (Java Foundation Classes)
• Library of classes (around 1500 in 1.2) which may each contain many methods.
• Bit like combined set of system services and RTLs. Since a Java program cannot (portably) use any of the underlying routines that are provided by the OS where it's running, the Standard Java libraries have to provide all that functionality
• Non-portable routines have to be written in conventional languages and therefore have to be ported by each vendor at the same time as the JVM. For example, I/O.
• JFC is written in Java and so is 100% portable.
• JFC includes Swing (GUI) as well as many utility and helper classes (similar to STL for C++).
• Successive releases of the JDK are adding more and more functionality to the JFC. For example, JNDI is included in 1.3 whereas in 1.2 it was an optional extra.
• Java Runtime Environment (JRE)
• Consists of JVM + libraries
• The JRE is like the operating system and hardware platform on which a Java application runs
• It is possible for a web-browser to host a JRE in which a Java applet can run. An applet is a Java application which is constrained by certain security limitations that are imposed by the browser.
  A web browser may have a JRE built in, or the JRE may be downloaded as a plug-in. Plug-in is more common now, since new versions of JRE were coming out more quickly than the browser vendors could keep up.
• A Java program can make calls to native software routines outside the JRE using JNI (Java Native Interface). This breaks portability though.
• Java Development Kit (JDK)
• Compiler, "javac" turns Java source into bytecode
• Debugger, "jdb" looks a bit like dbx except with a much worse UI, probably not worth using - all the IDEs have much better debug support
• Documentation tool "javadoc" parses Java source code and generates html output. Sun use javadoc for all the JFC documentation, so if you use it then you get documentation that looks "official".
• Java Archiver "jar" is effectively a zip utility. Makes distribution of your applications easy. Java libraries have classes which allow an application to manipulate jar files.
• Disassembler "javap" can disassemble byte-code back into Java source
6. Other buzzwords you might have come across
• JDK [covered earlier]
• JVM [covered earlier]
• JRE [covered earlier]
• JNI [covered earlier]
• JIT [covered earlier]
• AWT [covered earlier]
• jar [covered earlier]
• javadoc [covered earlier]
• Java plug-ins [covered earlier]
• Hot-spot technology [covered earlier]
• HotJava - this is a browser from Sun that's written in Java. Doesn't seem to have taken off.
• Applet [covered earlier]
• Servelet - this is the server-version of an applet; it's a Java application that runs on a server, typically performing work in response to requests from a browser.
• Java Bean - A Java bean is simply any Java class that exposes methods that have a defined naming convention. Using this naming convention, a bean may expose properties, methods and events to a caller. Like a VB control, or an ActiveX control.
• Packages - Each Java class exists in a package. The package name (which is user-defined) is part of the class-name, which means that the "Test" class in one package won't be confused with another class of the same name in a different package. Additionally, classes in the same package have extra access rights to each other (sort of like "friends" in C++).
• Swing [covered earlier]

Useful Links

• The Java Language Environment White Paper