Interview: Best-selling writer Harold Java I/O

Elliotte Rusty Harold

This article is translated from the o'reilly American Head Office website,

Do not think that Java can only be used to design dynamic images on Web pages. In fact, Java is a fully functional programming language and the first choice of many programmers today. Because the Java language has a clear architecture, provides dynamic memory management, and integrates web... So that the Java development process requires less time than many other development tools. The book Java I/o recently published by best-selling author elliotte Rusty Harold gives us a deep understanding of the internal mysteries and usage of Java I/O. We specially invited him to interview us for several minutes, targeting Sun's planned Java I/O direction.

Wayner: which type of Java programmers should be interested in Java I/O related topics?

Harold: All Java programmers should be interested in Java I/O. Almost all programs involve I/O more or less, even though they have their own purposes. However, the I/O examples in textbooks are often limited to command line arguments and system. out. println () ignores the need for real programs to read and write files, read and write networks, encrypt and decrypt data, send data from the serial port, and communicate with the database... . We can usually judge the degree of professionalism by observing the I/O capability of a programmer. The farther the programmer is from system. Out. println (), the more professional the programmer is.

Wayner: Many people have been impressed that Java is a tool used to write web applications, but Java is actually a fully functional programming language. What do you think of the I/O comparison between Java and C ++ with the complete functional programming languages?

Harold: without a doubt, Java I/O tools are more practical, powerful, and easy to use than C/C ++. C/C ++ and many other languages assume that the data read and written by devices such as the Yangchun terminal in the 1970 s cannot keep up with the times, modern C/C ++ programmers suffer deeply from this. Java is the first mainstream programming language to discard this burden. Java designers have long realized that file reading and writing, network connection, and communication with the serial column ports are very important. It is not the first-year student program of the Information Department. "One number is read, output the value of the root number.

Unfortunately, because the structure adopted by Java I/O is quite different from the past, many programmers do not know that it is actually very simple but powerful. From the reactions of my students, the many discussion forums, and the mailing of discussion letters, I found that most people initially asked questions that should not be asked. For example, people often ask how to read a number from the console. In fact, they should not deal with the console at the beginning.

Students are always asking if Java has a usage similar to C's scanf (). I think it is important to blame the professor for failing to teach well. A bunch of books on the market that introduce Java often teach readers how to use Java to write functions such as scanf () and printf (), which are equivalent to C. I think the reason behind this phenomenon may be: "The author does not know Java at all, especially Java I/O", or "the author directly follows the old Pascal example that has not changed for 20 years, 」. Now it is 1999. The user interface should be in the graphic mode (GUI) rather than the text mode (console ). It is necessary to introduce students to modern GUI programming methods in the Information System Curriculum. Now, I am teaching a postgraduate Java introductory course, with no more than 10 percent of the students in the class having experience in Gui programming.

Of course, the user interface is a GUI, which does not mean that the traditional I/O mode is no longer important. However, once you discard the console, you can design a clearer I/O interface to easily support archives, networks, etc... And so on.

Wayner: For those Web applet designers, how does Java I/O affect them?

Harold: Java's security mechanism strictly limits the I/O actions performed by the applet in the Web browser. Currently, the main browser does not support the Java 2 security model, so it is purely "Theoretically acceptable, but actually not 」. In addition, most users do not want the website designer to relax the applet permissions more easily. Therefore, generally, the I/O used by the applet is to establish a network connection with the original server, or use Object serialization, or RMI.

Wayner: When Microsoft began to build its own Java branch, it did not use RMI to change its method. What do you think of this?

Harold: Microsoft does not need RMI because they have their own set of Windows exclusive technology DCOM. Microsoft has also established the technology of embedded dynamic content on ActiveX web pages to differentiate themselves from Java. However, no matter whether it is DCOM or ActiveX, it has not achieved some benefits in the Web Design Market, and Microsoft has abandoned them for the benefit and some purpose. In fact, the RMI and underlying Object serialization mechanisms are really slow and terrible, and the culprit is Java itself. Most of the large and non-applet projects I have come to use CORBA, rather than Microsoft's DCOM or Java's RMI.

Wayner: Do you think NC wants to download the software and execute it as an applet? Is this possible in the new version of Java 2?

Harold: if this happens, it won't be on a PC or any computer platform. Set-top box is a suitable platform for this method.

Wayner: does Sun provide sufficient Unicode support for multi-cultural and multi-language programming? Or is it just a preparation?

Harold: since Java 1.1, Java I/O categories have fully supported internationalization. The main problem is that programmers are not very familiar with this, because they always use a method of thinking that does not support international programming languages (such as C or Pascal), which is strongly applied to Java I/O, in fact, they do not match each other. Once you know How to logically cut functions between languages in different countries in Java and their connection methods, it is easy to use them, however, if you want to achieve the same purpose in other programming languages, you will find that the complexity is hard to control.

Wayner: Is there any I/O function that sun needs to strengthen or expand?

Harold: currently, Java does not support data in the format of "little endian" or values in other order (such as the Floating Point Number of VAX ). However, in Java I/O, I designed some categories to tell readers how to read and write data in special formats to data streams ). These categories can also be easily connected with standard data streams.

Wayner: Do you think Java needs to support more coding methods?

Harold: Obviously, we need Java to support the new Latin-0 word set to include the euro symbol. In addition, Unicode 3.0 will be available in just a few months, and Java also needs to make some corresponding fine-tuning after the curtain. Such an action cannot affect most existing programs. In addition, IBM claims that sun has disrupted the ebcdic conversion code, which also needs to be improved (I personally think This is IBM's fault, if they standardized ebcdic and sorted out its files, ebcdic would not be so messy today ). Apart from the above problems, Sun is actually doing well in supporting most word sets.

Wayner: Many people complain that there are many differences in the Java environment of different companies. Have you found any serious problems due to this? What should we pay attention?

Harold: The biggest problem with I/O is Java. Io. File. Although it has been improved in Java 2, it still shows its UNIX lineage. Java. io. file works well on UNIX and can be used on windows, but it cannot be ignored on Mac because of Java. io. file has made many simplified assumptions about "what is the file" and "How should the file name be", but many of these plus assumptions are only compatible with UNIX environments, not applicable to non-UNIX platforms. There are also some potential problems. For example, Sun determines that as long as two arbitrary separator characters cannot appear in the file name, they can be used as the separator Number of the file name and the path separator number respectively, this assumption conflicts with Mac. for Mac, only one character cannot be used as a part of the file name. This requires some Luo Yun steps to port Java to an Apple Computer.

Wayner: the last question: do you think Sun is doing well in making Java cross-platform? Or do you think there are some places that are too UNIX-based?

Harold: for cross-platform platforms, AWT is a big headache. I know it is quite difficult to design a GUI class library that can span windows, Mac, and motif, but sun did not even try it. However, after the advent of Java 2 and swing, the situation has improved. Although improvements have been made, Java is still very poor in this regard because it comes from the hands of many UNIX programmers who do not know much about Windows and Mac.

Java Network APIs (for example, java.net. socket and java.net. serversocket) are also UNIX-based. However, Windows and Mac are also similar to Unix in the network. Therefore, it is not easy to detect UNIX flavor on Java Network APIs.

--------------------------------------------------------------------------------