Java Application Development on Linux 428
| Java Application Development on Linux | |
| author | Carl Albing and Michael Schwarz |
| pages | 600 |
| publisher | Prentice Hall |
| rating | 9 |
| reviewer | Ray Lodato (rlodato AT yahoo DOT com) |
| ISBN | 013143697X |
| summary | An eminently readable book covering all you need to develop commercial-quality Java programs on a Linux platform. |
The authors, Carl Albing and Michael Schwarz, chose to create a book that is a complete guide to writing commercial-quality Java programs. With the burgeoning presence of Linux, they focused on how to use the tools of the Linux platform to assist in the creation and maintenance of Java programs. They have broken the book up into five major parts: Getting Started, Developing Business Logic, Developing Graphical User Interfaces, Developing Web Interfaces, and Developing Enterprise Scale Software. Each chapter is self-contained, and the knowledgeable reader can pick and choose what they would like to read without losing track. Carl and Michael have properly started each chapter with a summary of what you'll learn, and conclude with a What You Still Don't Know section. A Resources section is included to give you more references for further study.
Part 1, Getting Started, provides a 10-chapter overview of Linux, Java, the SDK's (Software Development Kits) from Sun and IBM, version control via CVS, and IDEs. The first two chapters cover enough command-line Linux to manage your files and directories, plus the Vi editor to create and edit your programs. Chapter 3 gives you a summarized but complete overview of the Java language (minus the standard classes), and Chapter 4 covers how the program can deal with the context in which it's running. The next two chapters cover Sun's SDK and (mainly for comparison) IBM's development kit. In some instances, the Java program may be so large and/or so complex that running the byte codes in the Virtual Machine may not be quick enough, so Chapter 7 describes how to use the GNU Compiler for Java (gcj) to create native-code programs.
Larger programs definitely need some form of source control (actually, any project larger than a classroom exercise needs it), so source control using CVS is clearly laid out for you. While other products are available, CVS (Concurrent Versioning System) is widely available, robust, mature, and reliable, so the authors chose to describe its use in detail. For building and deploying the numerous files of a larger project, Ant provides value beyond what the make facility can offer, especially with the RMI (Remote Method Invocation) dependency problems that make can't address. Finally, Integrated Development Environments are covered. While Carl and Michael focus on NetBeans, SunONE Studio Community Edition and Eclipse are also covered.
If the book stopped after Part I, you would still have a valuable addition to your bookshelf. However, it continues with a five-chapter discussion on how to properly develop business logic. One chapter is totally devoted to the business aspects of getting requirements, documentation, and buy-in. The next covers how to use a simple software development methodology to analyze the program and discover the objects to be created. The following chapter goes over a frequently overlooked aspect of programming - automated testing - with JUnit. The last two chapters of Part II cover storing data in databases using Oracle, PostgreSQL, and MySQL, and using the Java Database Connector (JDBC) to access them.
While Linux users (at least the older ones like me) are more used to command lines, most users want some form of a graphical user interface (GUI) to access the program and their data. Chapters 16 and 17 describe how to create a GUI using Swing and the Standard Widget Toolkit (SWT).
By far the most popular way to access programs is via a browser. Java Servlets are (maybe not so) little programs that run on the targeted web server, relieving the user of having to install an application on their local computer. This allows the user to always have access no matter which machine they're on (how many times have you complained that the program you want is on the PC where you're not?), and to always be accessing the latest version of the software (assuming the web administrator keeps it updated on the server). Chapters 18 and 19 cover Servlets and JSP (JavaServer Pages), then Chapter 20 describes Java-based web application servers (JBoss and Geronimo) for serving the servlets.
Finally, Part V covers Enterprise JavaBeans (EJBs) in what the authors describe as an almost criminally brief introduction. While it is definitely an overview, they still cover more than enough about EJBs to get you rolling, and provide many references to where you can fill in the blanks. They wrap up the book with a plea for help. The book is an Open Content book, and therefore they are requesting comments, suggestions, and patch files to help improve the text and examples.
I have to admit that Java Application Development on Linux is an extremely readable, very informative, and deep without being lengthy book. (The only complaint I have is that they tried to cover a little too much in a single book. EJBs, for instance, definitely warranted more coverage than they provided.) Carl and Michael use a very conversational tone, just as though they were sitting with you and giving you their personal attention. I found it enjoyable, interesting, and highly informative.
You can purchase Java Application Development on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Working on a java app now (Score:5, Interesting)
The advantage: Java has abstracted alot.
The downfall: Java has abstracted alot.
For anyone who has done alot of programming in Java, they will understand.
I hope the book has a section on porting.... (Score:3, Interesting)
The Java trap (Score:2, Interesting)
So...? What's the big deal? (Score:1, Interesting)
Maybe the important point is "it does not matter which platform you use for Java programming, but by throwing in some buzzword into my booktitle, I can target more nerds and make some extra bucks".
Re:The IDE Issue... (Score:3, Interesting)
Re:Write once, run everywhere is called GCC (Score:3, Interesting)
Which, amazingly enough for a lie, I am now using to rewrite some of our inhouse utilities in preparation from the move from Win2k to Linux servers. There's not too much overhead on CLI Java programs, and I've ported one app so far, rewritten on my Windows box, and it ran without a single hitch on the Linux server it's destined for. No recompiles, no nothing.
Re:Java: I love it, but... (Score:3, Interesting)
We have hardly ever had any issues with "Write once, run everywhere." It works. Really. Probably writing Swing/GUI apps is different, but on the server side, developing and deploying across different platforms works like a charm. Admittedly the issues you get on development vs. production can be very different, so deploying a production system on multiple operating systems might give you different results. But as far as testing and developing on two platforms, then deploying on a third, we have no complaints.
Java and Linux (Score:4, Interesting)
I usually do my development on OS X (except for new JDK 5 coding - use my Mac as an X display for a Linux box -- annoying that Apple is slow getting JDK 5 out except for in a $500 developer's preview). Anyway, I do most of my deployment on Linux, and the ease of this depends on which hosting company I am renting a server from. For example, is a usable (i.e., PostgreSQL) database installed, easy to administer, etc. I have not read the reviewed book, but hopefully a lot of practical issues are addressed.
One interesting thing about the Linux platform is that now all new distros have RPMs (or equivalent) for installing runtime and developer support for GNU GCJ.
I find GCJ to be very interesting (a bit of a nuisance to run on OS X) because not only is it a way to run Free Software (GPL) on Linux, but it also makes it possible to take large Java applications like Lucene, compile them natively, and then use the compiled code in Python, C++, Ruby, etc. programs. Very cool, really.
If Linux was my development platform, GCJ would be a much more important tool for me - it would be great if Apple installed GCJ runtime libraries by default (yes, they are large). While Java is not as productive a language for many programming projects as Python, Ruby, etc., Java is a great language and platform for many types of projects; having GCJ runtime installed by default on OS X, Linux, and Windows (well
What about make and emacs? (Score:2, Interesting)
At my last job, back on 2002, ant forced me to hate it when:
1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
2. We had this crazy huge build.xml file that was created for our project. It started off life as a rats nest and only got worse from there (OK, probably not ant's fault but it had the same effect on me). On top of it being huge, its in XML which is way hard to read compared to a makefile.
3. I never could figure out how to ask ant to echo the compile line. Make echos it by default and I like it that way.
That was three strikes.
On my current project we are using make but one of them whipper snappers came along and made a build.xml file for the project. Its just one big, ugly, build.xml but it is much faster. The project has 30 or so small, easy to read/understand, makefiles (and I figured out how to make it go much faster on a clean build but its still not as fast as ant).
Sure, make has its quirks (e.g. the tab thing) but I figured all thouse out 15 years ago.
I tried Eclipse last fall after seeing an interesting presentation on it. I tried it for a couple of days but it felt so bloated that I soon abandoned it.
Re:I hope the book has a section on porting.... (Score:3, Interesting)
I developed the code using JDK 1.4.1 on Linux (Red Hat 9). Tested it on my workstation at work that ran Windows 2000 using both JDK 1.4.1 and 1.4.2, and have deployed it on two Solaris boxes and it has run under 1.4.1 and 1.4.2 (albeit better under 1.4.2).
There was no porting needed whatsoever. I used pretty much all of the NIO classes in my code.
Andrew
Re:I still fail to see .. (Score:3, Interesting)
Close, but no cigar. If there are enough binaries for the different platforms, you might not need the code. The bigger problem is that people tend to stack libraries - e.g. on the Windows libraries. That will really get you stuck.
The thing about java is that everyone is forced to distribute "source", or more specifically, bytecode, which amounts to the same thing for cross-system compatibility purposes.
Byte-code is far from source. Though many names (public class names, method & field names) are preserved, none of the code within methods, as well as parameter names will be preserved. Please stick to the Virtual Machine paradigm instead - it pretty much explains itself.
Can you make non-portable "libraries" in Java? Yes.
Well, only if you move outside the Virtual Machine (JNI/exec() calls from the VM), since the default API is available on any supported platform. So that's pretty difficult indeed.
We are probably in the same mind on this issue, but it seems that your explanation is more confusing than it needs to be.
EBay and Google DO use Java! (Score:1, Interesting)
You have clearly been misinformed:
eBay uses Java:
http://www.sun.com/service/about/success/r
They actually dumped
Google uses Java:
http://www.ccombs.net/weblog/2004/08/28/10
They were even part of the JCP (Java Community Process):
http://eyeonit.itmanagersjournal.com/a
Yahoo uses Java for their sitebuilder and chat, among other things. Don't know what they use for the main site but it wouldn't surprise me if Java was in the mix somewhere.
MSN:
Gimme a break!
CNN does use java in a limited way:
http://sportsillustrated.cnn.com/java/
If you still think Java is slow pay a visit to EBay and check out the number of transactions they process in one hour.