I see yet another function in Kotlin/Native, that does not exist in the Kotlin JVM or JS. What does it?
From Kotlin native's Concurrency docs
Freezing is a runtime operation making given object subgraph immutable, by modifying the object header so that future mutation attempts lead to throwing an InvalidMutabilityException. It is deep, so if an object has a pointer to another objects - transitive closure of such objects will be frozen. Freezing is the one way transformation, frozen objects cannot be unfrozen. Frozen objects have a nice property that due to their immutability, they can be freely shared between multiple workers/threads not breaking the "mutable XOR shared" invariant.
Sharing a more recent and easier explanation from Kotlin Multiplatform Mobile docs here:
The Native runtime adds an extension function freeze() to all classes.
Calling freeze() will freeze an object, and everything referenced by
the object, recursively.
Eg:
data class MoreData(val strData: String, var width: Float)
data class SomeData(val moreData: MoreData, var count: Int)
//...
val sd = SomeData(MoreData("abc", 10.0), 0)
sd.freeze()
freeze() is a one-way operation. You can't unfreeze something.
freeze() is not available in shared Kotlin code, but several libraries
provide expect and actual declarations for using it in shared code.
However, if you're using a concurrency library, like
kotlinx.coroutines, it will likely freeze data that crosses thread
boundaries automatically.
freeze is not unique to Kotlin. You can also
find it in Ruby and JavaScript.
Related
val list = listOf(1, 2, 3)
fun main() {
if (list is MutableList) {
list.add(4)
}
}
The above code throws the below runtime exception.
Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList.add (:-1)
at java.util.AbstractList.add (:-1)
at FileKt.main (File.kt:5)
After reading Kotlin's collection documentation I understand that the kotlin differentiate mutable and immutable collection via interfaces and the immutable interface doesn't have any mutable methods like add() but I wonder what would be the underlying implementation for both List and MutableList on JVM platform? In this case, it looks like the underlying concrete class has the add() method but it throws an exception.
Question:
As I don't have much experience in Java it's quite hard for me to find the concrete implementation of the List and MutableList interface in JVM. It would be great if someone point me to the code or way to track what's the actual java collection under these interfaces. Are both these interfaces get implemented by the same java collections or different ones?
Note:
I'm doing this for my learning and I know it's really bad code and I should use.toMutableList() extension function instead of the smart cast.
As you say, Java doesn't distinguish mutable from immutable lists. (Or at least, not in the type system.) So both the kotlin.List and kotlin.MutableList types are mapped to the java.util.List interface.
The unfortunate consequence of this is that the check:
if (list is MutableList)
…doesn't do what it looks like. It's really just checking whether the object is a java.util.List, and so both mutable and immutable lists will pass the test.
That's why your code is going on to throw an UnsupportedOperationException (which is the Java way to distinguish immutable lists, and indeed any other optional features).
I don't know of any way to reliably distinguish mutable from immutable lists, short of trying to modify them and seeing whether they throw that exception…
It's also worth being aware that listOf() doesn't promise to return any specific implementation. All you can tell is that it'll return something implementing kotlin.List, but it may be mutable or immutable. (In practice, I think it varies depending whether you pass zero, one, or more items. But the exact implementation may well change in future releases of Kotlin, so you shouldn't make any assumptions.)
Similarly, mutableListOf() returns some implementation of kotlin.MutableList, but makes no promises which one.
In practice, if you need a mutable list, then you should create one explicitly (either by creating a specific class such as ArrayList, or better still, calling mutableListOf() and letting it pick the most suitable type). Or if you don't have control over the list creation, then — as you say — you can call toMutableList() (though that may create an unnecessary copy).
Lists can almost always be cast to MutableLists (unless you wrote your own class that implements Kotlin List and not MutableList) because most (maybe all?) of Kotlin’s functions that generate lists use Java Lists under the hood, and Java Lists are always equivalent to Kotlin MutableList. Java’s way of making a List immutable is to throw an exception at runtime when you try to mutate it, which is why you’re getting a crash.
Basically, you should never cast to a MutableList because it is inherently unsafe. It is a common design pattern for classes to expose read-only views of MutableLists as Lists to protect them from being mutated externally. This is how Kotlin protects you from crashes when working with Lists that must not be mutated. If you subvert this design pattern by casting, sometimes it will succeed at runtime because the underlying list was not a Java immutable list implementation, and then you will trigger bugs that are very difficult to track down.
If you want to explore source code, in IntelliJ IDEA or Android Studio, you can Ctrl+click the function to see it’s source code. So in this case you could have done that with listOf and clicked in through until you got to the List implementation being generated in Java.
Do you know how to use Web Speech API in KMM project for Web application: https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API/Using_the_Web_Speech_API
I'm using Kotlin to build the web app, and the web app require speech to text feature.
I'm not familiar with this particular WEB API, but here's the general process of wrapping global JS APIs in Kotlin so hopefully you'll be able to correct the odd inconsistencies yourself via trial and error.
Firstly, since the target API is global, there's no need for any meta-information for the compiler about where to source JS code from - it's present in the global context. Therefore, we only need to declare the shape of that global context. Normally that would be a straightforward task as outlined in this article, however there's a caveat here which requires some trickery to make it work on all the browsers:
As mentioned earlier, Chrome currently supports speech recognition with prefixed properties, therefore at the start of our code we include these lines to feed the right objects to Chrome, and any future implementations that might support the features without a prefix:
var SpeechRecognition = window.SpeechRecognition || webkitSpeechRecognition;
var SpeechGrammarList = window.SpeechGrammarList || webkitSpeechGrammarList;
var SpeechRecognitionEvent = window.SpeechRecognitionEvent || >webkitSpeechRecognitionEvent;
But let's ignore that for now since the API shape is consistent across the implementation, and name is the only difference that we'll address later. Two main API entities we need to wrap here are SpeechRecognition and SpeechGrammarList, both being classes. However, to make it easier to bridge the inconsistent names for them later on, in Kotlin it's best to describe their shapes as external interfaces. The process for both is the same, so I'll just outline it for SpeechRecognition.
First, the interface declaration. Here we can already make use from EventTarget declaration in Kotlin/JS stdlib. Note that the name of it does not matter here and will not clash with webkitSpeechRecognition when present since we declare it as an interface and as such we only care about the API shape.
external interface SpeechRecognition: EventTarget {
val grammars: SpeechGrammarList // or dynamic if you don't want to declare nested types
var lang: String
// etc...
}
Once we have the API shape declared, we need to bridge naming inconsistencies and provide a unified way to construct its instances from Kotlin. For that, we'll inject some hacky Kotlin code to act as our constructors.
// We match the function name to the type name here so that from Kotlin consumer's perspective it's indistinguishable from an actual constructor.
fun SpeechRecognition(): SpeechRecognition {
// Using some direct JS code to get an appropriate class reference
val cls = js("window.SpeechRecognition || webkitSpeechRecognition")
// Using the class reference to construct an instance of it and then tell the kotlin compiler to assume it's type
return js("new cls()").unsafeCast<SpeechRecognition>()
}
Hopefully this gives you the general idea of how things tie together. Let me know if something's still not quite clear.
We have a Kotlin package that we native build and export to C. We have the header file with all the nested struct and pinned-style pointers.
In the Kotlin code, there is a Map which we want to access. We can get a hold of the Kotlin package enum (the key of the Map), but what's the C code for actually indexing into the "kref kotlin Map object" to get to the value in the map?
Basically, we'd like to know how to manipulate Map, List and Array from C code. Actual steps and/or reference doc would be appreciated.
Kotlin/Native compiler does not export any of the collection's functions to the native library API. This decision was taken some time ago, with the idea to minimize the verbosity of the library header. However, this leads to the problem you faced. Right now, the recommended approach is to write wrapper functions in your Kotlin code.For an example of this approach, please see this ticket at the Kotlin issue tracker. I also recommend subscribing to it, to get the updates on the problem's state ASAP. Posting this in case the ticket won't be available for someone:
fun getListElement(list: List<Any?>, index: Int) = list.get(index)
/// function accessing the list element by index
I'm trying to solve the problem of serializing and deserializing Box<SomeTrait>. I know that in the case of a closed type hierarchy, the recommended way is to use an enum and there are no issues with their serialization, but in my case using enums is an inappropriate solution.
At first I tried to use Serde as it is the de-facto Rust serialization mechanism. Serde is capable of serializing Box<X> but not in the case when X is a trait. The Serialize trait can’t be implemented for trait objects because it has generic methods. This particular issue can be solved by using erased-serde so serialization of Box<SomeTrait> can work.
The main problem is deserialization. To deserialize polymorphic type you need to have some type marker in serialized data. This marker should be deserialized first and after that used to dynamically get the function that will return Box<SomeTrait>.
std::any::TypeId could be used as a marker type, but the main problem is how to dynamically get the deserialization function. I do not consider the option of registering a function for each polymorphic type that should be called manually during application initialization.
I know two possible ways to do it:
Languages that have runtime reflection like C# can use it to get
deserialization method.
In C++, the cereal library uses magic of static objects to register deserializer in a static map at the library initialization time.
But neither of these options is available in Rust. How can deserialization of polymorphic objects be added in Rust if at all?
This has been implemented by dtolnay.
The concept is quite clever ans is explained in the README:
How does it work?
We use the inventory crate to produce a registry of impls of your trait, which is built on the ctor crate to hook up initialization functions that insert into the registry. The first Box<dyn Trait> deserialization will perform the work of iterating the registry and building a map of tags to deserialization functions. Subsequent deserializations find the right deserialization function in that map. The erased-serde crate is also involved, to do this all in a way that does not break object safety.
To summarize, every implementation of the trait declared as [de]serializable is registered at compile-time, and this is resolved at runtime in case of [de]serialization of a trait object.
All your libraries could provide a registration routine, guarded by std::sync::Once, that register some identifier into a common static mut, but obviously your program must call them all.
I've no idea if TypeId yields consistent values across recompiles with different dependencies.
A library to do this should be possible. To create such a library, we would create a bidirectional mapping from TypeId to type name before using the library, and then use that for serialization/deserialization with a type marker. It would be possible to have a function for registering types that are not owned by your package, and to provide a macro annotation that automatically does this for types declared in your package.
If there's a way to access a type ID in a macro, that would be a good way to instrument the mapping between TypeId and type name at compile time rather than runtime.
This question already has answers here:
What is reflection and why is it useful?
(23 answers)
Closed 6 years ago.
I was just curious, why should we use reflection in the first place?
// Without reflection
Foo foo = new Foo();
foo.hello();
// With reflection
Class cls = Class.forName("Foo");
Object foo = cls.newInstance();
Method method = cls.getMethod("hello", null);
method.invoke(foo, null);
We can simply create an object and call the class's method, but why do the same using forName, newInstance and getMthod functions?
To make everything dynamic?
Simply put: because sometimes you don't know either the "Foo" or "hello" parts at compile time.
The vast majority of the time you do know this, so it's not worth using reflection. Just occasionally, however, you don't - and at that point, reflection is all you can turn to.
As an example, protocol buffers allows you to generate code which either contains full statically-typed code for reading and writing messages, or it generates just enough so that the rest can be done by reflection: in the reflection case, the load/save code has to get and set properties via reflection - it knows the names of the properties involved due to the message descriptor. This is much (much) slower but results in considerably less code being generated.
Another example would be dependency injection, where the names of the types used for the dependencies are often provided in configuration files: the DI framework then has to use reflection to construct all the components involved, finding constructors and/or properties along the way.
It is used whenever you (=your method/your class) doesn't know at compile time the type should instantiate or the method it should invoke.
Also, many frameworks use reflection to analyze and use your objects. For example:
hibernate/nhibernate (and any object-relational mapper) use reflection to inspect all the properties of your classes so that it is able to update them or use them when executing database operations
you may want to make it configurable which method of a user-defined class is executed by default by your application. The configured value is String, and you can get the target class, get the method that has the configured name, and invoke it, without knowing it at compile time.
parsing annotations is done by reflection
A typical usage is a plug-in mechanism, which supports classes (usually implementations of interfaces) that are unknown at compile time.
You can use reflection for automating any process that could usefully use a list of the object's methods and/or properties. If you've ever spent time writing code that does roughly the same thing on each of an object's fields in turn -- the obvious way of saving and loading data often works like that -- then that's something reflection could do for you automatically.
The most common applications are probably these three:
Serialization (see, e.g., .NET's XmlSerializer)
Generation of widgets for editing objects' properties (e.g., Xcode's Interface Builder, .NET's dialog designer)
Factories that create objects with arbitrary dependencies by examining the classes for constructors and supplying suitable objects on creation (e.g., any dependency injection framework)
Using reflection, you can very easily write configurations that detail methods/fields in text, and the framework using these can read a text description of the field and find the real corresponding field.
e.g. JXPath allows you to navigate objects like this:
//company[#name='Sun']/address
so JXPath will look for a method getCompany() (corresponding to company), a field in that called name etc.
You'll find this in lots of frameworks in Java e.g. JavaBeans, Spring etc.
It's useful for things like serialization and object-relational mapping. You can write a generic function to serialize an object by using reflection to get all of an object's properties. In C++, you'd have to write a separate function for every class.
I have used it in some validation classes before, where I passed a large, complex data structure in the constructor and then ran a zillion (couple hundred really) methods to check the validity of the data. All of my validation methods were private and returned booleans so I made one "validate" method you could call which used reflection to invoke all the private methods in the class than returned booleans.
This made the validate method more concise (didn't need to enumerate each little method) and garuanteed all the methods were being run (e.g. someone writes a new validation rule and forgets to call it in the main method).
After changing to use reflection I didn't notice any meaningful loss in performance, and the code was easier to maintain.
in addition to Jons answer, another usage is to be able to "dip your toe in the water" to test if a given facility is present in the JVM.
Under OS X a java application looks nicer if some Apple-provided classes are called. The easiest way to test if these classes are present, is to test with reflection first
some times you need to create a object of class on fly or from some other place not a java code (e.g jsp). at that time reflection is useful.