Notice: This material is excerpted from Special Edition Using Java, ISBN: 0-7897-0604-0. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
by Alexander Newman
Where do we go from here? In thirty or so chapters, dozens of diagrams, and hundreds of lines of code, we've covered cutting edge changes in computing. Like it or not, Java has revolutionized what people expect from the Worldwide Web. The question is "is Java here to stay?" The answer, as with all prognostication, is a little murky.
Among those people who care about Java and the Worldwide Web, there are basically three camps: converts, realists, and reactionaries. But to keep things in perspective, there are hundreds of millions of people to whom Java means nothing. Not because they have other things to do or worry about, but because they don't interact with the Web or even the Internet. At last report, about one in every ten Americans had never used the Internet at all-and of those 25 million people, only one in ten used the Internet regularly. Out of those two and a half million people, only (you guessed it) about one in ten used the World Wide Web on a regular basis. That means that only about a quarter of a million people use the Web on a regular basis. Now, no study has been done yet, but looking at everything else, if you had to guess how many of those people were using Java or a Java-compatible browser, you might guess close to...one in ten.
To be honest, we don't know. Sun Microsystems claims that "millions" of copies of Java have been downloaded. Of course, many of those downloads were probably performed by the same people as each new iteration of Java appeared. Nonetheless, Java seems to be a phenomenon which is bucking the bell curve.
In this chapter we'll look at:
As the popularity of Java swells, many information specialists are using Java to provide a unique role in client-server databases: use of Java as a platform-independent client for network-accessible databases. Java allows the database programmers to focus on the functionality of the database without worrying about platform-specific issues, and for outside access to databases, an easy way to download the client to the user's specific machine.
The Java DataBase Connectivity (JDBC) Specification takes this one step further: database application designers write database-independent Java clients, which will in turn be able to connect to a wide variety of databases. Just as Java itself helped application designers write programs without worrying about the final user platform, programs written to conform to the JDBC specification are developed without worrying about the final database platform the user will choose.
Before the JDBC specification, database designers needed to take care of the interaction between the Java application and the standard database tools themselves. They usually accomplished this by running a helper application or server on a network-accessible machine, which would translate data between a Java applet on a user's machine and the database on the local system. The helper applications needed to be hand-coded for each type of environment: one wrapper for ODBC databases, another for I/Net systems, another for Oracle databases, and so on. In addition, there were some performance issues related to funneling all processing through a particular helper interface, in order to satisfy the strict Java security requirements.
The JDBC specification removes the hassle or writing that helper application. Java applications and applets are able to speak through the JDBC layer to the required databases, and the JDBC drivers are able to handle all of the database connectivity. If the database designer uses fairly standard SQL syntax when implementing his or her Java application, then any database product with a JDBC-compliant driver may be used, transparently to the database programmer.
The JDBC is not a product; it is a specification of an interface between a client application and an SQL database. It is up to the various database vendors and third-party software vendors to actually implement JDBC-compliant drivers to connect to Java applications to their commercial and free database engines. One of the first such drivers is expected to be the JDBC driver for ODBC-compliant databases, which will give Java programmers easy access to any ODBC-compliant database. The JDBC/ODBC driver (now, that's a mouthful) is expected to be available by June, 1996.
All of the major database vendors have committed to developing JDBC drivers for their on-line databases. As they become available, Java programmers using JDBC will have the flexibility to choose database engines which meet their needs and budget -- without re-writing any part of their Java code. At the time of this writing, there are almost 20 different companies who have endorsed the JDBC API.
The most common example of database functionality embedded in a Java application is to perform an database search for a given set of criteria. Using JDBC, the code fragment to perform the search might look like:
ResultSet rs = stmnt.executeQuery("SELECT compid, comp_name, comp_city FROM companies");
The select statement is passed through to the database engine by the JDBC driver, which in turn performs the search itself (hopefully, very rapidly), and returns the results back up through the JDBC layer to the client program. The client program may then step through the results of the search, and use the information in its interaction with the user. The results for the current row are obtained by fairly simple methods, such as:
rs.next(); // Moves to next row in result Numeric compid = rs.getNumeric(1); String comp_name = rs.getString(2);
The interface may also be used to update or insert rows within the database, using a similar type of statement:
Statement cmd = con.createStatement();
int num_rows = cmd.execute(
"update companies set comp_name = \"Leepfrog\"
where compid = 8337");
The JDBC specification also supports dynamic statements, where "placeholders" are given in the SQL string, or which columns are returned from a query are not known in advance and must be discovered at run-time. The above could have been written:
Statement cmd = con.prepareStatement(
"update companies set comp_name= ? where compid = ?");
cmd.setVarChar(1, "Leepfrog");
cmd.setInteger(2, 9337);
cmd.execute();
Of course, the values could easily have been variables reflecting user input or program calculations.
When using data types whose representation varies from database engine to database engine, you must use a special syntax so that the database driver may change the representation into one that the engine can understand. Such data types include date, time and timestamp (date/time fields). Similar handling is done for scalar functions, which in some databases are done by keyword (such as using "TODAY" to mean "today's date").
Advanced features of modern RDBMSs are also accessible through the JDBC interface. For example, if a database engine supports stored features, that procedure may be called by a Java applet through the JDBC driver, and outer joins between tables may be specified in a engine-independent manner, and the JDBC driver will translate the statement into an appropriate syntax for the database engine. The "update company name" may be a stored procedure in the database, with associated side effects. This could be called as:
cmd.execute("{ call update_compname[8337, \"Leepfrog\"] }");
The JDBC drivers allow client Java programs to query for the functionality available from a database engine. For example, if the database engine does not support outer joins, the client program may choose to use two SQL statements with a "UNION" to get the same results. The meta-information includes lists of callable scalar functions, permissions information regarding the current user, sorting order for NULL values, how the engine handles many of the different idiosyncrasies of the different SQL dialects, transaction handling, schema information, and so on.
The JDBC specification is very similar to Microsoft's ODBC specification, largely because both specifications are based on the X/Open SQL CLI (Call Level Interface). Database programmers who are familiar with either of those specifications will find that using the JDBC is a direct application of the concepts learned in their previous projects. In many ways, the JDBC is easier to use than ODBC, since the interface is naturally strongly typed to work with Java. Many of ODBC's shortcomings-such as string overflow, handling of very large binary objects, and mis-cast pointers -- are either easier to handle with Java, or don't even exist because of the way that Java handles data types of unknown size. The JDBC specification states that ease of implementation using common SQL APIs (ODBC, in particular) is a strong goal of JDBC; therefore, much of JDBC "tastes like" ODBC.
The main differences between JDBC and ODBC concern how the data is passed back and forth between the caller and the driver. Since ODBC is a C-based API, it makes use of "(void *)" casting to pass column results back to the calling procedure. Since Java is strongly typed, it uses methods which return the expected types to the caller directly, which removes a frequent source of ODBC errors. Since Java is not limited to static array sizes, concern with string overflow and the host of different character sizes needed by the database can be easily handled within Java. Retrieving large amounts of data from a database BLOB is much easier using a Java iostream than it is to use the corresponding ODBC methods.
JDBC also provides more flexibility in specifying a database's namespace, which allows users to more easily "find" databases on large networks. Since Java applets frequently have no knowledge of the user's file system configuration and naming conventions, the JDBC specification gives applet programmers the ability to choose the JDBC driver which will be able to correctly provide data access, and from there give the driver enough information to find the database on the local network or out on the Internet.
JDBC provides levels of security that are not present in ODBC, which faithfully reflects Java's overall approach to trusted/untrusted applets. Because Java's strict rules on security cannot be propagated through the ODBC layer, the Java security model may lead to an overly-strict enforcement by the JDBC manager in charge of the ODBC driver. In general, handling a trusted/untrusted mix of applets and device drivers seems to be a fairly sticky proposition, and users may be tempted to disable JDBC security entirely rather than deal with conflicting driver/applet permissions.
JDBC does not support scrollable cursors, or ODBC-style bookmarks, although this may change in the future.
As a Java program executes, it may have several JDBC drivers accessible for its use. One driver connects to ODBC-compliant databases, another connects to Informix databases accessible by I/Net, and a third provides access to any database following a well-published protocol. Each driver "registers" itself to the JDBC manager during initialization, so that the manager has an overview of the drivers available. The manager also tracks the "trusted" state of each driver, so that an untrusted applet may download an appropriate driver itself if one does not already exist on the system.
During a database connection attempt, the Java program passes a database URL to the JDBC manager. The JDBC manager then calls each loaded JDBC driver until one is able to open the requested URLs. Each driver ignores URLs that request databases that it cannot connect to. Java client programs may also bypass the "driver hunt" and specify explicitly which driver is to be used, if the Java client knows ahead of time which driver is appropriate.
JDBC URLs are in the form jdbc:subprotocol:subname. The subprotocol is the name of the connection protocol, and the subname is the name of the specific database within the domain of the protocol. If the subname contains information about the host and port numbers, then it is strongly suggested that the subname be encoded in the URL-standard //hostname:port/subname manner.
For example, the ODBC database customers may be specified by the URL jdbc:odbc:customers. The textbooks database accessible on the machine walker using the connection protocol ixnet would have a URL of jdbc:ixnet://walker/textbooks. To avoid collision between different subprotocols with the same name (which would confuse the JDBC drivers), JavaSoft provides information registration for URLs. Drivers will also likely be available which will allow URLs to use a formal named lookup mechanism (such as DCE), which would provide even greater flexibility in changing between different JDBC databases.
Each client may have multiple database connections open, each of which is an instance of a class derived from jva.sql.connection. The multiple connection may come from the same JDBC driver, or may be spread across a variety of different drivers. In many cases, the Java program will not care which connection goes where, but when the application needs to track which database features are available to the client, care must be taken to not confuse which connection has which features.
In keeping with its overall security module, Java keeps track of the trusted status of each database driver. Untrusted drivers have the same restrictions that untrusted applets have: they cannot access the local file system or network hosts other than their home. The JDBC manager will even go one step further: untrusted drivers will only be used on applets downloaded from the same host. During the connection attempt and ╥hunt╙ for an appropriate JDBC driver, the manager skips over untrusted drivers from different hosts. This may result in many copies of a particular kind of driver on a user's machine, but it prevents a malicious driver writer from hijacking a harmless applet which calls it.
Trusted JDBC database drivers must be careful not to extend their credentials upwards to untrusted applets who call it, particularly when it comes to other hosts on the network or the local file system. In particular, it is important that JDBC drivers which access real data do not allow untrusted applets to corrupt that data.
As the various database vendors release drivers for their databases, the database programmer will be able to swap their client around with different databases. Simple demos or beginning users may use small database systems, and then graduate up to larger, more expensive, more reliable database systems as their data needs grow. As they move, none of their investment in the Java/JDBC clients is lost; in fact, the client may be able to access the new databases without modification. The design, programming, and training investment with the old system is not lost-it is directly usable by the new database engine.
In addition to the flexibility of code reuse, there will be an exciting market of published data farms accessible over the Internet. Companies or organizations which maintain collections of information may allow remote querying of their information over the Internet. The schema and protocols (and possibly even custom JDBC drivers) for such data will be published, and Java applet writers may then spread out across the Internet to gather various information. As an example, a company which expends considerable effort compiling an accurate database of people in the United States may sell query subscriptions to its service. A data-entry applet can query on-the-fly the people database for records which match what has been entered so far, and the record populated. The company publishing the information as up-to-date as possible, and the subscribers see updates and changes as soon as they are entered into the database. There are already a variety of data servers on the Internet, but in general they do not offer a common means of accessing them. JDBC will change that.
Even more interesting are the application design tools which can be built on top of Java and the JDBC specification. Coming up just around the next bend, programmers will be able to easily develop an entire database application, in Java, using high-level visual design tools. The final result will be a cohesive graphical interface to a particular database design, which will run on any machine supporting Java, and can utilize any database engine which support the JDBC specification. Once written, the same application can be used both by Macintosh users who access a FoxPro database on their local machine, all the way up to a user on a high-end SGI workstation who accesses a large distributed Informix On-Line database over a fiber optic network.
Database vendors are also working on ways of extending the functionality of the database engine itself, by providing programming hooks which will allow a wide variety of data types to be stored in the database. No longer will database columns be constrained to the mundane char, int, date, time, interval data types, but any user-definable data type may be stored within the database proper, and searched by the database engine using normal SQL statements. Geographical positions (what is located near here?), graphic pictures (find me other things which look like that), HTML files (what documents have links pointing to here?) and so on will be accessible directly from SQL-and through JDBC, from any Java client running on any platform. The future of database client development is poised to change drastically, and Java/JDBC will be on the edge of the new technology.
The JDBC specification is very well-written and easy to follow, and provides the header files for the JDBC database drivers, along with a couple of examples of JDBC usage. The specification can be found on the web, at URL http://splash.javasoft.com/jdbc.
The major database vendors are also the best source of information about how their databases can be accessed using the JDBC specification. They are also the best source on the availability and schedule for their database drivers. Many vendors are also announcing additional Java classes for use with their engines, which enhance the Java environment even further. For up-to-date information, check out their home page on the Web.
There are three ways to make software popular: make it easy to get, make it easy to use, make it easy to run. Sun, by following Netscape's Internet play model of marketing, has made Java easy to get. It's free. More than free, they've established multiple websites where you can download Java at the touch of a button. You can get Java.
Sun hasn't done a particularly good job of making Java easy to use. The online documentation is limited, both in scope and volume. Supporting a product which you're not going to make any money off of just doesn't make that much business sense. Most of the support for Java comes from outside Sun in the rapidly developing Java community. Local user groups are springing up all over, and a national Java user group (Java-SIG) appeared last December. Sun does host a few electronic mailing lists, but they aren't moderated and there's no guarantee that you'll get an answer to your question.
One of the models floating around the net that seems to be picking up support is OpenDoc. OpenDoc is a multi-platform component software architecture which is designed to work across Mac OS, Windows, OS/2 and UNIX. Component software allows users to select the features they need to get the job done without forcing them to run burdensome monolithic applications. This means that when a user goes to create a presentation they don't have to build tables in their spreadsheet, graphics in a draw program and text in a word processor before lumping it all into a presentation application. Instead, they start with a blank page and add information using components which consist of specialized text, graphics or spreadsheet tools. OpenDoc supporters assert that OpenDoc would bring a whole new level of capabilities to Java programmers and applet users, allowing applets to be integrated seamlessly, and complex applications to be constructed of interchangeable components.
Developers worldwide have been attracted to OpenDoc since its introduction. By creating an architecture where smaller, more specialized software components can interoperate, OpenDoc provides an ideal environment for both independent software vendors and entrepreneurial developers. Since Apple made OpenDoc 1.0 available on the World Wide Web in November 1995, the site has averaged more than 1000 OpenDoc downloads each day. For more information about OpenDoc, visit Apple's OpenDoc Web site at:
http://opendoc.apple.com/
OpenDoc components are based on industry standards set by Component Integration Laboratories, an association of industry leading companies including Apple, Adobe Systems, IBM, Lotus, Novell, and Oracle. OpenDoc 1.0 for Mac OS shipped in November 1995 and OpenDoc for Windows is expected later this year. More than 300 developers have committed to delivering OpenDoc component software products, and Apple plans to introduce an OpenDoc-based Internet application suite (code-named CyberDog) as well as a series of parts and viewers that will allow easy integration of Apple technology, such as QuickDraw 3D, into OpenDoc-aware applications this year.
Many people believe Java is OpenDoc's best potential platform: a highly productive cross-platform environment with broad industry support and a rapidly growing audience.
More information about the OpenDoc for Java movement is available at:
We've already seen a variety of self-styled Java "experts" appear. Hot on their heels we've already started to see Java consulting firms and Java VARs. You may well ask "how does one become a VAR for a free product?" The key is the "VA" part of "VAR". VARs are Value Added Resellers. Obviosuly a company can't resell Java. Even if you could legally, the fact that Sun is giving it away would certainly cut into your market. However, the Java craze has created a niche for people to market packages on top of Java or related to Java: bundles of applets, Java 'gunslingers' for hire, and more. You can already get Java training from a number of places besides Sun. Once the fervor dies down, you'll start to see some of these consultants and instructors get shaken out of the marketplace, or merged together for survival.
As for making Java easy to use, Sun and a variety of other companies have come up with a novel solution to that problem.
Java is, after all, a computing language. You still need a computer to do anything with it. But Sun, as well as Oracle and a few other companies, have announced their intentions to develop low-end machines designed exclusively to run Web applications well.
These machines, called variously "hollow boxes", "virtual boxes", and "network access devices", depend on Java's "virtual machine" specification. As we've discussed, the Virtual machine defines a high-level instruction set for which the Java compiler generates bytecode, takes care of garbage collection, and also provides a minimalist interface to the underlying machine and operating system. Sun and other computer companies got people talking with the notion of a network computer.
The network, or "hollow" computer paradigm has a lot of support, particularly from longtime computer users who feel that Microsoft and Intel have an unbreakable lock on the home computing market. Hollow computing supporters say their approach breaks this grip which is based on Microsoft's Windows operating system and Intel Corp. processors. Currently, about 80 percent of desktop computers are Wintel machines.
In theory, these machines could draw applications and even their operating system from large servers, or even over the Internet, as needed-but that's not going to happen. In February, Sun conceded that, despite the hype, "hollow computers" will still require some operating software. Their solution? Codename: Kona.
Even though Sun chief executive Scott McNealy has gone on record as saying "the whole idea is not to give you an operating system," Sun's own version of the hollow computer is going to include a "minimal operating system layer." Sun's hollow box was demonstrated at the Uniforum tradeshow in early 1996. Uniforum is a conference focused on the UNIX operating system widely used by businesses for network purposes.
Sun's "Java client" (their name for the hollow box) is supposed to be ready by the end of 1996. To support the Java Client, Sun is developing its own operating system, code-named Kona. The Kona operating system is going to go head-to-head with other low-level operating systems, such as Oracle's Network Computer Operating System (NCOS). If both Sun and Oracle bring operating systems to market, you're going to have to choose one, with no guarantee that they'll run the same programs.
Kona "tricks" Sun's network device. Kona essentially makes the network server believe that the hollow box is a fully functioning machine. At a minimum, the operating system for a hollow computer would have to provide support for network connections and multithreading. However, it wouldn't have to support many of the operations that today's desktop operating systems support. Features like files systems, memory protection, or virtual memory.
Hollow boxes are also more secure than many of today's typical servers or other machines which are attached to the Internet twenty-four hours a day. With the hollow box model, you only attach to the Internet when you need to retrieve a piece of data, much like dialing up to an service provider with your home computer. Like your home computer, a hollow box is only connected to the Internet for short periods of time. By keeping your connect times short, you greatly narrow the window of opportunity for intrusion from the Net.
Kona supports Sun's Hot Java browser, although it's currently unclear which other browser the hollow box will support. Netscape? Maybe. We hope so. The only thing we know for sure is that Sun doesn't plan to develop any browsers other than HotJava.
Sun has always been a leading advocate of network computing. And that makes sense. In order for there to be network computing, you need servers, and Sun controls the majority share of the network server market.
Sun has been providing only sketchy details of its network device. The price for different versions would vary widely depending on which of Sun's many microprocessors end up in the machine, and on what sort of battery the machine uses in wireless implementations. Also, the Java client is being designed to connect to a variety of devices. Add a joystick, and you've got yourself a game machine; add a touch screen if you want a kiosk; or add the simple keyboard and mouse and you've got an all-purpose office tool. Essentially, Sun is covering all the bases. They're hoping to be able to stay on top by moving where opportunities come up, and they're going to try to move there fast.
Naturally, when we say "the future," we mean the future of Java. Well, there are a lot of players, each with their own agenda. Like anything else, they're not all going to succeed. Some are directly opposed to one another (like Sun and Oracle on the matter of hollow boxes), and some just won't catch the wave at the right time. After all, the only reason VHS is the standard for video cassette recorders is because Beta isn't.
Not a lot is currently known about Sun's "Java Chips", except how they are going to be executed. At this time, we don't know if they are going to be for "Java accelerators" or full-blown Java systems? More importantly, we don't know whether they're an entirely new design, or just a lightweight RISC state machine with a Java software front-end. The evidence seems to support the former, use of the Java Virtual Machine's machine code natively, partially eliminating the interpretation, but nothing is definite yet.
In February, 1996, in a move "to better reflect the division's breadth and depth", Sun Microsystem's SPARC Technology Business division announced a new corporate name and divisional restructuring. The newly entity named "Sun Microelectronics" was tasked with delivering merchant-market processing solutions including the industry's highest performance networked computing microprocessor cores, chips, chipsets, boards and services. In support of its business in networked embedded applications as well as the low-end of the newly-announced Java processor family, the division announced its Embedded Product Group.
Besides the fact that Sun Microelectronics sells Sun's UltraSPARC, SuperSPARC, and microSPARC technologies, it's not a division which has been in the spotlight a lot. They recently kicked off their Embedded Products group which is developing, marketing, and selling SPARC and Java processors into the emerging networked embedded marketplace. With their new family of Java processors, Sun hopes to open up a vast new spectrum of solutions for Internet and multimedia applications.
More information on Sun Microelectronics is available via the World Wide Web at
In the latter half of 1995, a team led by IBM Fellow Mike Cowlishaw at IBM's Hursley laboratory spent several months evaluating the Java environment. The team initially ported one of the versions to both OS/2 and AIX. In January, 1996, they released the JDK 1 for OS/2 and JDK 1 for AIX.
IBM is continuing work on ports to MVS and OS/400, as well as to Win16. The Win16 port is the one that is closest to completion. The chief technical problems that needed to be addressed were threads and long file names. They seem to be progressing towards the stage of a complete implementation of the JDK by use of existing code and raw intelligence, but no dates yet.
You wouldn't ordinarily think of an online service, no matter how large,
as having an impact on software development. That's not true in the case
of Java and America Online. When they introduced their own built-in browser,
AOL, with something on the order of three million subscribers, brought
the Web to the masses. Now America Online has announced that they've "endorsed"
Java. What does that mean to AOL subscribers? Probably that we'll see a
Java- compatible browser built into AOL by the end of
1996.
The real question is, "What does this mean for Java?" If AOL's web browser is Java-capable, than Java has just been introduced to millions of users who might not otherwise have access to it. In the first place, it's going to be a brutal field-testing. Every bug, every flaw, and every possible configuration of Java hardware (at both the server and client ends) will be stress-tested in a matter of months-if not weeks. If Java passes this battery of assaults, it could truly establish itself as the language for network programming. If it fails in someone, those failures are going to be well-publicized.
There's the additional element that your average America Online user's craving for Java may be satisfied with just the browser. After all, AOL doesn't currently offer individual homepages, so there's little need for their users to want to start writing their own applets. Their may be some "trickle down," as AOL users expect to see more animation and interactivity on the pages they visit, but that's not the same thing as encouraging people to develop their own applets.
One online service provider that does allow people limited access to
Java for their own Webpages is Boston-based Software Tool & Die. Their
online service, called The World, offers its customers a chance to use
Java on their own web pages. But placing a variety of parameter-intensive
applets in a publicly accessible directory, along with some on-line
examples, users with almost no Java experience and only limited HTML experience
can pull together sophisticated webpages using only simple tools. Users
can't currently compile their own Java source into bytecode, but that's
not too far off.
Throughout this book, we've been discussing what's right with Java, and how to get the most out of the Java language. That's because we truly believe that Java is a valuable resource that will continue to change the World Wide Web. However, we'd be remiss in our responsibilities if we didn't at least touch on some of the negative aspects of Java.
As we've discussed throughout this book, the Java language is a series of trade-offs. Each feature begets a limitation, and while the value of those features strongly out-weighs the detriments of the limitations, that doesn't mean there are no limitations.
Java is free. That's great; you don't have to pay anything for it. It also means that there's no single company supporting the language. Despite Sun's ownership of Java, the documentation, as we've said, is sketchy at best. which means that support for Java is going to have to come from elsewhere.
Java is secure, but that security places some unfortunate limitations on what files and devices a Java applet has access to, which limits Java's usefulness. Also, questions remain about how secure Java really is. Lack of security isn't a major shortcoming in an increasingly open environment, and we feel that if the Java development team hadn't made such an issue out of Java's security, people wouldn't be as focused on Java security as they are.
Nonetheless, even within the fairly stringent parameters that come with the programming language, the potential for abuse exists. For example, it's a fairly trivial matter to use JavaScript to grab the e-mail address of everyone who visits your webpage. It's equally trivial to automatically send e-mail to those people about your product, services, hobbies, etc. If you want to see how it works, visit
Before you rush right out and implement this code, think about this: Not only is this intrusive to the casual Web browser (think of it as the moral equivalent of junk mail), it's probably illegal. Certainly, if you're a commercial site, utilizing a script like this one (and configuring it to gather even more information) violates the US laws regarding consumer privacy. What impact will that have on overseas sites? That will vary from place to place, but that's one of the wonders of the Worldwide Web.
We expect to see Java spawn a small industry within an industry. Look for a whole range of software tools to help you write better, faster, and smaller applets. Imagine a helper application where you could combine several applets from a large library of pre-existing applets to come up with a new applet-all with but a few clicks of the mouse. You won't have to wait too long; several companies are working on these helper programs even as we speak. Be patient as these start to appear; the first one to market isn't always the best.
Also, look for applet swaps to start-up. Applets are small, portable (you can fit them on a floppy), and run the range from utilitarian to amusing to creative. They could become high-tech baseball cards. People will bring their applets on a disk to a single site, with a Java compatible machine. Programmers can show off their creations and pick up a few new ones while they're at it, in a casual atmosphere.
There are several conferences and magazines focusing on Java in the works. Like most things, some will stick, the conferences will become annual events, and some will fail. One such magazine is JavaWorld Online, from the publishers of SunWorld Online. You can find them at:
You can also check the newsgroup comp.lang.java on a regular basis for updates from the world of Java.
We hope this book has done what you hoped it would, whether that was to provide you with a general overview of this hot new programming language, or to provide you with the knowledge you needed to design and implement your own applets and applications. This is just the beginning for Java, and all of us who work with Java are looking forward to seeing where the future takes us!
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation