This is an old question, but I'm answering to disagree with the accepted (and only) answer.
I've been a Java programmer for about fifteen years, and I've been doing it professionally and intensively for about three years. I initially resisted the
mMember convention for all the abstract reasons commonly cited. But the longer I stared at Java code, the more this convention grew on me. I started using it myself a few months ago.
For one thing, it is not entirely redundant. Even with modern syntax highlighting, the convention makes it easier to immediately recognize that an identifier is a member field. Especially at 3 A.M.
And many of the arguments against Hungarian notation are actually arguments against Systems Hungarian notation, in which the warts identify the type of the variable. This is indeed redundant in a strongly-typed language like Java. But there's a good argument to be made for Application Hungarian, in which the warts encode the scope and usage. Googling these two terms will turn up several articles.
Your second point is closest to the truth. I would argue that it is not bad practice at all, for the reasons given above. But I think we can leave that argument aside and say that you should do it solely on the basis of convention. The reasons for this are both practical and social.
The Java community has very strong naming conventions. They become ingrained to the point where code that does not follow them becomes hard to read. If you don't use the
mMember convention, you can bet that some maintenance programmer who comes after you is going to refactor all your identifier names.
And the social aspect is that not abiding by Java naming conventions immediately flags you to your peers as not a real Java programmer. "Watch out for this guy. He probably doesn't even know what a memory model is." (And they're usually right...)