![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
From: Jon "Maddog" Hall <hall at zk3.dec.com> This is the handout for Bill McKeeman's talk on Java, to be given at UNH on October 30th at 1900 hours. I am sending you the handouts in two parts, labeled "Handout: Part One" and "Handout: Part Two" (hey, we don't do anything fancy, here!!), since majordomo has a (self-imposed) limit of 44,000 characters. [Editor's note: Can you imaging someone SPAMing a message that is *over* 44,000 characters? The mind boggles.....] If you wish, you can print these and bring them with you to take notes. So you expected that *I* was going to print, copy, staple and distribute them? HA!! Dream on, McDuff!!! md P.S. If you think that just having the handouts is good enough, you have never heard Bill speak. :-) ============================================================================= Java Briefing -- the BIG picture -- Bill McKeeman Especially prepared for Greater C Team Meeting 96.02.22 and updated for The CTG Lunchtime Seminar Series 96.03.08 and updated for Digital Galway 96.04.22 and updated for OBB/DMQ 96.06.27 and updated for VoiceTek 96.09.13 and updated for Digital Unix Engineering Group 96.09.20 and updated for The NH Linux Users Group 96.10.30 Java has been around for about 4 years, starting as a TV settop language called OAK, and passing various internal engineering perils until SUN finally hit on using it as a browser-side execution medium. The details of the early history of Java are gleefully documented in many of the introductory books on Java. What is magical about Java is that it has caught on and Gosling did a good job of designing it. Now Guy Steele and Bill Joy did a good job of defining it. Java has momentum. It also means that the Java world is changing daily. There is a firehose full on information about Java in every communication medium, most especially the WWW. One good way to get early information is to read JavaWorld, an on line magazine devoted to current news (http://www.javaworld.com). There are lots of other wannabe languages to fill the role of a browser-side execution medium (Inferno, JavaScript, VBscript, Visual Basic, etc. etc.). The fundamental technical requirements for a Java competitor are: 1. Platform-independent execution. 2. Virus and Trojan Horse resistant. 3. Privacy respecting. Even though Java was designed to put interactive content into WWW pages, it can also be used for many other system tasks. Java will give C++ a stiff challenge in the places were C++ was becoming dominant. C, other other hand, will probably retain its role as an efficient application language and also as the language of choice to support native methods in Java. There are (at present) three forms to a Java program (applet, servlet and application). An applet (which comes down the wire from a server side and runs in the browser) attaches methods to screen and keyboard events. The result is interactive content without needing server intervention once execution starts. A servlet (which comes up the wire from the browser side and runs on the server) is a means for the browser to request computation to be done on the server. Servlet/applet communication is convenient because both can work to a common API. An application (which runs from your command line) and acts like a normal program. An application has a method named main which is where execution starts. There is nothing otherwise special about the name main, which can also be present in applets and servlets but has no effect unless it is explicitly called or associated with a screen event. I put a main in every applet and use it to run the applet as an application for standalone unit tests. The fundamental change in The World As We Know It is that the WWW provides a new channel for software distribution (netwrap) -- Java code can be can be up or down loaded over the net. SUN is trying hard to make Java the preferred medium for netwrap. Others (Microsoft) are trying hard to make Java not the ONLY medium for netwrap. See conventional compilation below. Platform independent execution is achieved two ways. The first is by porting the Java interpreter so that each platform is capable of efficient interpretation of the Java executables. The second is providing platform- specific compilers to turn Java executables into machine language, picking up a factor of 20 or so in Java execution speed. SUN is busily turning out 25 cent Java interpreter chips so that no platform-specific compiler is needed (see below). The virus problem is close enough to being solved that it is national news when someone finds a hole in the system. Probably nothing can be done about stink bombs, Java applets that consume system resources so fast that the user has to do something to clean it out. But this is an annoyance, not a safety issue. Privacy of the user's data is another area which has shown some problems. In particular, some applets have been caught emailing data back to the applet server. I think nearly all of the holes will be plugged. When a new one shows up there is a potential Black Monday where most of the PCs in the world die. A few incidents like this could kill Java. language competition -------------------- Java is a competitor to C and C++. It is my opinion that the combination of Java with C native methods is a more effective programming language model that C++. But so are a lot of other things. That has not stopped C++ yet. The deciding factors in language adoption are availability and investment. There is already an enormous industry-wide investment in C++, mostly in the form of existing applications, training and class libraries. If someone invests in moving the C++ class libraries to Java or Java+C (see below), Java will begin to compete in the traditional 3GL space. In any case Java use will grow in its own niche of netware -- giving it the leverage that Pascal and Modula never had. Also, it causes a smaller break in the utterly universal C paradigm than did the Pascal family, which shows good business sense on the part of the Java designers. There is no point in fighting over surface syntax. C won that battle years ago. Brown University is already using Java instead of C++ in its teaching program. I would too, if I were still teaching in a University. Java is conceptually cleaner and simpler and richer. Good for learning concepts. Reasonable chance of being a useful skill after graduation. Other universities are following Brown's lead. Another competitor is Visual Basic. I have done most of my personal computing in Basic for years. It is lots easier to use than C. Microsoft knows this and has 3,000,000 users who must agree. There are probably few nerds among them and lots of business people. Again, surface syntax does not matter much. What does matter is the supporting class libraries and mature integrated development environment. Visual Basic is very O-O, and the infrastructure is highly developed. See Development Tools below. It is possible to support other languages within the Java infrastructure. SUN has announced support for Scheme, Ada and Visual Basic. SUN has also announced a chipset supporting Java byte codes directly, eliminating the need for the JVM. This is an interesting development considering the industry has finally reached a consensus on risc machines for performance. The SUN Java chips are definitely cisc. I think older languages such as Pascal and Modula are just not candidates anymore. There is no technical reason that they cannot be used but Java is good enough so why bother? In my opinion, the really interesting development will be JavaPlus -- that is, dialects that can map onto Java. This can vary from Java plus some built in operators and classes to a language more like Basic that makes the Java structuring (classes, methods, ...) implicit. Such a scenario is an extension enabled by the Java infrastructure, not competition with it. UTF8 ------------------------ One forward-looking Java feature is Unicode source input. Unicode is a standard within which all the worlds natural languages can be encoded. It has been ratified by most of the governments in the world, including Japan, China and Korea, which had to agree on Kanjii (the so-called Han unification effort). Ritchie and Pike invented an encoding for unicode that is upward compatible with ASCII. Looking at the bit layout of the code, the trick is to use more than one byte for some codes. 0bbbbbbb ASCII 0-127 7 bits 110bbbbb 10bbbbbb unicode 0-2047 11 bits 1110bbbb 10bbbbbb 10bbbbbb unicode 0-65535 16 bits The code has the property that even coming in the middle you can establish the character boundaries. Leading 10 means "in the middle of a character" Leading 0, or leading 11 means "starting a character". In the tables for unicode there are digits for 15 different number systems, large ranges of unicode acceptable for identifiers, and so on. The Java Language specification says that non-ASCII cannot show up in numbers. Seems like a small oversight that may someday be corrected. Why irritate the Tamils (or Tibetans) unnecessarily? In fact SUN has not yet delivered on the Unicode promise by implementing the libraries with Unicode. That is, most everything is there except input, output and graphics :-). SUN says the 1.1 release will do better. Now, of course, my keyboard does not include a key for Kanjii "rice paddy", but there is a unicode escape in the form of \uxxxx, giving a 4-hex-digit value which can be embedded in the Java source text. This solves in a single stroke the problems that caused digraphs and trigraphs and wchar_t to show up in C. JIS is not a subset of UTF8, so the Japanese are not going to be able to switch (anytime soon) to UTF8 because of billions invested in JIS data and programs with hardcoded JIS dependencies. The Japanese can and do use wchar_t. Programming in Java ------------------------ If you are a C programmer and want to program in Java the way you program in C, it will take an afternoon to get started. Almost all of the effort is learning a new run-time package which has the same kind of stuff stuff as the CRTL, just with different names. If you are a C++ programmer and want to program in Java the way you program in C++, it will take a week to get started. On top of having to learn the new run-time, you also have to unlearn a lot of C++ creature comforts and syntax and expectations. If you want to program Java the way the designers intended, it will take six weeks. You will have to learn two books worth of run time interfaces, and then switch to an event-driven, thread-rich, model of programming. You have to define lots of methods for the run time to call, but on its own initiative. Things happen. Events occur. Your program must react correctly to all of them. The (wonderful) freedom to abandon storage management to the garbage collector is offset by the new problem of garbage threads that run and run and run. Here is an example of Java written by a C programmer (me, although this is much like a demo program from SUN). // FILE: tictactoe.java // PURPOSE: java demo application to play tic-tac-toe // MODS: mckeeman at zko.dec.com -- 95.12.20 -- original // who at where -- yy.mm.dd -- what // METHOD: The tic-tac-toe board is represented by two 9-bit vectors, // one recording the X moves, and one recording the O moves. // The correspondence between row, column and bit is b = 1<<r*3+c. // X plays first. O moves automatically (using a weak heuristic). // The class TicTacToe encapsulates the board and strategy. // The class Play provides main() and the play-by-play interaction. import java.io.*; // for println class BadMove extends Exception { // for throw BadMove() { super(); } } class TicTacToe extends Object { // all eight winning combinations final int[] wins = {0007,0070,0700,0111,0222,0444,0124,0421}; // center is best, corners next, edges are last choice final int[] best = {0020,0100,0400,0001,0004,0200,0010,0040,0002}; private int X, O; // record of moves public TicTacToe () {X = 0000; O = 0000;} // initialize private boolean taken(int move) { // move not available return ((X|O)&move) == move; } private boolean win(int board) { // XXX or OOO for (int i=0; i<wins.length; i++) { int w = wins[i]; // three in a row if ((board&w) == w) return true; // win } return false; // not win } public boolean Xwin() {return win(X);} // X won? public boolean Owin() {return win(O);} // O won? public boolean cat() {return ((X|O) == 0777);} // no more moves // make pretty output for tic tac toe board public String picture() { String b = ""; // empty to start for (int r=0; r<3; r++) { // rows for (int c=0; c<3; c++) { // column int m = (int) (1 << r*3+c); // convert to linear if ((X&m)==m) b += "X"; // an X else if ((O&m)==m) b += "O"; // an O else b += "."; // empty square } b += "\n"; // end of row } return b; // picture of board } // do what the player requests public void ex(int r, int c) throws BadMove { int m = (int)(1 << r*3+c); // row-col conversion if (taken(m)) throw new BadMove(); // reject move X |= m; // update X moves } // simple-minded computer opponent public void oh() { for (int t=1; t<=0777; t<<=1) { // look for O win if (!taken(t) && win(O|t)) {O |= t; return;} } for (int t=1; t<=0777; t<<=1) { // look for X win if (!taken(t) && win(X|t)) {O |= t; return;} } for (int i=0; i<best.length; i++) { // look for move int t = best[i]; // best first if (!taken(t)) {O |= t; return;} // update O moves } } } class Play extends Object { // io routines private static void output(String s) throws IOException { System.out.println(s); //print line } private static int input(String prompt) throws IOException { output(prompt); while (true) { char r = (char) System.in.read(); // a keystroke if ('0' <= r && r <= '2') { // valid? output(""); // signal acceptance return Character.digit(r, 10); // convert and return } if (r == '\n' || r == ' ') continue; // ignore whitespace output("enter 0,1 or 2 please: "+prompt); // complain } } // main program public static void main(String argv[]) throws IOException { TicTacToe ttt = new TicTacToe(); // new board while (true) { int r = input("row = ?"); // user input int c = input("col = ?"); try { ttt.ex(r, c); // user move output(ttt.picture()); // display results } catch (BadMove e) { output("square "+r+","+c+" occupied, try again"); continue; // try again } if (ttt.Xwin()) { // X wins? output("X wins"); // notification break; } if (ttt.cat()) { // cat wins? output("cat game"); // notification break; } ttt.oh(); // machine move output(ttt.picture()); if (ttt.Owin()) { // O wins? output("O wins"); // notification break; } } } } JavaScript, etc. --------------------------------------------- JavaScript is a language (from NetScape, previously called LiveScript) which can be embedded between html <script>...</script> tags in pages prepared for the NetScape browser. It does not need compilation, which makes it a good deal easier to use than Java. Executing JavaScript is slower than executing Java byte codes which, in turn, is slower than machine code. JavaScript is also less capable. It looks and feels a lot like tcl/TK to me, dressed up in Java clothing. One can think of a JavaScript as the inside of a single Java method with predefined hooks for screen events (like Click). The screen layout itself is done in HTML with tags like <input>. JavaScript can call into Java. Microsoft claims to be working on VBscript, a strict subset of Visual Basic, as a competitor to JavaScript. SUN is talking about using tcl/TK as a WWW scripting language. The author, Ousterhaut, quit UC Berkeley to work for SUN about two years ago. the WINNER --------------------------------------------- I believe that most simple interactive content in HTML is going to be in the scripting languages. JavaScript is not a carefully thought out language but it is established. Microsoft can probably force VBscript on everyone by just making it available in their favorite web browser. Ease of use will win all to the scripting language (except the nerd market). Java is easier than C++ but so is jumping off a bridge. ********************************************************** To unsubscribe from this list, send mail to majordomo at zk3.dec.com with the following text in the *body* (*not* the subject line) of the letter: unsubscribe gnhlug ********************************************************** ------- End of Forwarded Message
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |