Let's say I have these 2 Java methods: `public Str...

# announcements

[Dico]

Let's say I have these 2 Java methods:
public String get(Integer key) {...}
public String get(int key) {...}
How can I call one of these without running into overload resolution ambiguity?

[Dominaezzz]

I think, with a nullablilty hack you can call the first one. Not sure how to call the second one.

[Dico]

ah that does work, I want to call the second one though 😅

[karelpeeters]

So get(5) picks the first one as well?

[Dico]

that's illegal

[karelpeeters]

Right 🤦‍♂️. What does
val f: (Int) -> String = ::get do? Also illegal?

[Dico]

The concrete use case is that I want to call remove(key, value) on a Int2ObjectOpenHashMap from fastutil

[Dominaezzz]

Ha! Beat me to it.

[Dico]

Also illegal

[Dico]

I can do get(5 ?: null) or get(5 as Int?)

[Dico]

but that doesn't call the one I want to call

[karelpeeters]

There's reflection and creating a Java wrapper but you know about those simple smile

[Dico]

I can create a Java utility function I guess..

[karelpeeters]

Exact same problem here (it's even fastutil): https://stackoverflow.com/q/37625599/5517612
It looks like there was a solution back then, maybe it's a regression?

[Dico]

Hmm, something weird seems to be happening here

[Dico]

```

[Dico]

public static <V> boolean remove(Int2ObjectMap<V> map, int k, V v) {
        return map.remove(k, v);
    }

    public static <V> boolean remove(Int2ObjectMap<V> map, Integer k, V v) {
        return map.remove(k, v);
    }

[Dico]

I made these and I can call the primitive one from Kotlin

[Dico]

but not the member method

[Dominaezzz]

Same project maybe. 🤷🏼

[Dico]

I think it may be because of inheritance

[Dico]

the problem doesn't exist with put, which has the same overload ambiguity

[Dico]

making very little sense

[Dico]

thanks for the help to you both

[karelpeeters]

I think there's a document somewhere specifying the exact resolution order/steps, but I can't seem to find it. I'll search when I'm on a pc.

[karelpeeters]

Do let us know if you find a solution, now I'm interested!

[Dico]

I have no answer to why there's an error calling remove but not put

[Dico]

I am adding a wrapper function though to make sure it calls the right one

[Dico]

Today I found out that comparing equality of inline classes causes both to be boxed when looking at the bytecode

[karelpeeters]

Haha why would that happen!?

[Dico]

so I lost some trust in the Kotlin compiler's decision making

[Dico]

They fixed this for next version though I think

[karelpeeters]

I feel like inline classes are still very brittle, especially around delegates I faced some issues too.

[Dico]

Yeah they are an experimental feature of course

[Dico]

I think you know the project I'm using them on

[karelpeeters]

Right, I can confirm they deserve that status.

[Dico]

I wonder what it does when comparing unsigned ints now 🤔

[karelpeeters]

What use case do you have for them? I have trouble coming up with anything other than unsigned ints and packed coordinates.

[Dico]

References to memory from another process

[karelpeeters]

That's neat.

[Dico]

I've been working on replacing the inline class system over the last few days 😕

[Dico]

It was definitely great to start with but hasn't scaled too well

[Dico]

it's great though for defining remote memory structures like this

[karelpeeters]

The memory reference system? Or do you have some general inline class stuff?

[Dico]

the prior

[Dico]

can confirm it doesn't box UInt when comparing two

[karelpeeters]

Then maybe a >= b && a <= b is faster.

[karelpeeters]

The JVM might even realize what's going on an optimize that, but I'm not so sure.

[Dico]

p >= nullptr && nullptr <= p

[Dico]

😂

[karelpeeters]

That's even easier to optimize!

[Dico]

There were millions and millions of boxed inline class instances in memory snapshots because of that comparison

[karelpeeters]

Really? I've been led to believe the JVM was good at optimizing short lived instances too, idls there an actual performance impact?

[Dico]

if you go higher than 15 million you will definitely feel it

[Dico]

I can't give you numbers but I can say that the application lagged

[Dico]

I think I read somewhere that the GC will freeze the application if things get out of hand or something

[karelpeeters]

This was the document I was talking about earlier, unfortunately it doesn't really say anything about the primitive mapping: https://github.com/JetBrains/kotlin/blob/master/spec-docs/NameResolution.adoc

[Dico]

Interesting read!