As you know the private classes in Kotlin change to package-private under the hood and internals changed to the public.
unfortunately, this can lead to the known problem here.
if the compiler sees the usage of Kotlin internal classes when it wants to change it to the byte code, it can choose package-private for internal kotlin classes that didn't use outside of the package and choose public for others, so we can handle above problem on our own.
Or they can define another annotation such as #JvmPackagePrivate before internal classes to tell the compiler we want a package-private class in java.
Or they can do both.
The question is, why they don't solve this obvious problem with such an obvious solution?
Are they have another approach to solve this?
I just got acquainted with the Kotlin, so I think that I cant create lib for java with kotlin because when I create internal concrete classes, all client can see them outside of the library and its serious problem with kotlin. why they can't see this obvious problem??????
I want to mention that none of the answers in here solve this problem because of #JvmSynthetic and #JvmName just target the fun in kotlin, not classes and at the end they both visible even if they change the name of classes.
at last kotlin claims that it is completely interoperable with java but I think it's not right. better to say that it is 99 percent interoperable with java :)
Related
I have a Kotlin Library into which I integrated the usage of Detekt static code linting. Most of the rules are clear to me and I fixed all the issues with my code except for one:
There is a rule called LibraryEntitiesShouldNotBePublic, which makes no sense in my opinion. It tells me for every public class, that it should not be public, but of what use is a library without any public classes.
I must admit I am rather new to Kotlin, coming from Java, so I might miss some language feature here.
Any hints would be greatly appreciated. Thanks.
I followed the tutorial https://kotlinlang.org/docs/tutorials/native/mpp-ios-android.html, then I successfully create the folders of androidmain, iosmain and commonmain.
However when I want to implement the datatype BigDecimal in the commonmain. It won't work. I need the decimal dataype for the currency.
I know that the question is old, but, in case anyone stumbles upon this topic, I made a KigDecimal library that implements BigDecimal and BigInteger for kotlin multiplatform (for jvm and js). The library is distributed completely freely. Therefore, I invite everyone to supplement and expand it, if desired.
On the jvm side, BigDecimal and BigInteger are just the corresponding types from java. And on the js side is used https://www.npmjs.com/package/bigdecimal.
The main repository is located here: https://gitflic.ru/project/mikhaylutsyury/kig-decimal
There is also a mirror on github: https://github.com/YuryMikhailuts/kig-decimal
But the mirror can sometimes lag a little behind the main repository.
There is no support for BigDecimal in the Kotlin common code (yet).
You may have a look at the related thread
https://discuss.kotlinlang.org/t/multiplatform-bigdecimal-implementation/5631
You may create your own implementation for such a class with expect and actual keywords.
https://kotlinlang.org/docs/reference/platform-specific-declarations.html
The idea is as follows:
you declare expect declarations for the BigDecimal type in common code
you use the actual annotations at every platform to supply the platform specific implementation (e.g. JVM's BigDecimal class)
I see kotlin.List and kotlin.MutableList is implemented by java.util.ArrayList. But where did kotlin put this trick? Compiler or somewhere in stdlib?
If kotlin supports making a class implementing an interface outside of its definition file like the ArrayList case, it will be fascinated.
No, it is not supported.
You are right, that is only a compiler trick. There are lots of magic applied to the collections to make them right. Fortunately it is not available to the devs. Special paragraph in the docs: https://kotlinlang.org/docs/reference/java-interop.html#mapped-types
It's common in a lot of classes in JDK, just a few examples:
java.util.Properties
load0
store0
java.lang.Thread
start0
stop0
setPriority0
Usually they are private native methods (like in Thread class), but sometimes they are just private (Properties class)
I'm just curious if anybody know if there is any history behind that.
I believe they are named like that because equivalent functions with same names exist in the code and just to distinguish between native helper functions and public functions they decided to suffix them with 0.
in java.util.Properties both load, store and load0, store0 exist.
The 0 after the method name is done so to distinguish between public and private methods having same name .
Start function will call the start0 function.
Those functions which ends with 0 is private method.
And those which are not ending with number is public.
You can check in any of the library.
The use of zero suffixes on method names is just a convention to deal with cases where you have a public API method and a corresponding private method. In the Java SE libraries, this is commonly used for the native methods that provide the underlying functionality implemented by the classes. (You can see what is going on by looking at the OpenJDK source code.)
But your questions are:
Why some java methods in core libraries end with numbers?
Because someone thought it would be a good idea. It is not strictly necessary since they typically could have overloaded the public methods instead. And since the zero suffix matters are private, the naming of methods should not be relevant beyond the class and its native implementation.
I'm just curious if anybody know if there is any history behind that.
There is no mention of this convention in the original Java Style Guide. In fact, I think it predates Java. I vaguely recall seeing it in C libraries in 4.x BSD Unix. That was the mid 1980's. And I wouldn't be surprised if they adopted it from somewhere else.
I am not a program designer by any means but I would really like to start getting a better grasp of how to do it and a better understanding of the .NET languages in general (VB, C#). I was reading a book by Wrox - Professional Visual Basic 2008. In it I believed it mentioned that Modules are slowly going out of existence. I can see why most coding would go into a class object but I would assume modules would always be necessary to at least keep the code clean.
Could anybody clarify this up for me? Also, I have been searching for a good source on software design but I can't seem to find any recent books published. I might be searching in the wrong places but I would really like to get my hands on one.
Thank you.
While in general they don't quite fit with OOP, they are still used and are required in some cases.
In VB.Net, if you wish to write extension methods, you are going to have to use a Module - The compiler will only allow Extension Methods to be defined in one.
You could of course get round not using Modules - an Non Inheritable Class with a private constructor and nothing but Shared Methods will achieved the same thing as a Module.
Like everything in programming (and many other things), they have their uses, and as long as they are not miss-used there is no problem with them. Right tool for the job!
The Module keyword in VB.NET primarily exists for compatibility with VB6 and earlier. Back then, most VB code was procedural with free-standing non-class Subs and Functions. The language acquired the Class keyword somewhere around VB4. Not true classes in the OOP sense, it didn't support inheritance. A feature missing from the underlying COM architecture.
It doesn't fit very well with the execution model provided by the CLR. There is no support for free functions, every method must be a member of a class. The VB.NET compiler emulates modules by declaring a class, the module procedures become Shared methods of that class. You can see this with Ildasm.exe:
.class private auto ansi sealed ConsoleApplication1.Module1
extends [mscorlib]System.Object
{
.custom instance void [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute::.ctor() = ( 01 00 00 00 )
} // end of class ConsoleApplication1.Module1
Note how it is private, so that code can't get a reference to it, and sealed, so that no code can derive a class from a module.
The C# compiler does the exact same thing with a "static class", the CLR doesn't have a notion of static classes either. There are plenty of good reasons for static classes, the idea of "Module" isn't obsolete. You could accomplish the same by declaring a NotInheritable Class in VB.NET code, having only Shared methods. The VB.NET compiler however doesn't enforce methods to be Shared like the C# compiler does and doesn't allow you to declare the class private. As such, a Module is just fine.
Modules are the closest thing VB has to static classes, which can be very useful, even when programming in an object-oriented environment.
And since VB has no static classes, modules are as far as I know the only way to create extension methods.
You need modules in order to define your own Extension methods