Operator overloading for collections?

[Rob Ross]

It is my understanding that Gosling rejected operator overloading in Java
because it had been misused in C++. It was often used improperly as a way
to implement general purpose macros instead of consistent algebraic
operations and thus made it difficult to reason about what an overloaded
operator actually did in any context. But it's a very concise and
convenient notation and its use in Python is one of the reasons why that
language is so popular in data science. It allows code to flow more like
mathematical operations. For example:

minusOneList: list[int] = [-1] * N   # creates a list of N elements all
initialized to -1

Java will initialize an array with all elements set to 0, but for a
different value you'd need to call Arrays.fill().

List, Set, and Map concatenation is also very easy to read and write with
the overloaded + operator. Allowing * for collection operands could support
dot product expressions.

Is this all just syntactic sugar? Maybe. But think about the code you'd
have to write to get the dot product between two collections. It obscures
the actual intent of the code.

Having spent the last couple of years writing Python code, I have found
operator overloading to be a great tool to enhance the utility of custom
classes. Maybe the fact that Java has never had them would make their
adoption and use in the "correct" way easier. New tutorials could stress
the design principles and their intended use cases, just like you did with
the Optional class and annotations. Just because a feature has the
potential for abuse doesn't necessarily override the benefits it could
provide when correctly used.

- Rob



On Thu, Aug 21, 2025 at 4:06 PM david Grajales <david.1993grajales at gmail.com>
wrote:

> Dear Amber team,
>
> I hope this message finds you well.
>
> I recently watched Brian’s talk "Growing the java language" and I
> found the discussion on operator overloading particularly interesting. I
> appreciated how the proposed approach allows operator overloading in a more
> restricted and safer way, by enforcing algebraic laws.
>
> This immediately made me think about potential use cases for
> collections—for example, using operators for union (+), difference (-),
> exclusion, and similar operations. However, since this feature is intended
> to be limited to value classes, and the current collection classes are not
> value-based, it seems they would not benefit from these new operator
> overloading capabilities.
>
> My question is: are there any plans to enhance the collections framework
> with value-class-based variants, so that they could take advantage of this
> feature? Or is this idea (or any other related to the use case) not
> currently under consideration?
>
> I know this is still under discussion, I am just curious about this
> particular use case.
>
> Thank you very much for your work and for your time.
>
> Best regards, and always yours.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250822/3bcaf9f5/attachment.htm>