I was just studying the interdependence of state and behavior exhibited by the state of an object and its behavior.was wondering if an object can have behavior without having state. Because i am very sure that the other way around is very much possible

  • 3
    Of course it can. Just imagine a factory object, which has a make() method that returns a new object each time. – BobDalgleish Mar 5 at 14:26

Yes. An obvious example would be Comparator implementations.

Imagine you want to be able display a collection of some type as a table of it's properties, and sort by any column.


class Bar implements Comparable<Bar> ...
class Baz implements Comparable<Baz> ...
class Quux implements Comparable<Quux> ...

class Foo {
    public Bar getBar();
    public Baz getBaz();
    public Quux getQuux();

You would create

class CompareFooByBar implements Comparator<Foo> { 
    public int compareTo(Foo o1, Foo o2) { return o1.getBar().compareTo(o2.getBar()); } 

class CompareFooByBaz implements Comparator<Foo> { 
    public int compareTo(Foo o1, Foo o2) { return o1.getBaz().compareTo(o2.getBaz()); } 

class CompareFooByQuux implements Comparator<Foo> { 
    public int compareTo(Foo o1, Foo o2) { return o1.getQuux().compareTo(o2.getQuux()); } 

None of these need any state.

Comparator isn't anything special, as most functional interfaces can plausibly have stateless implementations.

  • This feels a bit cheating in methodology. The code above is basically function, it's only that in Java you have to have it as Object (lambda -> anonymous class -> class), but essentially they are still considered IMO as functions. – andras Mar 6 at 16:18
  • @andras I'm more used to C++, where these would be free functions or lambdas. The usage still objectizes them, because they get passed around as parameters – Caleth Mar 6 at 16:24

The strategy pattern is often be used in a way with objects without fields.  Two or more instances of such a strategy may coexist.  Each may offer some differing behavior, and would be generally be considered stateless.

@BobDalgleish's comment about a factory object is a form of strategy pattern.


Technically, all objects have state in Java. Somewhere in the heap there is some data that represents that object and what class it is an instance of. It's common to use objects that have no additional data (state) like a method pointer. The newer versions that allow for method pointers and lambdas use this approach behind the scenes.

In informal discussions, we would typically call these 'stateless' because the above is so primary to the way Java works that it's not helpful to mention in most contexts.

  • 1
    You are talking JVM implementation details, and then assuming the JIT never devirtualises a particular set of calls and to a jmp (or w/e) in the resulting instruction stream. – Caleth Mar 5 at 15:54
  • @Caleth, the way I see it Jimmy is speaking broadly about the nature of the object system, such as the reference identity that objects have, rather than underlying implementation details. (Sure optimization can do things in cases where you can't observe the difference, but that's always so...) – Erik Eidt Mar 5 at 16:10
  • 2
    But only if your program asks for reference equality does any state have to exist to maintain that – Caleth Mar 5 at 16:19
  • 1
    @Caleth "You are talking JVM implementation details" Not exactly. This is all part of the language spec. All objects have, for example, a class. If we've got a List<Object> filled with instantiated objects, you can always iterate over the objects and call getClass. Every object must maintain the state of what class it belongs to. And that state (i.e. class) is inherently used in instance method calls and in casting evaluation. In escape analysis scenarios, it's possible eliminate the object entirely but that would be JVM implementation details. – JimmyJames Mar 5 at 17:40
  • 1
    @Caleth Another example is that "Each object in Java is associated with a monitor" . We can quibble over whether the monitor is part of the object or not but clearly there is state associated with object, from a language perspective. This is another case where I think the JVM often removes this overhead for objects that never escape the thread: the implementation can vary but language semantics must be followed. – JimmyJames Mar 5 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.