Re: Proposal: Static Service Traits—Enhancing Java’s Static Polymorphism and ServiceLoader Facilities

[Ethan McCue]

To give what (I think) is more the kind of feedback that would be helpful:

I've been playing around with this library -
github.com/bowbahdoe/java-type-classes. Finer points aside, it seems
comparable to the planned language feature. What I am struggling with is
when I would actually **want** to register witnesses for a typeclass.

Take comparator for instance. If I am making a Point class I can register a
witness for Comparator<Point>.

public record Point(int x, int y) {
    @TypeClass.Witness
    public static Comparator<Point> comparator() {
        return Comparator.comparingInt(Point::x).thenComparingInt(Point::y);
    }
}

And then I can summon that witness later

import com.garciat.typeclasses.TypeClasses;
import com.garciat.typeclasses.api.Ty;

void main() {
    var points = new ArrayList<Point>();
    points.add(new Point((int) (Math.random() * 15), (int) (Math.random() *
15)));
    points.add(new Point((int) (Math.random() * 15), (int) (Math.random() *
15)));
    points.add(new Point((int) (Math.random() * 15), (int) (Math.random() *
15)));

    IO.println(points);

    points.sort(TypeClasses.witness(new Ty<Comparator<Point>>() {}));
    IO.println(points);
}

But, I am already referencing the Point class directly. Syntax aside, I'm
not sure why I would bother interacting with typeclasses at all when I can
just write Point.comparator(); or (for this specific interface) making it
implement Comparable.

Really if I am touching comparators at all I will end up writing things
like Point.comparingX(); and Point.comparingY();

On Fri, Jan 30, 2026 at 7:01 PM Steffen Yount <steffenyount at gmail.com>
wrote:

> no problem.
>
> On Fri, Jan 30, 2026 at 3:22 PM Ron Pressler <ron.pressler at oracle.com>
> wrote:
> >
> > Oh, I apologise!
> >
> > > On 30 Jan 2026, at 22:20, Steffen Yount <steffenyount at gmail.com>
> wrote:
> > >
> > > For what it's worth, the recent "Java Language Enhancement: Disallow
> > > access to static members via object references" thread and suggestions
> > > there weren't mine. My first and otherwise most recent foray into
> > > engaging with you guys on this list was way back in late 2023.
> > >
> > > On Fri, Jan 30, 2026 at 1:05 PM Ron Pressler <ron.pressler at oracle.com>
> wrote:
> > >>
> > >> P.S.
> > >>
> > >> Your previous suggestion about turning some warning into an error
> suffered the same flaw. All it said was that the pattern is potentially
> confusing. But that’s why there’s a warning. That’s not how to motivate
> turning a warning into an error. What is the problem with the warning? Is
> it that your team don’t turn it on? Do you turn it on but ignore it? Why is
> it that particular warning that merits becoming an error? Are the problems
> caused by it particularly serious?
> > >>
> > >> Without clearly stating what the problem you wish to solve is, it’s
> hard to judge the merit of any solution.
> > >>
> > >> If you look at our JEPs, they start with a motivation section. That’s
> the first step: clearly identify a problem and explain why it’s an
> important one for the platform to solve.
> > >>
> > >> It’s very important for us to know what problems people encounter,
> and we appreciate such reports, but if you don’t tell us exactly what the
> problem is we can’t help.
> > >>
> > >> — Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260131/ebc91220/attachment-0001.htm>