Is there C# unsafe code like in kotlin?

Language Design
1

C# has an unsafe keyword which allow for more dangerous and low-level access to data. Is there something similar in kotlin? I couldn’t find anything related so far.

1 Like
2

The JVM is designed as a safe, managed platform; I think the only way to do potentially unsafe things in it is to break out of Java into native code using Java Native Interface (JNI). (This is of course highly platform-specific and potentially dangerous.)

So the same applies to Kotlin/JVM.

(I don’t know whether Kotlin/JS or Kotlin/Native provide any other relevant features. But of course they won’t be available in Kotlin Multiplatform.)

What unsafe things do you want to do?

1 Like
3

Hey, thanks for the answer, I thought that might be the case. Actually I’m just trying to compare the two languages as I’m thinking to host a presentation of kotlin for c# devs.

4

AFAIK Kotlin itself doesn’t have any “unsafe” operations, but the JVM does. There was another thread here where somebody mentioned the Unsafe Java class, which allows for low-level memory manipulation. They said it was “less safe than C” (or C++?) if you can believe that. :stuck_out_tongue:

4 Likes
5

AFAIK Kotlin itself doesn’t have any “unsafe” operations, but the JVM does. There was another thread here where somebody mentioned the Unsafe Java class, which allows for low-level memory manipulation.

Yep, that’s it, I suppose.

They said it was “less safe than C” (or C++?) if you can believe that. :stuck_out_tongue:

I’ll use protection gloves and goggles when accessing that class. :upside_down_face:

3 Likes
6

Heads up: Unsafe will be going away (mostly), there are better alternatives:

  • VarHandles for field access / CAS / etc.
  • FFM API for native memory

Only allocateInstance will remain.

See e.g. this article for an overview and JEP 471 etc. for details.

3 Likes
7

Hahaha, that was me! I still stand by that notion. Who would imagine people would remember that statement?

Yes, C is weakly typed, while the JVM Unsafe class isn’t typed at all, and almost any possible usage of it relies on behavior not defined in the JVM specs (because those are only concerned with Java’s own safe memory model), basically private details of the specific JVM implementation itself that might change over time, such as class layout.

1 Like
8

It stuck in my memory for two reasons; firstly, because I didn’t even know Java had Unsafe memory stuff, and secondly, because the concept of Java doing anything worse than C (except for performance) was just a totally wild concept to me.

2 Likes
9

The fully-qualified name of the Unsafe class is sun.misc.Unsafe; AIUI, this means it’s specific to Sun/Oracle-based JVMs, and probably isn’t available on other JVM implementations.

So non-Sun/Oracle code shouldn’t be using it in the first place, should it?

1 Like
10

Yeah, sun.misc.Unsafe has never truly been standard, although it’s been very commonly present and a ton of popular libraries have built around it.

From JDK 22 onward, the java.lang.foreign API should provide a better replacement where explicit control over memory access is needed.