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.
Eclipse? (Score:4, Insightful)
BTW. the ret of my project was Java for a HP iPAQ 5555 which, interestinly enough was developed on Windows using IBM websphere device developer, which is based on Eclipse
Freespirit
The IDE Issue... (Score:5, Insightful)
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.
Sounds pretty wide-ranging (Score:5, Insightful)
* Basic Linux (files, directories, vi)
* Basic Java (two different SDKs)
* Basic software development (requirements gathering, et.al.)
* Basic programming (CVS, build tools)
* Basic Web programming (servlets, presumably JSPs, no Struts/Spring/other frameworks)
* Database programming (Oracle AND PostgreSQL AND MySQL)
* And finally, Enterprise Software in the guise of EJBs (remember: friends don't let friends use Entity Beans!)
Granted it's 600 pages, but I'm wary about how much real detail they can pack into all those topics. I'm guessing this won't be much of a reference book, but rather a large collection of introductions to a variety of Java topics.
Commercial quality apps? (Score:3, Insightful)
Re:Java: I love it, but... (Score:5, Insightful)
Re:I still fail to see .. (Score:3, Insightful)
(Just as a side note, the weirdest porting problem I had was the result of someone who shall remain nameless assuming that all filesystems are case-sensitive. I unpacked the source tar onto an HFS drive and spent ages trying to work out why some externs were undefined. tree.c was being extracted over TREE.c. There are so many assumptions one can make without checking that they hold for every platform - and even if they do, a future platform may break them if they're not part of a standard to which you're working).
Best java gui tk for linux (Score:3, Insightful)
Java-Gnome binds gtk with java. Very nice.
Re:Working on a java app now (Score:3, Insightful)
When I programmed in Java, it wasn't Java itself that was the problem with respect to abstraction, it was the dime-a-dozen here-today-gone-tomorrow APIs that appeared on the cover of JavaPro. My co-workers would get all hot and horny over some new API only to have it backfire due to bugs, high volatility between versions, or the API just solving the problem terribly. Java itself is actually quite good, and Sun makes an good effort with it. However, with popularity came idiots, and with idiots came the APIs. Kinda like that usenet/AOL article earlier today. And don't get me started on XML. Ugh.
Re:I'll be the first to quote Bash... (Score:5, Insightful)
if you're old enough to remember back that far, you will recall that when k&r released the c language, on of the big "selling points" was that it was a hardware/os agnostic language. you could write applications in c for a variety of different operating systems running on lots of different hardware and even re-use code, libs and entire applications (so long as you had the compiler, obviously).
the "write once" mantra has been with us for 30+ years... and, in that regard, java beats the living pants off the other contenders.
Wow... that's just troll-tastic! (Score:2, Insightful)
I congratulate you on providing one of the best examples of trolling [wikipedia.org]I've seen in a while from a non-anonymous post. Let's see if you've covered the basics:
Congratualations... you're a winner!
All sarcasm aside, if you don't like Java and don't develop software in Java, then a book whose title starts out Java Application Development is probably not for you. Moving right along....
Credit where credit is due. (Score:3, Insightful)
I've recently worked on a J2EE project with nearly 1 million lines of code -- they're all needed, really
Have there been platform related bugs? Yes.
Are there any open? No.
Are there some lurking? Maybe, but we've tested extensively.
Could any collection of jackasses build this app? No, sorry.
Is Java a magic bullet? No more than any other tool.
Binary Programs are not always appropriate (Score:2, Insightful)
Portability - You can't run C and C++ in a web browser very easily. In an enterprise environment, or even on the internet, you need to be able to distribute your application quickly. No one likes having to download a program from the Internet, especially in the days of spyware and adware. Allowing people to just run your program with code they know won't break their computer is the best way to fly. No to mention, HTML allows you to embed a Java applet much easier than CGI allows you to execute a local program, in my opinion.
User Interface Design - Ever try to write a Windows interface? What about a GTK interface? If you need a program whose main focus is in computation and calculations, not User Interface or data entry, an IDE like NetBeans will help you easily design the interface in an hour or two rather than having to manually code it by hand and constantly test how it looks. Before
Memory Protection - With Java, you have no worries about memory troubles. With C and C++, the developer has to handle his own memory allocation and garbage collection. Java does it automatically. What worries do you have when you dereference a pointer to 6 MB's of memory if Java is going to clean it up for you? There's almost no room for pointer miscalculations and for dealing with ugly Microsoft API's that handle six or seven different arguments, all either reading or writing and all being pointers. Unix API's are simpler but you still run into Segmentation Faults with Linked Lists and other Data Structures.
When you write an application, you want to focus mostly on the purpose of that app, not small CS details such as memory allocation and UI design. Obviously, some projects require this attention but for an enterprise project that isn't going to break into any new territory, eliminating as many problems as possible is the best choice. That's why languages like Perl and Java are great - very little chance to blow things up. I'd agree with someone that Perl might be a better choice in some instances over Java, but saying that C and C++ are better choices because you can compile them natively and run them a few milliseconds faster isn't a good reason for me.
Re:The Java trap (Score:4, Insightful)
Re:The IDE Issue... (Score:1, Insightful)
What code-generating GUI builder limits your ability to manually edit the classes? Certainly not Eclipse's Visual Editor plugin.
Re:Java: I love it, but... (Score:4, Insightful)
Yes, I know you could argue that "C" fits this bill nicely, too, but the fact is that most corporate IT shops at the time were VB and PowerBuilder clients talking directly to databases. Your average corporate developer would do more harm than good with C, and Java was seen as a simplified C++.
Anyway, I don't know if Gartner ever changed its stance on this, but the reality became quite different with the introduction of J2EE; J2EE required quite a different set of skills compared to good ol' J2SE, and many developers still can't adequately grok distributed server-side development.
Java is just a language, and I firmly believe that more attention needs to be given to the art of programming rather than to any specific language. It seems nobody cares anymore for appropriate use of patterns and careful selection of algorithms. It's all brute force programming. Get it done. Here's your soup - go code.
You can learn all the languages you want -- learn to speak English, Russian, Spanish, French, Hebrew, German and Greek -- but if you don't know how to communicate...
Re:The IDE Issue... (Score:2, Insightful)
Me too. But I suspect the book covered vim, not vi. That's a modern, good programmer's editor.
Personally, I've used Emacs for all kinds of text editing for ten years, and I can't see why I should learn another, inferior one just because I happen to be programming in Java rather than C, C++, Python or Perl at a certain point in time ...
Java on Linux Topics That Really Need Covering (Score:5, Insightful)
None of the topics mentioned in the review really seem to be Linux specific. Why not just call it "Java Application Development" (period, no "on Linux")?
There are some things that I think would be worth covering though, in a book about Java/Linux. Particularly for someone coming from a development of an app in a Windows Environment to deploying an app in a production Linux environment. Since often they will know all they need about Java. But won't be very familiar with Linux. And may not know the best way to do things in a 'Linux' way.
Some examples...
Init Scripts: Setting up init scripts to stop/start your Java services (e.g. getting tomcat to run on boot up). That differs a lot from how you'd do it with services on Windows.
Permissions I: Often on windows things will be run as root/Administrator. On Linux the better way is to have Java services run as a non-root user. e.g. run Tomcat as tomcat not root. There are some implications to this. e.g. you an unprivileged user cannot listen on addresses with sub-1000 port numbers. The solution is something like iptables or mod_jk2 [rimuhosting.com].
Permissions II: Another permissions issue (that I see crop up a lot with people moving from the Windows dev machine to one of our Linux servers for productions) is file permissions. Users being not being able to read/write config/data files that they had been able to see/use well enough on Windows. i.e. a paragraph on the almighty chown -R would be handy.
Command Lines: A page or two on running things from the command line would be a great thing. Often people working on Linux servers are doing so remotely. And won't have a GUI. And often they are only familiar with launching their app from the ide. So knowing about 'java' and 'javac' would be handy. And mention the need for colons between dir names not semi-colons. e.g. java -cp /myclasses:/3rdparty.jar mainclass.
Automating Tasks Users moving from a windows/dev environment to a Linux/production environment would also be well served by a page or two on automation tools. e.g. using ant to automate the process of getting code out of CVS and deploying it. e.g. cron for automating the process of running Java jobs on a regular basis.
--
Java Hosting on Linux, Simple Enough Even For Windows Users [rimuhosting.com]
Re:I'll be the first to quote Bash... (Score:2, Insightful)
kaffe (Score:2, Insightful)
The worst thing about Java, supposedly a "write once run anywhere" language, is that you can't run anywhere. You can only run on platforms that Sun has ported a JRE to. This is why projects like Kaffe [kaffe.org] are so important. With an open-source implementation of the Java specs, you never have to worry about unsupported platforms or Sun yanking the rug out from under you.
Re:What about make and emacs? (Score:3, Insightful)
Re:The IDE Issue... (Score:3, Insightful)
My team is working on a serious project right now (it will be responsible for > $20 million in annual revenue when launched).
We've used the refactoring feature in the past without issues. We also build every single time someone does a commit (using CruiseControl). Our policy is nobody leaves for the day if the build is broken.
We've had no problems at all with the "twerps" you seem to have.
Sounds like you might want to bitch slap some of your developers, teach them how to be part of a team, instead of ranting about the tool.
Re:Java: I love it, but... (Score:3, Insightful)
And for example C++, it should be "write once, port anywhere and then test anywhere"? At least with Java, you can skip one step.