I'd have to say that when people say "monostate", most of the time they
are implying object semantics such that the state is shared.  Static
methods would syntactically fit in Java, but that's really a language
design blunder.  That is, if you used the class as:

   Person p = new Person();
   p.setName("Bob");

then it might reasonably called monostate, but it would also raise a
compiler warning with my current Eclipse compiler settings, because it's
abusing the language.

At this point, I am feeling the uncontrollable urge to point out that
one should not mistake the assignment of the word "monostate" with any
kind of endorsement of one design over another.  Design patterns are (or
could be) useful in that they provide practice in evaluating well-
understood design decisions and understanding the effects of those
decisions on the resulting code.  When one is discriminating about which
patterns are used, they can also collect wisdom from previous software
designers.  They are, however, not at all useful for choosing designs
that have the largest possible number of design pattern names that may
be applied to their parts, especially if one is insufficiently picky
about patterns to use.  Whether or not something is or is not a
monostate is merely a terminology dispute, and in no way relates to
whether something is a good idea or not.

In reading about a pattern, one should always ask: had anyone heard of
this technique before design patterns became a buzzword, or has it been
commonly used for some reason other than its author's promotion of it as
a design pattern?  In other words, is it really the kind of elegant
solution that has tended to be invented again and again to solve a  
variety of problems, as it was once claimed patterns were, or is it
instead just a clever trick that is the sole work of some author or
small group of authors.  If the latter, then this is an "invented design
pattern".  It is questionable to be whether invented design patterns
ought to be called patterns at all.  They are, in any case, antithetical
to reasonable applications of patterns.  Reasonable use of patterns
attempts to organize and learn from the wisdom of collective experience.  
People had heard of factories long before design patterns, for example;
they are worth paying attention to.  By constrast, invented design
patterns like monostate are more often a tribute to the cleverness of
some blogger than they are a collection of wisdom from a long history of
designs.  They may or may not be a good idea, but I certainly don't want
my software design to be dominated by the influence of clever bloggers.