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.
Saying that Java is good because it works on all platforms is like saying that anal sex is good because it works on all genders.
I do some of my development in linux, and some on windows. I have found some differences in linux but very few. There is one huge advantage of java, and one huge downfall.
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.
While Carl and Michael focus on NetBeans, SunONE Studio Community Edition and Eclipse are also covered.
Editing Java in vi is one of the biggest waste of time I can imagine. Eclipse and Intellij are far far more productive environments in ways that are too numerous to describe. I think a Java development on Linux book should really ignore vi and just be an Eclipse centered tour at this point with a little bit of documentation on bash usage , scripting, deployment issues and tuning the environment.
*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.
Well, here's another article just beckoning me back to try Java development once more. Here I am, on the rebound again, not knowing any better. Almost forgetting the tough time I had creating GUIs, coming to grips with the AWT then Swing. Going nutty putting multiple classes in a jar file and all that manifest destiny sweet talk that had me at "hello world" but not much further when I ventured out past the simple stuff.
.NET, but too afraid to jump head-on into a relationship with cpp.
Oh yes, it was sooo much better than VB if you can get past the quick way to make graphical interfaces. The multi-threading made creating a multiplatform port-scanning tool so much more pleasurable.
Then there was running the code on multiple platforms. The need to install the JRE, ensure you're pointing to the right CLASSPATH, and all those somewhat cumbersome things.
Yeah, after a while, I forget those experiences. I come crawling back, not wanting to be assimilated in
I'm sure it's going to take time and effort, and I know I need to put more time in our relationship. Right now, though, I'm in the middle of a project with PHP so I'll get back to you when I can. Just remember, Java, that it's not you...it's me.
P.S. -- I think your father's a prick.
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!