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.
Re:Java: I love it, but... (Score:5, Informative)
I can't remember the last time I had issues with code because I changed platform, OS, or even JVM version. It's to the point where I don't think about it anymore.
Maybe if you're talking GUI code (desktop/applet), but for web or backend it's just not been an issue for me in some time. I've been developing on Java professionally for nine years now, and have have production systems in place for eight. I remember when you used to need to test every single VM, but by and large that time is done.
For example, I just finished working on a project running on J2EE 1.2 on Websphere 4 (jdk1.3.1) on Windows to running Websphere 5 (jdk1.4.1) on Z-Linux. The *only* thing I had to change was code that was written out of spec (a few JSPs forgot to import java.util.Vector). If the developers of the app hadn't been sloppy, there would have been no code change at all. This is an app that hits databases on Oracle, DB2, Teradata, and LDAP (with updated drivers for all of those, too).
I can think of plenty of counterexamples, but for most server-side business apps it really is write once, run anywhere.
success largely depends on expertise (Score:3, Informative)
Our product that runs on Linux/Solaris/AIX/Win32 also runs wonderfully on OS/390, but this is only AFTER the code base was revisited to respect that fact that a 390 is EBCDIC. For example, ASCII config files that you ship along with your distro to the 390 will be read in the system default encoding if you're using plain Readers. You'd want to use streams with an explicit encoding type. Or, just use XML since the parsers internally understand UTF-8.
So, some may say "debug everywhere" but in some cases this isn't being completely fair, if you're placing the whole blame on the JVM.
Re:Java: I love it, but... (Score:5, Informative)
Anything written for java 2 (1.2 and up) should work fine on the latest 1.4.x, and will probably work fine on 1.5 (I have had some funny issues with 1.5, but they were build time issues)
The only thing I've encountered that actually broke stuff in a version change was the bizarre choice by Sun to not just deprecate reading the OS environment, but to completely disable it by causing it to throw a runtime exception in 1.4 They changed their mind and re-enabled it and un deprecated it for 1.5 though.
Re:Run everywere, my ass. (Score:3, Informative)
If you are running OSX 10.3 you are running a very new version of the JVM. If you are running OSX 10.2 you are also running a very new version of the JVM. So I guess my question is what OS are you running on it?
Now you mention that you don't "miss" Java. I will argue that you don't care what an application is written in, as long as it looks good, is stable and does what you want. So I challenge you with this. How do you know what the application was written in? You probably don't. If you are a Linux/Macintosh/Windows/Netware/Solaris user and you launch your MP3 player and it works do you really care to see if it was written in C, C++, Java, Cobol?
JAVA runs on all MAJOR platforms.
It doesn't require the user to "compile" any code to run.
It has a rich GUI toolkit built in.
It handles object cleanup well.
It's speed has become excellent at most tasks
It has excellent networking support built in.
It has a giant developer base helping to add funcitonality.
Re:The IDE Issue... (Score:5, Informative)
You *really* need to have a look at Eclipse. Debugging is nice, but it's not the whole crop.
What's at the top? It understands your code. The first thing you'll notice is the incremental compilation. You don't have to ctrl-z (or alt-tab or whatever) and run the compiler and wait. It compiles it as you're typing, and tells you where you've screwed up. That improves your efficiency right there.
Next on the list is lint-checking. This starts with needless imports, and continues with warnings for unused private methods, empty and undocumented catch blocks, and a host of things that are easily missed. It's a real eye-opener to load up your vi-edited code into Eclipse and see the cruft.
Last, and most powerful of all, is refactoring. I can, with that dreaded mouse, move a class between packages far faster than you can even if you're a regexp wizard. I can rename variables and methods without fear. In short, I can do everything I need in order to make sure that the codebase makes sense. No more comments like, "This method doesn't do this anymore, but it's too much hassle to change its name"
Knowing that classnames and packages aren't set in stone, you are much more free to get to writing the code, and change what you need to change, as you discover the need to change it.
If I had to guess, I'd guess that you tried JBuilder, didn't care for it, and haven't looked back. Eclipse is so radically different from that environment that its almost miscategorization to call it 'an IDE'.
-Zipwow
Re:I hope the book has a section on porting.... (Score:4, Informative)
I think you'll find that the java.nio classes are actually non-blocking IO, not native IO.
And in all my years developing Java on AIX, Solaris, Windows, Mac, and Linux, I've yet to come across a platform specific class (at least in the core APIs or any API written in pure Java - JNI excluded). In other words, there are no OS gotchas. There are, however, app server gotchas, but that's a different story.
Bob
Re:I'll be the first to quote Bash... (Score:2, Informative)
Re:Eclipse? (Score:4, Informative)
Re:Run everywere, my ass. (Score:3, Informative)
Some of this is the same in JAVA but with one difference. You don't compile the source code on the machine. You send them a JAR file (zip compression) and in most cases they can just click(or double click) on that file and it runs. Doesn't that sound better? Send a file to a user, have them click on it and it runs? Heck you can even do one better. You can use Java's web start and have them go to a web page, launch the app from the page, it will check to see if you need a JVM installed, if so it will install one (major platforms only), then copy the application down to you and run it. The next time you try and run the app it will check the server automatically for updates and download them if needed. If for some reason the network is not available then it will run the local copy. Some people hate this, but a ton of developers and businesses love it. So now you have two ways of delivering your application. One with Webstart and one with sending a JAR file. No compile needed on either one. All the user needs to do is click on the file and they are off and running.
Lastly, I would also argue that if you have some basic users out there it will be far far easier to get them to load a JVM(with or without using webstart) than it is to get them to load a C compiler. The JVM installer has come a long way on all the major platforms.
Again though I ask you. Do you really care what the code was written in? When you click on your Instant messenger, Email client or CD/DVD burner and it runs, do you care what it was written in? If so then why?
Now I as a developer who wants to write a DVD burner have three options.
I only target Windows because they own 93+% of the desktop market? Most will answer yes to that question and use only Microsoft stuff, and lock the app in to the Win32 API set.
I can develop the application in JAVA and make the installer check to see if the user has a JVM installed. I then can focus my testing on Windows and the product should (without recompile) run on all other platforms.
I could write the software in C or C++ and force the user to have a compiler for their system, (good luck on the various windows versions), then compile the code on that system, create icons for them and they would be off an running.
Out of those options most developers choose options 1 (sucks but it is reality), a few pick option 2 and only open source people pick option 3.
lastly I want to point out that NOTHING is stopping the developers in option 1 or 2 from giving the source code away also. So those brave souls who wanted to compile it could. I can say that I run a quite a few JAVA applications from sourceforge that were written soley on Windows and tested on Windows but because they were written in JAVA I have had GREAT luck in getting them all to work on Linux. Specifically 64bit SuSe. Now getting C source code and compiling it.... Well that is another matter. I still don't have a working copy of Mondo, and can't compile it to save my life.
Re:What about make and emacs? (Score:2, Informative)
Ever try Maven [apache.org]?
build.xml files tend to get crufty. Maven builds are sleek, particularly if you write your own plugins to handle the odd bits. And the mevenide integration with both Eclipse and Netbeans is almost flawless.
Re:Java: I love it, but... (Score:4, Informative)
I have coded a wide range of applications, and have used many of the facilities provided by Java. NIO was the only part of the standard library that gave me trouble. However, I have a friend who was using Java3D for a project. His jobsite uses pretty much the gamut of operating systems. He has told me that Java3D is just plain not portable. Code that worked on Windows would not work on Solaris. I have no details on this, but they ended up using something else, according to him.
It ain't just the compiler, Luke. (Score:2, Informative)
Java comes with portable GUI libs.
Re:The IDE Issue... (Score:3, Informative)
Re:The IDE Issue... (Score:2, Informative)
Re:I hope the book has a section on porting.... (Score:3, Informative)
Re:I still fail to see .. (Score:3, Informative)
Although you can decompile java byte code with some degree of success, obfuscators exist which can be applied to the byte-code before you distribute it to make decompiling nothing but a waste of time as the code is irrevocably incomprehensible (and some byte-code obfuscators mess things up so bad that the decompiled code won't even compile at all!) Use of such obfuscators is not bad programming practice in the same way that obfuscating source code is because you are still working from clean source. In this sense, java byte-code obfuscators have more in common with the unix utility 'strip', than the conventional notion of an obfuscator. You can set things up in your build.xml or makefile so that the obfuscator can automatically be run on each class file as it's generated, whenever you specify a target intended for distribution.
Re:"Commercial quality"? (Score:4, Informative)
That is the fault of the programmer, not the language.
Chapter 2: Meanlingless error messages
The application programmer decides the error messages. Uncaught exceptions might show to the end user, but if you don't understand these, show me a language with clearer error messages? "ArrayIndexOutOfBoundsException? FileNotFoundException? MidiUnavailableException? What does this mean, I do not understand any of this. Owie my brain hurts...."
Oh, and it is spelled "meaningless". HTH.
Chapter 3: Remaining slow no matter how fast the hardware is.
Chapter 4: Losing data.
And finally:
Chapter 5: How to create the blue screen of death.
Hmm...seems I just responded to a troll.