I am curious if Deprecated functions in kotlin sta...
# kotlin-roadmap
n
I am curious if Deprecated functions in kotlin standard library are going to stay deprecated forever or if they will be removed eventually. I am think about this one: https://youtrack.jetbrains.com/issue/KT-43306/Deprecate-createTempFile-and-createTempDir-functions-in-kotlin.io in particular.
j
Normally the idea of deprecating functions is to delete them at some point. Either way, it's better not to use them at all.
n
I guess I was wondering if it was decided when they would be deleted. Those still show up as security vulnerabilities in security scans
j
Ah, that I don't know, sorry. You mean the whole stdlib is flagged even if those functions aren't used?
k
I too have come across this irritating issue. Snyk appears to be implying "consider not using the Kotlin standard library" 🙄. Yeah, as if. But this vulnerability is not just in the Kotlin stdlib; it's also in the java.io.File class (which Kotlin uses for these deprecated functions). Yet Snyk doesn't warn you not to use the Java API. What have they got against Kotlin? Maybe it's because Kotlin actually deprecated these functions, but Java turned a blind eye and they're not yet deprecated?
☝️ 1
v
We usually don't completely remove stuff -- it's an irreversible binary incompatible change. Usually we just hide it or deprecate with error. This function is no exception. It's worth reporting this to scanning tool; it seems like even if we'll raise the deprecation level to
ERROR
(so it's impossible to call this function), stdlib still will be reported as potentially vulnerable
k
Their web page says:
Note: As of version 1.4.21, the vulnerable functions have been marked as deprecated. Due to still being useable, this advisory is kept as "unfixed".
So if you do change the deprecation to ERROR so that it's unusable, they should by their own logic remove this advisory.
n
Curious though, can't you just change the implementation to be the safe version that is recommended in the function docs?
k
That would break backwards compatibility as it would involve changing the behaviour of the function. (Even though it was bad behaviour, I don't think JetBrains would want to change it.)
g
This report from Smyk is really strange, those methods would forever be available on java (or even JVM), what is even the point of it
2