Apache Jakarta and Beyond: A Java Programmeramp;#039;s Introduction [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Apache Jakarta and Beyond: A Java Programmeramp;#039;s Introduction [Electronic resources] - نسخه متنی

Larne Pekowsky

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Chapter 3. Eclipse


It is certainly possible to write Java programs using nothing more than the JDK and "vi" on Unix or "notepad" on Windows, but doing so is a rather arduous process. While most readers are likely familiar with the development process, it is worth listing the steps in some detail to discover where the inefficiencies lie. To that end, consider a typical development session using only an editor and the JDK:


1.

Code is written in the editor.

2.

The editor is suspended, or focus moved to another window, and javac is run.

3.

Numerous errors will likely be produced, such as syntactic errors like missing semicolons or braces, semantic errors like incorrect types, and missing or mistyped classes and methods.

4.

The editor is resumed, and one by one a sequence of keystrokes is used to access the troublesome lines as reported by javac.

5.

The syntax errors are relatively easily fixed, although it is easy to lose one's place in an undifferentiated mass of white-on-black text.

6.

The semantic errors are more difficult. Often the editor needs to be suspended or exited to look up some Javadoc information. Navigating this information may itself be time consuming, requiring many clicks in a browser to get to the right point.

7.

Repeat steps 16 until the code compiles cleanly. This may take a while.

8.

Finally, the program is run. In practice the best possible outcome of a first run is often a runtime exception. At least the exception reports a specific line number to examine. Return to step 4.

9.

Once the program runs cleanly, it may still produce incorrect answers. The developer then has two options: start adding println() statements throughout the code to track intermediate state or fire up jdb, the Java debugger included with the JDK. Neither option is particularly attractive.


It is possible to simplify some of these steps just by using a more sophisticated editor. Many editors color-code Java syntax, automatically assist in formatting, and make it easier to navigate around and between source files. Even with a better editor, the fundamental problems remain. Most of these problems reduce to a single issue: that five different programs are used (the editor, compiler, javadoc browser, debugger, and the program being constructed) at different steps of the process. Because each of these programs is run independently, there is no way that one program can inform or simplify the process of using the others. For example, if the compiler and the editor were aware of each other, the compiler could notify the editor of the line numbers at which errors occurred, and the editor could position itself at the right place automatically.

The recognition that using five programs to accomplish one task is essentially inefficient has lead to the development of

Integrated Development Environments, or IDEs. IDEs can trace their roots all the way back to the Symbolics Lisp Machines of the early 1980s. The concept became more widespread with programs like Borland's "Turbo Pascal" and more recently Microsoft's suite of development tools such as "Visual Basic," "Visual C++," and so on.

Throughout this history IDEs have had to walk a fine line. If an IDE is too bloated or slow, it may be more painful to use than simple command line tools. If an IDE tries to do too much, it may require users to adopt a development methodology with which they are not comfortable or happy. If an IDE is too simple, lightweight, or general, it may provide no significant benefit over simpler tools.

One approach to this problem is to design the IDE as a framework or platform into which new functionality can be imported. This approach works very well for IDEs that are themselves written in Java, since new functionality can be implemented as classes that are loaded dynamically. By implementing certain interfaces these class can fit seamlessly into the IDE and interact with other components already present. For example, a component that checks source code for syntax can integrate with the component that allows the user to edit files. Every time a new character is entered the syntax component can ensure that the file is still valid.

There are many IDEs and IDE platforms for Java, and many of these are free and open source. These include NetBeans (http://www.netbeans.org) and JDEE, which runs within the Emacs editor (http://jdee.sunsite.dk). The purpose of this chapter is not to recommend any of these over any other. Every developer has different tastes and requirements and may find one better suited for his or her use than the others. For example, NetBeans is written in 100 percent pure Java, and JDEE works with Emacs.

What this chapter will do is present Eclipse, a very powerful IDE from IBM that is justifiably getting a lot of attention. Most of Eclipse is written in Java, which makes it easy to add new components and functionality. However, the front end does not use Java's AWT (Abstract Windowing Toolkit) or Swing classes, but rather a toolkit called SWT (Standard Widget Toolkit), which is written in a combination of Java and C. The portions written in C makes the system very fast and responsive, but at the loss of Java's "write once, run anywhere" power. However, the full Eclipse system is available for most common operating systems, including Windows, Linux, Solaris, and OS X.[1] Note that because each version uses native graphics Eclipse will appear slightly differently on each platform. The screenshots in this chapter come from the Linux/GTK version, which should nearly match the appearance on any Unix variant. Other platforms will all have the same controls and abilities but will differ slightly in details.

[1] Note for FreeBSD users: Eclipse 2.1.3 is in the ports collection, and 3.0.0 should follow shortly. In the meantime both the Linux/motif and Linux/GTK versions of Eclipse can be run on FreeBSD by installing the appropriate Linux Libraries and a Linux version of the JDK. More complete instructions appear on the CD-ROM.



/ 207