com.typesafe.akka:akka-cluster-sharding_2.12:2.5
akka.cluster.sharding.ClusterSharding has the following methods:
public static ClusterSharding get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
public static Extension get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
NB: ClusterSharding <: Extension
None of these methods is synthetic or something, but javac allows
calls like ClusterSharding.get(null) and they get resolved
to the first method returning ClusterSharding
It seems that both javac and IntelliJ resolution algorithms filter out
such clashing declarations choosing the one that has the most
specific return type, the same idea is applied in the change
#KT-17560 Fixed
`isScript` gets invoked for each call
(see org.jetbrains.kotlin.resolve.calls.CandidateResolver#checkOuterClassMemberIsAccessible)
And currently it may work for O(|top-level-declarations|),
that is rather slow e.g. for native stubs for gtk
#KT-17562 Fixed
This prevents .idea/kotlinc.xml from being added with an empty
ArgumentParseErrors object and also fixes
ConfigureKotlinInTempDirTest.testKotlincExistsNoSettingsRuntime11
Rework kotlin-test common tests to make them runnable with qunit.
Change the way how asserter is overridden in js box tests.
Minor: remove unneeded test configs
BaseCompilerSettings.validateInheritedFieldsUnchanged() compares
old and new properties of the compiler settings, and the check requires
ArgumentParseErrors.equals() to be correctly implemented
By default we use the fast implementation in CLI compiler,
but in the most of the tests the old one is enabled
Also add tests on CompiledJava with the fast class reading
implementation
See org.jetbrains.kotlin.load.java.structure.impl.classFiles.BinaryJavaClass
as a counter-example, these classes may be used now in CLI too and they
aren't built upon Java PSI
It's only used for CLI compiler, and it should improve performance
of loading Java descriptors from class-files
For IntelliJ, it leads to 10-15% percent speedup of Kotlin Builder
Before this change, we were using a Java model based on Java PSI that
also read class files, but do it less effectively since it performs
some extra work, that we don't need, e.g. eagerly reading all
the inner classes
It seems to be very natural refactoring considering the
following changes: optimizing KotlinCliJavaFileManagerImpl.findClass
to make it read class files manually instead of requesting PSI
Zalim Bashorov