Does Xp Work For Java
Does Xp Work For JavaI understand that ExtremeProgramming was designed by smalltalkers for smalltalk[ers]. Does XP work for Java as well? Any pointers? -- AnatolFomenko?
Anatol - Why wouldn't XP work in Java? -- KentBeck
It all depends what is meant by 'work for':
That's arisen because I'm now coding in Java more myself, refactoring and writing tests (as one WhoIsUsingJunit and ServletTesting using VisualAge). And I confess that I'm just a weenie bit disappointed with the experience.
And yes, back in the eighties and early nineties I used to code, refactor and test using Smalltalk from time to time. When I started on Wiki in January 1999 I immediately got involved in discussions like IsXpIndependentOfObjects and CouldExtremeProgrammingHaveArisenWithoutSmalltalk that may be of relevance to Anatol's original question.
I've no doubt that Java projects are trying to use XP and are benefiting from the effort. Certainly the official story (based on a very fast read of ExtremeProgrammingExplainedEmbraceChange) is that XP is not just for one language but that its success will depend to some extent on how well a project's software tools support an incremental style of coding and testing.
But I too am more interested than ever in what people miss about Smalltalk when they try XP in Java and most of all, in pointers on how best to mitigate. -- RichardDrake
MartinFowler's book on Refactoring is all in Java. Since refactoring is the only language-dependent aspect of XP [that I can think of], clearly it can be done just fine.
I believe that the guys who have done both Smalltalk and Java told me they think refactoring goes 2 to 4 times slower in Java. Weigh in here, experts. That would suggest to me that you have to be more careful to hit needed refactorings early. I'd also think that VA for Java would help a bunch. No experience to speak of on the Java side, however ... just projections. I eagerly await hearing from folks who have done both. -- RonJeffries
Well, who's to say who's an expert, and this is anecdotal, but here goes. I've been programming in Smalltalk for 10 years, and Java for 2.5 years (using GemStone on both sides), and I'm convinced that refactoring is definitely much more painful in Java. I can't really say how much slower it is, because I haven't done any experiments and I hesitate to guess. I will say this, however: IMHO the biggest impediment to refactoring in Java is its implementation of exception handling. If, in the course of refactoring, you decide you need to throw a (checked) exception out of a context from which it was previously unthrown, this can have a tremendous ripple effect throughout the codebase. The alternative is to violate the semantic intent of RuntimeException. The exception-handling syntax also makes it impossible to write short methods in Java without rolling your own HandlerCollection? in which, for want of BlockClosures?, you'd at minimum have to introduce an interface to be implemented by inner classes (or else resort to a HandlerCollection? hierarchy - ugh). Furthermore, SchemaMigration? is more difficult in GemStone/J than in GemStone/S - probably due to class-loading and strong-typing issues peculiar to Java. -- RandyStafford
Ron, in calling for the testimony of experts (just as I was), don't we have a wee problem: there are Smalltalk experts going back 15 years or more and there are Java experts going back just five years - and only if they were on the Green/Oak project team!
And then a Smalltalk person fifteen years ago had more stable basic libraries to get to know (collections, streams, magnitudes) than Java had even a year ago. If you get to chance to quiz JamesGoslingOnCollections he'll freely admit that it's been late to retrofit a decent collection class hierarchy ... and this in turn has led to instabilities in existing libraries to some degree.
With XP there are C3 experts (and Smalltalk/Gemstone/Envy is a remarkably stable, uniform, untyped, incremental, multi-user, persistent object environment unlike anything yet available for Java) and there are more recent experts. And then there's Ward and there's Kent!
Don't get me wrong, as I see it Java projects all around the world are already benefiting from JUnit and other influences from XP the books, C3 the poster child and Wiki the amazing. But can someone converting from Smalltalk after ten years, say, really know the same amount about the optimal culture, conventions and rituals that are best for a team with Java and VisualAge after even two years using it with XP? Are you saying a person's suitability to be XP coach is totally language neutral?
Meantime I've ordered Fowler's Refactoring from Amazon, thanks for the reminder. -- RichardDrake
Of course the tools are different. However, if you want to compare refactoring in the two languages you need to talk to people who use both languages. The reports I've had are from object and refactoring experts who have used both languages extensively. But Smalltalk more extensively? Or are we already at the stage that some teams have enough Java experience to speak with some finality about this?
Take my report as apocryphal nonetheless, until the experts themselves weigh in here.
As for suitability as an XP coach, my guess would be that a coach experienced in eXtreme COBOL would make a better XP C++ coach than someone who had never coached at all. With the exception of refactoring, XP doesn't seem programming language dependent to me, and I've programmed in most of them.
That said, an XP coach might also be standing in the role of object mentor, architectural hintmaker, design guide. These things, while not part of XP coaching, are more likely to be language dependent. For that reason, an XP coach, like any other guide, would proceed with caution when outside his home languages, and would not overstate his powers or beliefs. -- RonJeffries
I came to believe that EvolutionaryDelivery was more important than the programming language and tools I was using over twelve years ago. One vital thing I omitted above is that XP is always very good news for Java projects simply because XP assumes ED. But some places XP improves on past ED thinking, such as refactoring, it does start to become language dependent (although not in PairProgramming which to me is a very fundamental contribution that makes up for the impractical nature of code inspections as taught by TomGilb).
I also see XP achieving critical mass leading to large numbers of case studies (XPeriments?), a lot of them in Java - which will greatly help with the evolutionary methods of the future.
But I'm still left wondering how experience within the XP team combines with the languages and tools used to affect the end result. I believed in LearningByRefactoring? for many years (without calling it that). What bothers me now are these issues with Java's broken object model, manifest typing, exceptions (thanks folks) plus retrofitting something as fundamental as collections to the libraries plus some of the culture and conventions that have grown up with Java. These things can not only inhibit refactoring even for the 'expert' but pile on additional learning burden for those for whom Java is not yet a 'home language'.
However you delineate the roles in the team all of this can't but detract from focus on the customer - at its worst it can contribute to a unhelpful old-style division between the customer-facing concept or product people and the programmers.
I don't doubt by the way that there is already much team management wisdom distilled in XP (much of due to your good self) but I suspect also a certain amount still to learn. What's an architectural hintmaker? I need one of those! -- RichardDrake
"[R]efactoring is the only language-dependent aspect of XP..."
UnitTesting is to some extent, too - StarUnit is a lot easier in a language that has some sort of reflection capability (which both Smalltalk and Java have).
My own experience - and this seems to have been borne out in ExtremeProgrammingWithTypes - is that a manifestly typed language is never as good for ExtremeProgramming as an implicitly typed language (I don't use "static typed" and "dynamically typed" because of languages like SML which have the happy advantage of being statically typed yet seldom require the programmer to explicitly indicate types). The problem is the refactoring pain caused by something changing type. JavaExceptionsAreParticularlyEvil in this regard, as the exceptions have to be refactored in as well (essentially, the exceptions a method can throw are part of that method's type).
-- BillTrost
I suspect this is more of a tools issue. For example, VisualAgeJavaThree has improved support for managing the consequences of changing things. The nice thing about manifest-typing is that the language will tell you how a change needs to propagate across a body of code, the nasty part is that it insists. -- SteveFreeman
Thanks for articulating the manifest-typing point. "Do you really insist?" is indeed something I've been muttering to myself - just like the old forays into C++. How much will I benefit from upgrading to VisualAgeJavaThree, Steve? -- RichardDrake
All I've seen so far of VisualAgeJavaThree is the demo download. It looks a little nicer, especially support for things like rename and replace, although we'd all like more... -- sf
AllenWirfsBrock gave a very interesting talk on Jove, their optimizing Java compiler, at the U of St Thomas OTUG meeting last week. He spoke of the fact that to do many of the optimizations in question, Jove needs to see all the class files so that it can do type inferencing and method reduction.
Unfortunately, to do effective refactoring, the human also needs to be able to see all the class files as well, so as to change all the senders or implementors when changing interface. Tools like Smalltalk and VisualAgeJava make this easier. However, in a language like Java, even if you can see it all, there's more to change. Interface definitions and type definitions can easily double the amount of typing you have to do to change something. The flexibility of languages with dynamic typing, combined with the tools those languages pioneered, probably does give them real advantages for refactoring. -- RonJeffries
I've just found some discussion that has helped me with some of my Java concerns this month at the end of JustGoodFactoring - a page that was last edited over a year ago, before I had ever looked at my first Wiki page.
This kind of thing always makes me feel slightly foolish, still very grateful for Wiki but wanting it to have even more effective linking and searching. More importantly it reminds me of an issue discussed with Ward a while back: WikiSuccessCanInhibitNewWriters. -- RichardDrake
I agree about manifest typing. The broken object model can't help, either. In Java, ints are not proper objects, cannot be stored in Vectors and so forth. Switching from "int" to "Integer" will require a lot of code changes. A related point is that Java has no operator overloading or typedef's; there is no way to make an Integer object look like an int primitive, no way to ShieldPattern such low-level details. -- DaveHarris
Just because refactoring is hard doesn't mean that therefore you're going to get all those decisions right. You HAVE to evolve every decision you make. Thinking ahead carefully might slightly reduce the probability that you will have to evolve a decision. It might not. You still have to refactor or you're sunk. Java makes this more difficult than Smalltalk, but not as difficult as C++. However, the cost of refactoring Java is well within the parameters needed for EvolutionaryDesign to be successful.
It strikes me that how difficult refactoring (or UnitTesting or whatever) is in a language has nothing to do with whether XP works for that language. It simply means that one might have more work to do. It's the thought process that goes into XP that counts surely? -- ChanningWalton
Somewhat. However, XP's attitude toward BigDesignUpFront is based on assumptions about the cost of change being low. To the extent that XP rests on this assumption, languages that get in the way of change affect the extent to which XP is economic. Parts of XP would definitely not apply in a seriously rigid language or development environment. -- RonJeffries
Very true :-). In the case of Java, I believe all that's missing is a RefactoringBrowser - I think there is mounting evidence that Xp does work for Java very well. -- ChanningWalton
Seconded. For all its faults, Java does at least make depedencies easy to detect, so it's then a matter of somebody writing helpful tools. In the C world you have to work harder because of #includes. -- SteveFreeman
Funny you should say that, as a colleague and I were looking into starting a mini XP project with the product being a RefactoringBrowserForJava. Although it's a bit difficult with a full-time job to hold down. -- StuartBarker
Who do you want us to talk to in IBM?
If only! -- SB
I've worked on two "XP" projects using Java. Both were abysmal failures. I don't necessarily blame Java in either case, but rather the kinds of developers available in the Java space. It has been my experience that Java developers are much closer to C programmers (read: procedural, at best, modular) in their mindset and day-to-day development "attack" than Smalltalk programmers.
I think that because of various JLS warts (see SmalltalkMinusMinus) it is easy to see that these Java programmers will have a very hard time indeed developing the proper ObjectOriented mindset required, in part, to make XP work.
In addition, I've seen that many of the organizations trying to use XP are simply not ready or willing to make the necessary internal adjustments to give XP its fair chance. Many of these organizations are trying to move from COBOL or some other old, waterfall bound, programming model and it's eXtremely painful for them. There is a lot of LetsPlayTeam, GuruDoesAll, and ScheduleChicken to fight in these organizations. This, obviously, is not the hallmark of an XP project. One tries to migrate these organizations into an XP "mode of thinking and acting", but it can sometimes be near impossible.
It might just be me, but it seems that if an organization is willing to go out on a "limb" to try Smalltalk, it is much better suited to try XP because its guard is already down and willing to accept more internal change. I think it's fair to say that Smalltalk has never been mainstream like Java. Don't get me wrong; I really love Smalltalk and use it regularly. But, Java is mainstream now - for better or worse. That being said, many organizations will want Java to fit into their "current", mainstream, processes. This, sadly, often doesn't include XP. -- JeffPanici
The EclipseIde has some good Java support - it includes a number of refactorings, not as many as some would like, but those which exist seem powerful and well-written. It also integrates JUnit, making a sidebar with the red/green bar available with a simple button to re-run the last used TestSite?. It's also not as slow as some Java IDEs since it uses a JNI widget set called JavaSwt. (available on Windows, Linux motif/GTK, Solaris motif, QNX, AIX motif and HP-UX motif, with MacOS in beta). I use it as my standard development environment while doing team-of-one XP.
It additionally nicely supports ProgrammingByIntention / TestFirstDevelopment? by providing "QuickFixes?" for compilation errors - for example by generating a stub for a called, non-existing method. Its incremental compiler also allows for a very fast round trip.
[Obligatory mention that IntellijIdea has the most thorough support in this area, though Eclipse is a pretty good free alternative.]
The JavaRanch has made room for discussing XP and Java.
See ExtremeProgrammingWithTypes
EditText of this page
(last edited September 25, 2007)
or FindPage with title or text search