Does anyone have experience regarding this type of request?
I've seen a lot of Java codebases over the past decade, ranging from good to awful. To get a feel for the overall quality, I've learned to check out some common things that are usually indicative of overall quality. For example, bad developers never seem to understand exception handling. Database connection management is another easy spot to check out -- letting the pool close up one's connections seems to be a favorite pastime. Other stuff that's not necessarily Java specific -- use of custom frameworks that, according to the developers' own descriptions, are replicas of existing stuff.
Perhaps, as @hga pointed out here, sitting at a terminal with an experienced developer and insisting that he/she show you the stuff you want to see (as opposed to a passive, guided tour) would be a quick way to gauge overall quality. And, you'd get a pretty good idea of management's notion of "experienced developer."
I haven't done exactly this (hey, I made some of my best (but most painful money) working on wretched code bases), but I've done this sort of thing when helping my company decide whether to partner with another.
If you've got enough experience looking at code bases, you could ask them to let you at a terminal with one of their experienced engineers at your side. 15 minutes of that could convince me the code base was worth dealing with (obviously, it can take considerably less time if not :-).
For full time positions, it's reasonable to inquire about the engineering practices of the shop, code guidelines and similar, what freedoms you have to make spot decisions, etc. But asking for actual code is just silly. It does nothing but paint you as a picky cry-baby who couldn't work with others, or cajole them into working with him (IOW, you lack both a cooperative spirit, and leadership.)
I definitely agree that asking for a code sample could make the candidate appear uncooperative, obnoxious, etc., particularly because it's unexpected. What if instead of asking for a code sample, the candidate more casually asked if one of the engineers could show him around the code base for 5-10 minutes? Would that make it more acceptable?
I don't like the "show him around" idea since it's subject to cherry picking, but it could be an acceptable alternative if they're obsessed with secrecy (which 95+% of the time is bogus and a bad sign you should take into account).
You can mitigate the issues brought up by making looking at the code base just one of all the things you ask about, like process. Hmmm, didn't Joel S. or someone else write up a short essay on the 5 or so things you really want to check before accepting a job? They ranged from using SCM to doing after project analysis.
I might add that one of the things I always ask is what are the finances like. If they're at death's door I might work for them (have before :-), but I want to know ahead of time.
Good point on asking about finances.
[1] I thought most of it was "obvious", but #5, "Do you fix bugs before writing new code?" wasn't something I'd explicitly realized the critical importance of. Heh, notice the beginning of it starts with an after action project analysis.
Hmmm, I just reviewed the list, some time after I read the comments to Mini-Microsoft's posting on why Vista development failed so badly, and I can see where Microsoft stopped doing too many of things that Joel said they were all doing back in 2000.
This is not the place to get into a long essay on that, but by my count:
5. Do you fix bugs before writing new code? (Similar sort of failure, e.g. a lot of bugs were officially closed when they weren't really fixed.)
7. Do you have a spec? (Joel wrote an essay on how it took N people one year to mis-design the Vista logout? feature.)
9. Do you use the best tools money can buy? (Developers had to spend at least one day a week keeping their Vista machines up to date. And the development process (which is a tool of sorts, think of turning a crank on the side of a box to push through something) was so bad, so convoluted, so difficult to push things through, that developers spent a whole lot less time on coding et. al. than they should have.)
10. Do you have testers? (RIFFed in favor of "automation" that seldom happened. They also abandoned the Raymond Chen backwards compatibility "cult" and that whole function and its people.)
One bottom line is that I'm still amazed at how under resourced such a vital project was (Vista, the restart from the Windows Server code base after the .NET Longhorn attempt was canceled).