# Would it be possible to use Kotlin primitive boxing "mechanism" on another project/library?

**URL:** <https://discuss.kotlinlang.org/t/would-it-be-possible-to-use-kotlin-primitive-boxing-mechanism-on-another-project-library/9434>\
**Category:** Language Design\
**Created:** [September 13, 2018, 11:22pm UTC](https://discuss.kotlinlang.org/t/would-it-be-possible-to-use-kotlin-primitive-boxing-mechanism-on-another-project-library/9434 "2018-09-13T23:22:01Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![SackCastellon](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/sackcastellon/32/4553_2.png) [@SackCastellon](https://discuss.kotlinlang.org/u/SackCastellon)\
**Post date:** [September 13, 2018, 11:22pm UTC](https://discuss.kotlinlang.org/t/would-it-be-possible-to-use-kotlin-primitive-boxing-mechanism-on-another-project-library/9434/1 "2018-09-13T23:22:01Z")

</div>

Given the following piece of Kotlin code:

```auto
val integer: Int = 42
val nullableInteger: Int? = null

```

When it is compiled the property types get _mapped_ from the _Kotlin type_ to the correct JVM type:

```java
int integer = 42;
Integer nullableInteger = null;

```

Well, my question is whether it is possible (now or in the future) to use this _mechanism_ with different types or not.

For example, let’s use it with the JavaFX’s properties.

Currently, to differentiate between an integer property that is nullable from another that isn’t, we have to write it like this:

```auto
    val property = SimpleIntegerProperty()
    val nullableProperty = SimpleObjectProperty<Int>()

    println(property.get()) // Initial value `0`
    println(nullableProperty.get()) // Initial value `null`

    property.set(42)
    nullableProperty.set(42)

    property.set(null) // Compilation error
    nullableProperty.set(null) // Compiles ok

```

But using the aforementioned _mechanism_ we could simply _map_ the JVM types to more specific _Kotlin types_:

- `SimpleIntegerProperty` \<=\> `SimpleProperty<Int>`

- `SimpleObjectProperty<Integer>` \<=\> `SimpleProperty<Int?>`

That way the previous code would now look like:

```auto
val property = SimpleProperty<Int>()
val nullableProperty = SimpleProperty<Int?>()

```

* * *

This would also help with the nullability problems of `SimpleObjectProperty<T>` itself, because currently `SimpleObjectProperty<String>` is virtually the same as `SimpleObjectProperty<String?>` in the way that you can pass a `null` to any of them. This problem is similar to the problem with the nullability of the **Java collections framework** , that Kotlin solves by creating its own `List<T>`, `Set<T>`, etc interfaces.