Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Software Programming Book Reviews Linux IT Technology

Java Application Development on Linux 428

Posted by timothy from the not-those-weird-coffee-capsules dept.
r3lody ((Raymond Lodato) writes "Java was developed to be a cross-platform language. In other words, it shouldn't matter what processor or operating system you used, just the language itself. Write Once, Run Anywhere is the slogan, and an admirable ideal to attempt to reach. So when I first saw the title of the book Java Application Development on Linux, I expected to find descriptions of some idiosyncrasies in the Linux environment that affected the Run Anywhere part of the equation. What I got was a lot more." Read on for the rest of Lodato's review.
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.
This discussion has been archived. No new comments can be posted.

Java Application Development on Linux More

Java Application Development on Linux

Comments Filter:

  • I'll be the first to quote Bash... (Score:5, Funny)

    by vbdrummer0 ( 736163 ) on Tuesday January 25, 2005 @04:15PM (#11473115)
    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.
    • But anal sex is good because it works on all genders! So I guess you are saying that Java is good because it works on all platforms. Kinda redundant. Maybe you should think about considering a vocational job in the Department of Redundantcy Department.
    • And it works on many mammalian species!!!

    • Re:I'll be the first to quote Bash... (Score:5, Insightful)

      by Frymaster ( 171343 ) on Tuesday January 25, 2005 @04:43PM (#11473446) Homepage Journal
      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.

      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.

  • Working on a java app now (Score:5, Interesting)

    by I_am_Rambi ( 536614 ) on Tuesday January 25, 2005 @04:19PM (#11473157) Homepage
    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.
    • But everybody knows that Abstraction Is Good. That's why Wittgenstein and Kirkegaard are so much easier to understand than Zane Gray and Mickey Spillane.

    • 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 AP
  • The biggest issue with cross platform development is the "Gotchas". I'd like to see a list of what is actually different between all the OSes. What os specific parameters are there. What classes are unique to Linux devices. Especially with the native IO that 1.4 and later have included.

    • Re:I hope the book has a section on porting.... (Score:4, Informative)

      by CowboyBob500 ( 580695 ) on Tuesday January 25, 2005 @05:08PM (#11473743) Homepage
      Especially with the native IO that 1.4 and later have included.

      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
    • I recently wrote a multi-threaded socket based server that uses the NIO classes. This application uses not just the network portion, but also utilizes the DirectAllocate functions for memory allocation. DirectAllocate does use system calls to allocate memory directly in order to speed up all the manipulations of the buffers. I.E. Sun recognized the fact that when manipulating large buffers in memory....it can be slow when having to go through a translation layer. So, there are native libraries needed fo
    • biggest recurrent issue that causes complaints to the Ant team (I am one member) is that there is no way in Java to tweak file permissions. That is right, Java, written by a Unix vendor, has no way to read/write unix file perms. which sucks, and usually surfaces as "Ant copy task broken" bugreps.

      As far as NIO, the only problem I know there is that you cannot select more than 64 objects on windows, which is MAX_WAITABLE_OBJECTS on WinNT/DOS.

  • Eclipse? (Score:4, Insightful)

    by nhnfreespirit ( 809462 ) on Tuesday January 25, 2005 @04:20PM (#11473172) Journal
    From skimming through the review, I saw no mention of Eclipse. I wrote a large part of my Masters Thesis in Java on a Linux machine. Sure, Í could use vi, emacs or whatever and a command line compiler, but for me Eclipse is the Java development tool of choice.

    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)

    by TheNarrator ( 200498 ) on Tuesday January 25, 2005 @04:23PM (#11473196)
    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.

    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.

    • Editing Java in vi is one of the biggest waste of time I can imagine.

      Yea.

      /me puts on flame-resistant suit
      You should use EMACS, of course !!!

    • Re:The IDE Issue... (Score:3, Interesting)

      by pzarecta ( 775947 )
      I've been programming Java for years and I've always used vi. How much time have I wasted? I find IDEs a bigger waste of time. IMO, every second my right hand leaves the keyboard to reach for the mouse is time wasted. The only thing you get from a graphical IDE is the ability to step through the instructions. But there are other ways to compensate for that...

      • Re:The IDE Issue... (Score:5, Informative)

        by zipwow ( 1695 ) <zipwow@g[ ]l.com ['mai' in gap]> on Tuesday January 25, 2005 @04:58PM (#11473616) Homepage Journal
        The only thing you get from a graphical IDE is the ability to step through the instructions.


        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
    • Editing Java in vi is one of the biggest waste of time I can imagine.

      Perhaps for experienced developers, but for those just getting familiar with Java, you can't beat a text editor. IDEs obscure too much of what's actually going on. If you learn java with an IDE, you'll likely find it difficult without one. But then, "graphical programmers" seems to be the big rage these days.

    • Re:The IDE Issue... (Score:2, Insightful)

      by jgrahn ( 181062 )
      Editing Java in vi is one of the biggest waste of time I can imagine.

      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 ...

    • Re:The Java trap (Score:4, Insightful)

      by Joe Tie. ( 567096 ) on Tuesday January 25, 2005 @05:06PM (#11473721)
      I'm a little lost as to what your point is in linking to that. Are you suggesting people don't use java, or that people stick to gcj, gnupath, and swingwt? If the latter, isn't it a bit redundant given that gcj is specifically mentioned as being covered in the book?
      • I'm a little lost as to what your point is in linking to that.

        Posting links to anything remotely related on GNU.org is an easy way to get modded up.
    • *Flameproof suit on*

      Jesus, Stallman can talk a load of crap. Most people use an OS, program, language, whatever because of the *benefits*, not because of some ideology. Stallman can really come across like a religious fundamentalist sometimes.

      Is he seriously suggesting that no-one should ever use any proprietary software? So what if Java isn't licensed under the GPL?

      And then there's this:-

      If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even no
      • Most people use an OS, program, language, whatever because of the *benefits*, not because of some ideology.

        That's not an argument: Most people do foolish things. More specifically, things that are easy in the short-term, but may hurt in the long-term. (Most programmers don't use version-control systems, which is really scary!) One example: putting all you documents in a proprietary undocumented format so your documents are at the mercy of one company. Another example is writing your programs in a proprie

  • Sounds pretty wide-ranging (Score:5, Insightful)

    by Doctor Memory ( 6336 ) on Tuesday January 25, 2005 @04:24PM (#11473216)
    Let's see, they discuss:
    * 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)

    by Profane MuthaFucka ( 574406 ) <busheatskok@gmail.com> on Tuesday January 25, 2005 @04:37PM (#11473358) Homepage Journal
    I know what they mean by that, but really I'd like to have open source quality apps. That's the next level up.

    • Bzzz.. you missed something.

      "Commercial quality" and "Open source" are two different possible aspects of a piece of software.

      Don't fall into the FUD trap, there are plenty commercial quality open source applications. There are also plenty of commercially sold open source applications.

      There's nothing wrong with that.

      - Erwin
  • I think a good baseline is to stick to that Java which can be compiled and run by the gcj* toolchain. This is for your own protection - in the event a vendor (gee guess who) ticks you off you will always have a free option.

    While the gcj toolchain is not capable of supporting bleeding edge features, its likely you do not truly need these so the gcj baseline will also hold you to a sane subset of proven Java features.

  • success largely depends on expertise (Score:3, Informative)

    by bwy ( 726112 ) on Tuesday January 25, 2005 @04:41PM (#11473414)
    Write once, run anywhere becomes closer to the truth if the developer has experience with multiple platforms and knows what he is doing.

    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.
    • Normally it might not be fair to blame it on the JVM but when the JVM marketing people promise you "Write once, run anywhere" you can blame them if they can't deliver even if the feature is technically impossible to implement in the JVM.

  • Best java gui tk for linux (Score:3, Insightful)

    by sprekken ( 623464 ) on Tuesday January 25, 2005 @04:41PM (#11473420)
    http://java-gnome.sourceforge.net/cgi-bin/bin/view [sourceforge.net]

    Java-Gnome binds gtk with java. Very nice.

  • Java -- the abusive relationship (Score:5, Funny)

    by Eberlin ( 570874 ) on Tuesday January 25, 2005 @04:42PM (#11473427) Homepage
    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.

    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 .NET, but too afraid to jump head-on into a relationship with cpp.

    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.
  • ...if this book was about any other language ever invented it would be 50 pages and 10 times quicker to read with 90% less calories burnt?

  • Java and Linux (Score:4, Interesting)

    by MarkWatson ( 189759 ) on Tuesday January 25, 2005 @05:04PM (#11473702) Homepage
    Actually, this book sounds like a good idea - cover deployment issues like database installation and configuration with Java, tips for deployment, etc.

    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 :-) would make Java a more suitable language for small applications and utilities. This would get around Sun's lame Linux/Java licensing issues also.

  • Credit where credit is due. (Score:3, Insightful)

    by IvanHo ( 767188 ) on Tuesday January 25, 2005 @05:05PM (#11473708)
    I'm not a Java zealot by any means, but Java deserves credit for what it does well and one of those things is reducing the importance of platform.

    I've recently worked on a J2EE project with nearly 1 million lines of code -- they're all needed, really ;) -- that runs on XP, Redhat, Mac/OS, Solaris >= 8, HP/UX and AIX 5L.

    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.
    • Parent post is probably as balanced as you will get on /., I think he sums it up: Java is 98% problem-free cross-platform, if you poke long and deep enough you might find some problems, but these problems are most usually minor and mostly due to slightly different underlying platform issues like threading models that give different scaling behaviour (cross-platform doesn't mean you can entirely escape the platform you are running).
  • I use Xemacs, JDE, and make on Linux to create commercial products in java/jsp.

    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 ma

    • 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.

    • > 1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.

      -ea? Its not a javac option. And you can add any compiler argument like with the tag. Maybe you mean the -ea enable assertions feature of the java program. yes, that didnt come out till after java1.4, but you could still do it by hand.

      2. If you dont know what you are doing, yes, ant can be an ugly mess. So can make.

      3. Echo the compile command line. Every try "ant -verbose"? I'm not sure it does, but remember that a

    • For people under the age of 40 Make is incomprehensible, unintuitive and full of quirks that make so sense. Or maybe that's just me.

      If you want 30 or so small, easy to read/understand Ant build.xml files, all controlled by a single daddy build.xml file, go right ahead - the tool supports it just fine. And it'll still be fast.

      If you want them really really easy to read, I'm very concerned. You shouldn't need to be messing about with them - write them, get them working, leave them alone. Constant fiddling i

    • 1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.

      You could've used exec and ran javac, which allows you to specify any worldly command line argument you wish.

      2. We had this crazy huge build.xml file that was created for our project.

      Ant allows you to import other buildfiles in a namespace-aware fashion. This allows you to create multiple build files, and access them from a top-level build file that imports the smaller buildfiles.

      On top of it being huge, its i

    • For every horrible build.xml file, I can find you an incomprehensible Makefile. Or even worse, an automake file... It's not the tools, it's the people writing the files.
  • I find that I use the same tools on windows and linux for java development. Ant and Eclipse, they work about the same.

  • Java on Linux Topics That Really Need Covering (Score:5, Insightful)

    by rimu guy ( 665008 ) * on Tuesday January 25, 2005 @05:35PM (#11474069) Homepage

    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]

Slashdot Top Deals

The truth of a proposition has nothing to do with its credibility. And vice versa.

Close