... I think it would be a bit strange to have a "sentence" object and all we can do with it is ask if it is a pangram ...

I think totally get that point. We're invoking two concepts instead of just one. And I think you're saying that it feels rather surprising to spend time talking about "pangrams" and then suddenly turn around and start with "okay, so you've got a sentence..." Is this part of where you're coming from?

A switch flipped in my head when I read your commit comment, "make object-oriented." It reminded me that the roots of Java are in the OO model of thinking.

I'm a rather concrete learner, so I have the sketch it for myself...

public class Sentence {
   public Sentence(String input) { ... }
   public boolean isPangram() { ... }
}

and

public class PangramChecker {
   public boolean isPangram(String input) { ... }
}

We can take (at least) two views with the API design: it's a Function Object or it's a Value Object that happens to have one function.

If I see a Function Object, it feels like a ... function: stateless and composed. This style has become much more idiomatic these days with the literal @FunctionalInterface annotation as well as this kind of structure being a natural outcome of SRP. Also, such shapes fit easily into DI/IoC frameworks like Spring.

When I see an Object, it feels like a wrapper that adapts the contents to something else. A wrapper says, "from these ingredients we have a new thing which has these new property/ies." This style hit the "Object-Oriented" button pretty squarely: it's intended to convey a model in the programmers' minds of "things that have state+behavior".

I suspect there's not enough design pressure from the exercise itself to tip us one way or another. I might have inadvertently drifted into the "stylistic" realm...

What would be most useful to someone at this point on the track?