Failure is the most instructive teacher of all. You have to give him enough responsibility so that he can fail and then learn from those mistakes, but not so much that he'll take everyone else down with him.
There is no substitute for failure.
Assuming that he has the type of mentality that's ready to learn... I'd say the best you can do is plant him in certain scenarios where he needs to see the reality of the situation. Places where Java can't be the answer, or where he needs to encounter real engineering (choosing among solutions of varying quality/cost). Give him the opportunity to make mistakes.
Also consider the remote chance that he may actually be a God of Java. Does what he says have any merit?
Given a large enough stick, you can "teach" anything to anyone, biological impossibilities aside.
Inexperienced people will not listen until they have a few failures under their belts. It usually takes something smacking them on the head for humility to have a chance to take root. This is the #1 reason that I usually like working with older programmer better.
I think most of your problem with this guy is that he was young and immature. Also, he may have been "fluffing himself up" so he didn't feel so much like a wet-behind-the-ears newbie among a bunch of seasoned programmers.
What he needed was a good, long, thoughful talk with the boss to explain to him how things work in real-life business as opposed to what they teach in school. It would have benefited both him and the company in the long run.
A good pair programming session with a senior programmer taking on a really hard part of the code might help to bring him back to reality. Learning how much you don't know is really the beginning of wisdom. Hopefully, the "boss" understands that team chemistry is at least as important as the raw programming ability of the team members. Lack of humility -- whether experienced or not -- is really detrimental to a good team and a good boss will help the person grow in their ability to mesh with the team as well as in programming skill.
Failure is the best teacher, but if he sees you as someone who is causing him to fail he will likely see you as an enemy and making an enemy of a type like him is never wise. He will fail on his own with this attitude, that's for sure.
Don't we all start that way? (well, not me of course, but...) Mark Twain even had a quote about it (the general idea, not java) which went something like "When I was 16 my old man was so ignorant I could barely stand to have him around, but when I got to be 21 I was amazed at what he had learned in 5 years".
Best thing for taking conceit down a few pegs is reality - If you can show him a fix for something he thinks is great, he may actually get the idea that he doesn't know everything. Best if you can find something obvious. Unfortunately there are some things that don't really make sense without some experience - rewriting code always looks like a good solution if you're not used to reading others code (Here's a good Joel article), and don't have a sense of the hassle that can cause in a business sense. Patterns are another thing that doesn't really make much sense until you've done it the wrong way.
-Ask him to architect the rewrite and then tear it apart?
-show him some examples of his code on the dailyWTF?
Ultimately he's either a good programmer who's just inexperienced (in which case he'll figure it out eventually) or he's terrible and he'll spend the next 10 years thinking he's hot s**t, in which case there's probably nothing you can do). If he really thinks java is the end-all language, he's (to put it charitably) got a long way to go (and I say this as a mostly-java programmer). Write a major module in lisp and ask him to "just do a little fix" on it.
On a more positive note, there are some projects that I've worked on that seemed easy at the time but eventually taught me the inadequacy of the naive and obvious approach, and that have widely used and tested methodologies. Two that come to mind are parsers and web frameworks. If you think you're great but aren't really and are asked to write a parser, you'll probably start with a big mess of string matching. A really elegant parser architecture can be humbling, especially if you've just spent a week trying to figure out how to separate out comments using raw string parsing.
Just about any challenging programming project would be a good teacher of humility. I can't think of any really hard problem which doesn't teach humility. But that doesn't mean that this fellow will learn that humility ("The humbug can swim in the sea of knowledge for hour and not get wet" - Norton Juster ). Also, Don't be absolutely certain that you have grasped what this guy is about - have a bit of humility about your own judgments of others.
Also, it is indeed up to your supervisor to decide if a given system needs rewriting, which is good since that is one thing you don't have to worry about.
How about pointing him to some classics like "The mythical man month" or blog posts by experienced developers who point out how it is always harder than it looks in the real world;)
Try challenging him with a problem that sounds trivial but has brought down the masters: a Binary Search. According to this Wikipedia article:
When Jon Bentley assigned it as a problem in a course for professional programmers, he found that an astounding ninety percent failed to code a binary search correctly after several hours of working on it, and another study shows that accurate code for it is only found in five out of twenty textbooks (Kruse, 1999). Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contains an error that remained undetected for over twenty years.
Block access to the internet (to avoid "cheating" like a real world programmer would do). Give a time limit of, say, 1 hour--it is such a trivial program, after all. Then ensure you have some data that will test boundary conditions, gaps, etc.
After the failure, you may still not have a humble programmer, but you will feel a certain (malicious) satisfaction.
Of course, if he does it correctly under the constraints, you will never live it down...
If people keep on coming for advice from this guy, he's an asset, not a liability. If you think he holds an invalid belief which may affect you in a bad way, then either convince him with facts or make it clear that the burden of proof is on him. Just sitting around thinking you are right and he is wrong is not improving the situation.
When there is a disagreement about the truth of a qualitative statement with far-reaching implications ("it would be good to rewrite our code in java"), then you need to go through a process of quantitative analysis involving modeling/analyzing/observing/measuring/estimating until someone realizes he is wrong or the issue can at least be phrased as a relatively simple executive decision. ("based on model X with parameter estimations Y, expected ROI of rewriting the code is Z.").
Or you could just ignore any hard facts and start an eternal flame war, which is way more fun ^_^. Joel has an article which sums up pretty good why programmers always want to rewrite the entire code base, and why it is probably a bad idea.
I've worked with a small number of programmers who were remarkably resistant to learning from experience, who had the right answer every time, even if the last ten "right answers" didn't work, this time it was right, for sure.
It all boils down to whether or not this person can learn from experience, which depends 100% on the person. Others have given great examples of possible ways to try to teach the young programmer. Try those. Be prepared for either possibility, that this programmer can grow, or not.
This type of programmer needs extra management, sometimes, to ensure that grandiosity does not cause him/her to take undo risks. Hopefully this person is as good as they think, but more often this is not the case. Only experience and an open mind can teach humility. Sort of like the proverb that you can lead a horse to water, but you can't make it drink. This is true here to. Some people are just resistant to humility and need to be let go before they bring down the whole team.
Some of them never learn, unfortunately. When Their Way ceases to be viable, they turn into consultants, it seems.
Anyway, gift him. Give him "Lion's Commentary on Unix 6th Edition". Come up with whatever excuse will work, but get this book in his hands.
IF he reads it, he'll most likely improve in attitude. If he doesn't... well, you tried.
Pride is a powerful force in a programmer, and can be used to motivate him to produce very good work. Give him more responsibility so he feels proud of his work, but at the same time remind him that he is still young and inexperienced. He should feel good about his talent, but also understand that experience and growth are important to his career as well. Enforce code reviews and have him present the good points and bad points of his own code. Give him an explicit goal to teach his less experienced coworkers, and he may learn to treat them with more kindness.
If his attitude causes personality conflicts, it can be helpful to have somebody take him aside and let him know that. He may not know that he is coming across as a pompous ass, and would appreciate advise on how to change! ;-)
(This is coming from someone who is sort of like the person you described. Except maybe only 10% asshole, I hope!)