Lwjgl3: Could MemoryStack implement Closeable?

[hoijui]

MemoryStack currently implements AutoCloseable (since Java 1.7), which just has the void close() method.
This works great in Java, but not in Kotlin, which requires Closeable (since Java 1.5), which extends AutoCloseable, and adds no new method.

So if we could just add java.io.Closeable to the list of interfaces here,
it would save Kotlin developers to write a wrapper for it.

[octylFractal]

What is the exact issue with Kotlin? If you have the Kotlin stdlib for JDK 8, AutoCloseable.use exists, and given that LWJGL'S Readme states "LWJGL 3 requires Java 8 or later to build and run", I don't see the issue with requiring Kotlin users to include stdlib-jdk8.

[hoijui]

thank you!
I read up on kotlin-stdlib* here because of what you wrote.
Indeed, I was using kotlin-stdlib which really is for Java 6, and AutoCloseable was only added in Java7 (and thus in kotlin-stdlib-jkd7).
Now techincally, it would still make life easier for devs, if MemoryStack implemented Closeable instead of just AutoCloseable, as use would then work out of the box with kotlin-stdlib aswell. "Philosophically", it would be better if they switched to a later stdlib, if they can. The problem is, that they first have to find out, that they have to do that, and there is no way for "us" to give them a nice error message suggesting that.
To me, using Closeable makes more sense, as it has no technical downside, and makes life easier for some, meaning O(1) work leads to O(n) benefit.
But I can understand if you prefer to stick to the purist idea. there is no harm in it for me anymore, just some trouble for others.

[XenoAmess]

@hoijui I apologize if this question would offend you, but why you still use java 6 in year 2020?
or, what is the reason to stop you from moving to java 8, which is still maintained?

[hoijui]

I do not use Java 6 (in this project), but somehow the kotlin-stdlib (for Java 6) ended up in my _pom.xml_, and it never was a problem until now.
So supporting Closeable means supporting Java 6, and people who do not know that kotlin-stdlib == kotlin-stdlib-jdk6. The first scenario is totally valid in my eyes, the second one is debatable, but even that is worth considering, as there is no way to give a meaningful error message. and as said... nothing to loose.

[octylFractal]

Personally, I am against polluting the API with an unrelated interface (MemoryStack has nothing to do with IO, which the Closeable interface indicates). The documentation for e.g. Using Gradle or Using Maven explicitly mentions that you need the jdk8 variant to support things from JDK 8, so I don't think this should be unclear if people just read the documentation :)

[hoijui]

mmmm true.
It is a question of theory vs practice.
In theory, people read the documentation and then all is good.
In practice, people do not read the documentation, and they can not be blamed for that.
It is like the fine-print on a contract.
But as said. it is your decision from here on.

[Spasi]

Closeable changes the semantics of AutoCloseable by declaring close as throwing IOException. This is undesirable.

I recognize that the kotlin-stdlib situation is obscure when you're getting started with Kotlin, but I'm sure most users figure it out quickly. As soon as you try to interact with typical JDK APIs you'll know something's missing. Kotlin should communicate this more clearly to users, it's not something that LWJGL needs to worry or do something about.