What implementation class is used to back the Set<E> and MutableSet<E> types returned by setOf() and mutableSetOf()?
Since the api documentation describes MutableSet as A generic unordered collection of elements, and since elements don't have to be Comparable, I'm guessing it's a HashSet but I can't find confirmation.
Taking a look inside Kotlin sources here and here, it seems that both return LinkedHashSet. There is an exception, in case setOf() is provided an empty list, it returns a singleton object (Kotlin object) which is defined at the top of the first file (link).
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.
Is there any way to get only the declared members of a class (not inherited) with Kotlin Reflection?
Something equivalent to getDeclaredMethods(), or ...Fields(), in Java, but for members and JVM free, which:
Returns an array containing Method objects reflecting all the declared methods of the class ... but excluding inherited methods.
Or like a binding flag, such as BindingFlags.DeclaredOnly of dotnet.
Because the reflection is based on the class, So the following is only for the kotlin/JVM, not suitable for the Kotlin/JS or Kotlin/Native.
For the Kotlin/JS it supports limit, for detail, you can see this
document
The only supported parts of the API are: (::class),KType and typeOf
Firstly, you can use the SomeClass::class.java.declaredMethods to get the
getDeclaredMethods. That is the java method. Because the Kotlin file after compiled it is still a class. so you can directly use it.
You can also add the kotlin reflect to get the KClass, then use the declaredFunctions to get. Here is the Document
Returns all functions declared in this class. If this is a Java class, it includes all non-static methods (both extensions and non-extensions) declared in the class and the superclasses, as well as static methods declared in the class
For how to get the KClass, you can use the following code
Class.forName("mypackage.MyClass").kotlin.declaredFunctions
Besides the method, the other property you can also get. such as
declaredMembers
Returns all functions and properties declared in this class. Does
not include members declared in supertypes.
allSuperclasses
functions
Returns all functions declared in this class, including all non-static methods declared in the class and the superclasses, as well as static methods declared in the class.
you can read the document using it.
It seems Kotlin core Data Structures (i.e. Map, List, Set) are really an interface and not really immutable.
If I have:
fun <K,V> foo(map: Map<K, V>) {
...
}
Can map change after I received it - from outside?
In which cases is it possible?
No.
The Map interface does not provide any mutator methods, so an implementation could be completely immutable.
But other implementations aren't — in particular, MutableMap is a subinterface, so anything implementing that is a mutable Map. This means that code with a reference to a Map could potentially see the data changing, even though it couldn't make those changes itself.
Similarly, MutableList is a subinterface of List, and MutableSet is a subinterface of Set.
There are immutable implementations of those top-level interfaces (such as the kotlinx.collections.immutable and Guava libraries) — and you could write your own. But the Kotlin language and type system don't yet provide strong support for deep immutability, only for read-only interfaces to data that may or may not be immutable.
(That's not to say that such support couldn't be added in future. There is a lot of interest in it, and JetBrains have been considering it.)
Let's run an experiment:
class Foo {
#Test
fun foo() {
val items = mutableListOf("A")
run(items)
Thread.sleep(1000)
items.add("B")
println("Foo")
Thread.sleep(2000)
}
fun run(items: List<String>) {
thread(start = true) {
println("Run ${items.count()}")
Thread.sleep(2000)
println("Run ${items.count()}")
}
}
}
This test case will create a mutable list of 1 item, it will then pass a reference to this list into a method whose type is for an immutable list.
This method called run will diplay the length of the list.
Outside of the run method a new item will be appended to the list.
sleeps have been added ensure that the addition to the list happen after run's first statement but before the second print statement.
Let's examine the output:
Run 1
Foo
Run 2
As we can see, the list contents did indeed change, even though run took in an immutable list.
This is because MutableList and List are merely interfaces and all MutableList implementations also implement List.
When Kotlin refers to mutable and immutable it simply references whether the methods to modify the collection are present, not whether the contents can be changed.
So if you take in a list to a method using List as the parameter type then yes, the contents can vary if they are altered by another thread, if that is a concern then make a copy of the list as the first thing your method does.
As other have indicated, the map could be modified while you're using it in another thread... however that would already be broken unless your access to the map was #Synchronized, which would indicate that you knew it would change, so this possibility is not really a problem. Even if your method took a MutableMap parameter it would be wrong if it was changed while your method was in progress.
I think you're misinterpreting the purpose of the read-only collection interfaces.
When your method accepts a Map as a parameter, you are indicating that the method will not change the map. The purpose of the read-only Map interface is to allow you to say such things. You could do (map as? MutableMap)?.put(...), but that would be wrong since you promised not to do that. You could also crash the process in various ways or run an infinite loop, but that would also be wrong. Just don't do it. The language does not provide protection against malicious programmers.
Similarly, if your method returns a Map, that indicates that the receiver must not change it. Usually in such cases, you also promise (hopefully in a comment) that the returned map will not change. You can't keep this promise if anyone who receives the map can change it themselves, and that is why you return the Map instead of the underlying MutableMap
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.