Slashdot Mirror
Java Application Development on Linux
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.
*sigh*
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.
Sloppy programming and / or paranoia by the developer.
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.
Advanced users are users too!
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
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.