-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional type pollution fix #224
Conversation
Avoiding the cast by returning void will work too |
right that's essentially what I've done here: ignore the return type. Perhaps that would be a good change to the |
Sure. We probably need to deprecate that method and introduce a new one. |
Something like |
I have to also add a 🛑 to this line of reasoning... what we're working around here is a JVM bug which people are working on fixing, whereas an API change is much more long-term. As @Ladicek pointed out this is a commonly used pattern so changing the API isn't really warranted. I'm OK with some simple/localized band-aid type fixes for the type pollution issue to stop the bleeding but I am against significant reengineering or API redesigning to work around it. Once the issue is fixed, I feel we will regret the amount of effort we spent on the problem which could have been spent in other areas, and we will also regret how we hobbled our own programming models for a short-term gain. |
Could this get merged? |
Thanks! |
Similar to #190 , this looks rather trivial but has severe performance implications.
I wonder if we shouldn't delete all uses of
Assert.checkNotNullParam
, it seems rather dangerous.