Slashdot Mirror
Java Meets XP: Two Reviews
The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.
The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.
Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.
While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.
Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.
In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.
Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.
The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.
The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.
Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.
I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.
If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.
Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.
Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.
Check out my double nested for loop ollie nose-grind, dude!!
If bad puns were like deli meat, this would be the wurst
Now you can run java on XP.
Too bad you can't run VB on solaris...
Linux is dead.
LU
...there was an instant spark between us... Despite the fact that I'm an OS committed to my hardware, I could definitely see something happening... Sure, she was openly platform-promiscuous, but I knew she always used VM protection... besides, both of us were protective of our own (code) secrets... and I must say that the mystery attracted me. So, I thought, why not?
...if only I had foreseen Bill and Scott walking in on us that one day... lord knows why they were hanging out together, but suspicion can make people do crazy things...
It's more like 2 quater reviews than "two reviews in one". Not even a table of contents? Jesus! Especially since the books have exactly zero to do with each other.
IMHO, Anyone who needs book to figure out Ant should be shot.
I am not a number! I am a man! And don't you
When reading about XP, I see a lot of mentions of Ant, XUnit, and cactus, but not much mention of Cruise Control. It builds upon Ant to allow continuous integration, one of the important piece of XP that should and can be automated.
It's important not to lose sight of this in all the troll^H^H^H^H^H enlightened debate about XP that will surely accompany this review. We used Ant for a number of large Java development projects and we were not an XP shop by any stretch. As the reviewer says, Ant really shines when you start making use of various extensions. In our case, we were able to wrap most of the software release process (synching from Perforce, rebuilding and packaging the code, and uploading the distribution to an ftp site) within a collection of Ant tasks.
So I noticed the links at the bottom have a sourceid parameter in them which as I recall, is bn.com's affiliate system. Am I wrong or is this just a blatant cash grab?
Maybe the slashdot editors could pick up the clue stick on this one?
I am not a number! I am a man! And don't you
Some more information about Java Tools For Extreme Programming can be found on this earlier review of
[alk]
Is it just me, or does anyone else get irritated hearing the new idiot buzzwords that come out every week? (Such as eXtreme Programmming?)
Some of us are hard working, college educated computing professionals, not dim-witted adolescents with the urge to jump off of a cliff without a parachute. We need to take our field or work back from every idiot that can put the three brain cells together required to write a stupid book, or to introduce a brand new moronic buzzword.
(Ok, I'll get off my soapbox, you can now mod me to -1000 loser-troll-flame-bait)
Java and XP are a natural combination anyway, since a lot of the emphasis of XP is to fixing crappy code. Since lots of Java code is written by your standard junior-to-mid-level Java programmer (usually an ex-VB or ex-ASP flunkie), it usually needs a lot of re-writing (oops, "refactoring"!).
That being said, I don't see how a build tool is related to a programming methodology. Is it because it has a fairly standard JUnit task? You could easily get make to do that.
Besides, reading a book now about Ant is foolish, because (hope, hope) Ant 2 will be available soon, which hopefully fixes Ant's more egregious kludges and bugs.
imp0rn Xtreme.J4va.COAD;
Clazz JazzyJava {
pubic voyd maine(Strig wordup) {
while(jav4_is_still_Xtream)
System.printl("you betta believe it sukka")
}
}
Stupid job ads, weird spam, occasional insight at
In 1994, the buzzword was "multimedia."
In 1998, the buzzwords all involved the Internet.
In 1999, the buzz was all about UNIX and Linux.
In 2000, Apple announced Mac OS X, which was a pun on the point that the new OS would run a form of BSD UNIX and that this was version 10, as in the Roman numeral. (There may have been an OS named "OS 10" elsewhere that could've led to trademark suits, too.) The new interface was named "Aqua."
Microsoft, working on its "Whistler" OS successor, later announced that it would slap on a Fisher-Pricey interface on its Whistler OS and name the interface "Luna." Later, they would announce that the new OS would be named Windows XP.
The industry names their products with respectively confusing names thereafter.
I think we can blame Microsoft on helping to muddy the waters once again on this one to confuse things mostly with OS X and other UNIXes.
Vos teneo officium eram periculosus ut vos recipero is.
The Extreme Programming movement came largely from the Smalltalk community, right about the time that community faced up to the face that VB and Java had pretty much cornered their former market. Java may have syntax like C++, but its semantics are surprisingly close to Smalltalk's; the migration started long ago. Most Extreme Programming projects (and books) are Java-based these days. (This crowd's second most common language is probably Ruby.)
Stupid job ads, weird spam, occasional insight at
Extreme Programming consists of a lot of distinct ideas including: small teams, two people per keyboard, unit testing, and refactoring.
The most useful of these ideas to me is refactoring. (probably followed closely by unit testing) Refactoring starts with the humble admission that at the start of most software projects, you really don't know exactly what the final product will look like. This implies that the design of the project will change during development. Refactoring is a set of techniques that allows the design of a program to change without making a mess of the code.
If you are interested in Java and Refactoring, you really owe it to yourself to check out Refactoring by Martin Fowler. He has come up with a very well written book in the format of Design Patterns that does a good job of enumerating and explaining many refactoring techniques.
More than that, there's a belief (justified or otherwise; I've got an open mind and want to get some experience before I take a stand) that xUnit allows the programmers to write the tests before writing the code, and that this "test first development" or "test driven development" leads to well designed code. (Kernighan and Pike suggest something similar in The Practice of Programming, but don't take it that far.) Interesting idea, at the very least.
Stupid job ads, weird spam, occasional insight at
Yes, I agree that's a possibility. I'm not sure how innocuous it is -- I mean, aren't the book reviews supposed to be impartial? Why don't we just let the authors write them?
Granted this is all largely theoretical as the vast majority (all?) of the reviews on slashdot are crap. They frequently are less informed than the average reader reviews on Amazon...
I am not a number! I am a man! And don't you
Actually compiled languages are kinda silly when you could hand craft your code in assembler and not have to waste all those cpu cycles compiling and linking over and over as you develop:)
Apache has a nice page on common myths surrounding Perl web applications here
Performance in a particular language depends on the task and more importantly the skill of the programmer. Also, usually the most import factor is developer time.
Take a second and review this paper on An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program (PDF sorry)
Conclusion
Designing and writing programs in Perl, Python, Rexx, or Tcl takes half as much time as writing in C, C++, or Java and the resulting program is only half as long.
No differences in program reliability between the lanuage groups.
Typical memory consumption is about twice that of C/C++ but Java programs was another factor level higher.
Sorry I mangled the above link. An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program
He didn't say they were new. He just said that XP "consists of a lot of distinct ideas." Where do you read the word "new" in that sentence?
I've used Ant, and concluded that it's only strength is that it comes with a bunch of modules ready-to-use. (Never mind that most of those modules would be five lines in a more modular, flexible system like make.) Further, in several respects, it has several serious regressions compared to other build systems. In light of this, it seems to me that the main reason Ant is popular is that it attempts to cover for the deficiencies of common Java compilers. What a mess!
The first regression is that Ant (by default) doesn't do reliable rebuilds. The most basic function of a build system is to produce correct output, and Ant doesn't do it! Its default algorithm for rebuilding is to compile only those source files that are newer than their corresponding class files. So, for example, if you change an interface, Ant won't recompile all the classes that implement the interface. You won't know that they are broken until you (or someone else) tries a full rebuild.
Ant has a "depend" task that attempts to fix this, by tracking source dependencies. Unfortunately, because most Java compilers don't do their part, Ant has to do this in an utterly kludgy way--by parsing class files! Not only is this slow and has some weird side-effects, it's still not completely reliable: Only the compiler really knows what files depend on what others. (For example, if it in-lines a constant, this may not be evident in the class file.) However, as far as I know, gcc is the only Java compiler that can output correct dependencies (jikes claims to do it, but is broken). Even if your compiler does output dependencies, you can't easily use them with Ant, because it stores its dependencies in a non-standard format.
Another regression is that in Ant, individual source and class files are not first-class objects to the build system. You can't easily depend on, or ask to rebuild, a single class file. It's all or nothing. This too is largely due to compiler deficiencies: There is no way to tell most compilers to compile only the given sources; they insist upon compiling everything they think is out-of-date (again, gcc is an exception). This misfeature takes control out of the build system's hands, with the result that "recompile everything that's out-of-date" is the only feasible approach. Another effect is that parallel and distributed builds cannot be done reliably.
Not to mention,
I don't even know where to start on that one. All Ant shows is that if you give people a half-working workaround for broken tools, they'll flock to it.The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I think this is actually where I disagree. Good code must be (a) correct and (b) maintainable. Good unit tests guarantee the former if, but say nothing about the latter. It is therefore quite possible to write crappy code that passes all of the unit tests.
And herein, IMHO, lies the single biggest weakness in XP. In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design, and left it essentially to chance. If your development team consists purely of top-10% programmers who work well together, then certainly they will "refactor mercilessly" and maintain/develop a tidy design. However, most project teams don't, and in my experience will be "at the mercy of refactoring" instead.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Objection, Your Honour. That's hardly a fair test of languages in general. As you point out yourself, these things are inevitably task-specific, and many interpreted/scripting languages have powerful built-in support for string processing, so of course they come out on top. Would you like to see the results of my empirical comparison of C++, Java, VB and Perl for creating a realistic GUI front-end or a high-performance maths engine, now? :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Look man, you might be educated to be a programmer, but if you are worth anything to your employers then you implement some sort of software design methodology, and that's all XP is: it's a lightweight, high-discipline approach to delivering software to a client.
You can argue whether or not XP works, but if you are ridiculing and avoiding it just because it has the word "extreme" in its title then you are a poor programmer and a fool. Since your entire post consists of mockery you leave no choice but to believe you are both.
I like many of the concepts of XP because it is a more realistic model of how developers actually work. The big problem however is that it does not account for programmer laziness and time constraints. One of the premises of XP is that you should develop objects for your current needs today. If tommorrow or next week, those objects nolonger suit your needs, refactor them until they do. In real life many/most programmers are too lazy or don't have time to refactor a class and then work through the code base to insure that every thing still works. Yes i know there are tools and the unit tests help. But the fact is most programmers will just write new code rather than rework existing stuff, especially if someone else wrote the original.
The other big problem with XP is the working in pairs bit. Most developers smell bad, who wants to be stuck in a cubie with one.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
It's worse than that, actually. Once XP became so overloaded, and for other reasons, a lot of Extreme Programming related stuff has been broaded in to the family of "Agile" methodologies. So the word Agile appears where XP might have appeared.
:-)
Now, of course, Microsoft is using the word Agile regularly in adveritisng.
Ugh. Maybe the XP community should embrace a new name for it. Call it "Fred". Of course, MS could come out with a replacement for MS Bob with that name
Nor did I say he did. However, as you point out yourself, he said that XP consisted of various ideas. My point was that since it didn't invent any of them, and all of them are widely used elsewhere as well, there must be more to XP than that.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
well.. i worked with perl for about three years, and C++ for about two years and java for three or four (some overlap here, but more or less) and i don't agree with you at all.
.java source files when i decide to do a Great Renaming and i want to automate it.
you're right about performance not mattering most of the time. it does matter some of the time, though, and then it's usually memory performance.
and if you had a project with just one or two people coding i don't think it would matter which language you chose to work in.
but in my experience perl is a disaster for projects with more than 10 people. i'm sure there are exceptions or you won't agree, but that's my experience.
the program being "half as long" is not necessarily a good thing. it depends what information you cut out. if it's half as long because you used powerful langauge features to reduce the number of program instructions then that's probably a good thing.
but if it's half as long because you cut out type declaration then what are you really saving? you type less, but someone reading your program also has less to go on when they figure it out.
this is why in large projects perl is just not viable: it's not possible to isolate program error effects from one component from spilling all over the application and turning up in unexpected places. you then spend hours and hours debugging your code, or more probably, bothering the person who wrote some section or other to have them explain it to you since it's unreadable. hopefully they still work for the company.
some people answer to this that you can just do ever more testing, and that your unit tests will eventually catch all the errors.
at that point i ask you, isn't a type declaration which is checked by your compiler exactly that? a little test? a little check?
so it seems that with perl you throw out the compiler checking and then have to write all the same checks by hand all over again.
i like langauges like perl because of the powerful features that can reduce 100 lines of code to 10. but please don't take away from me the 10-20 lines that were declarative, that told me what was what and how it fit together. that information is for *me*, it's not really for the compiler. cutting out the type definitions is a bad thing.
java also has a fairly powerful library available, comparable to perls most of the time, and depending on the application either better or worse than perl's. but it also is a strongly typed langauge, and in my view, that makes it viable for projects with many people.
C++ is a different story. sometimes i think you do need to code in a low level langauge to get the performance you want--the linux OS will never be written in perl. but for general applications i wouldn't choose it, however, it's a good systems langauge programming envirnoment.
i still write perl programs--when i have a little one-off just for me, or to fix up a trashed file, or parse some data out of some stream, or something, i turn to perl for these quick little one-offs.
in fact i found a great use of perl is that it's the perfect langauge for running through all my
the languages are not in competition really, just different purposed. java is for large scale application development. perl is for quick and dirty one-off applications. C++ is for systems programming.
a good developer, in my view, should be comfortable with all three (or an equivalent set of three).
There is some benefit to the naming and the book writing that surrounds it: more programmers get exposed to the ideas. But don't expect a magic bullet: people have had a lot more experience with those techniques than their recent new clothes suggest. For some problems and environment, they work well, for others they don't. Talk to experienced programmers from the 1980's for more advice :-)
In Objective-C, you can call those methods.
???
How is that significantly different from java? Cant you just cast the Object to whatever you like, and if it doesnt match up with the new cast, it gets an exception thrown??
not running VB on solaris might as well be a security feature opf Solaris as it protects it from run away programs and HORRIBLY coded apps...
Actually, a VB compatible interpreter runs on the Solaris operating environment. What protects the system from runaway VB apps is not a lack of VB but the presence of working permissions on the system.
Will I retire or break 10K?
(or the processor understands javacode, which is highly unlikely, Probability --> 0)
Talk to Transmeta. Transmeta's Crusoe processor runs programs through dynamic recompilation of bytecode. Current products emulate Intel x86 bytecode, but the Code Morphing recompiler is a piece of software and can be easily replaced with one that understands Java bytecode or .NET MSIL bytecode.
Will I retire or break 10K?
For anything more than short bits of code it's almost impossible to prove anything useful, and certainly impossible to communicate your proof in a way useful to someone who has to maintain your code.
As Knuth himself said, "Be careful about using the following code -- I've only proven that it works, I haven't tested it."
-Billy
Sorry, but I disagree. XP is pretty much how a lot of Lisp, Smalltalk, and similar communities have worked for a long time, using pretty much the whole of what is now called XP, not just bits and pieces. That's not surprising: those communities face rapidly changing requirements, they often have easy access to their end users, and they are usually highly qualified and trained. And that's the community Kent Beck came from; he is just trying to popularize those practices and ideas among non-Smalltalk users.
I have my doubts that that is such a good idea. Languages like C++ and Java were designed for non-XP development processes. Neither the languages nor the tools are up to the needs of XP. Trying to use them for XP is like trying to use a wrench as a hammer. But, then, industry has been trying to use wrenches as hammers for as long as we have had programming as a profession.
Sometimes code REQURES a rewrite, or it's quicker to do so. In these cases, a rewrite is CERTAINLY meritted, rather than bashing your head against a wall trying to get code to do something it was never intended to do.