OOC, how does "Problem" kind of YouTrack issue dif...
# compiler
p
OOC, how does "Problem" kind of YouTrack issue differ from a "Bug"? "NONE_APPLICABLE" with JVM stdlib but not with Common stdlib got converted to a problem, and I'm wondering out of pure curiosity what it means in practice. Does it mean lower priority?
in my projects, I use the "problem" label if it's not a bug, but rather a problem with some external tool or circumstances. is it the case here?
d
In general the difference is the following: • Bug is something which definitely works not as intended and it appeared because of the mistake of some developers • Problem is something that works more or less as expected, but the resulting behavior is problematic (leads to some problems for users)
p
so in case of a problem, can it be understood as a result of a conscious design decision, for example?
d
Your particular issue caused by the current KMP compilation scheme: when you compile some KMP hierarchy to, for example, jvm, then all modules (both commons and platform) have platform libraries as dependencies. So if your jvm source set depend on
some.jar
, all declarations from
some.jar
will be visible in the common source set during JVM compilation. In your case it strikes that the common
StringBuilder
class from common kotlin stdlib is completely not present at the classpath, and only java one is here Such design had some sense when it was originally implemented when the MPP was released (in 1.2 or 1.3), but it has some drawbacks, and the one you faced is the most important one Right now we are working on a different compilation scheme for KMP projects which targets to fix exactly this problem. The working prototype is ready and we are planning to start productization of it soon
p
got it, thanks! 🙇
👌 1
is there a YouTrack issue I can watch/star for the productionization?
d
KT-66205 and related
p
thanks! it makes sense to link my bug with this ticket, if you can
✔️ 1
thank you color 1