-
Notifications
You must be signed in to change notification settings - Fork 356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java annotations for Kotlin sugar #110
Comments
Should we consider |
@fvasco And BTW |
@ice1000 I consider My only consideration against Therefore a really common code pattern is: suspend fun <T> myAwait(block: (MyHandler<T>) -> Unit): T =
suspendCoroutine { cont ->
val handler = ContinuationMyHandler<T>(cont)
block(handler)
} followed by the code val result = myAwait{ handler -> myClass.myMethod(p1, p2, p3, handler) } Permitting the @KtSuspend("mypackage.ContinuationMyHandler")
public void myMethod(String p1, int p2, int p3, MyHandler callback) so the kotlin code becomes val result = myClass.myMethod(p1, p2, p3) |
Another tiny consideration: using So every Java developer has no issue.
|
So you mean |
Maybe is better provide with a
@KtContinuationAdapter("ContinuationMyHandler")
class AsyncByteBuffer {
@KtSuspend
void load(int bytes, MyHandler myHandler) { ... }
}
class ContinuationMyHandler implements MyHandler {
ContinuationMyHandler(Continuation continuation) { ... }
...
} |
We are not going to pursue either of those suggestions as part of this proposal. Coroutines aren't stable and the annotations in this proposal are targeted at library APIs where internal isn't useful. |
Hi @JakeWharton If this KEEP becomes stable before coroutine then it may contain experimental annotation, else the coroutine will be defined and the discussed part might be valid (the above annotation requires only a Finally the This KEEP is interesting not only for well-know public libraries, but it is applicable to every project with mixed Java-Kotlin code. |
The proposal is intentionally limited in scope to increase its chance of success, as evidenced by the last section where we enumerate a few other language features that could easily be included. Attempting to map every Kotlin language feature back into some shape of Java source is an easy and fast way for this proposal to never get implemented. It is a non-goal to solve Java-Kotlin interop for every project as you state. |
@JakeWharton thank you for quick response, The idea behind this KEEP is really interesting, but the most articulate discussed feature, the I not am an Android developer, I am developing a fully asynchronous server application. I consider asynchronous libraries an emerging trend for server-side develop (see Java NIO, Netty, Spring, AWS Java client, Vert.x, ...), so simplify further the Kotlin interoperation with existing Java libraries is a great benefit. Can you consider to introduce an optional part for this KEEP or do you consider a better option extending using a new one? |
@fvasco If you see good use cases mabe make sense to create a new KEEP |
I don't think that internal for Java code is good idea. If some class/method available from Java for some reason no need to overcomplicate it and provide additional visibility rules just for Kotlin. |
Hi @gildor, I exposed all reasonable motivation for Await coroutine stabilization is a JetBrain choice, so I should consider that this KEEP should be included in Kotlin 1.2 (right?). However if your consider interesting this idea and you would examine in deep the not clear parts then I will open a dedicated KEEP. |
Please, 🙏 do not put Kotlin related names in annotations that might be used in standard Java libraries. This should be defined through a JSR with generic semantics that Kotlin might choose to handle afterwards. For instance, Correct me if I'm wrong. Still, I think this initiative is great and trying to improve Java/Kotlin interoperability goes in the right direction, I'm just worried about the implementation and chosen names. |
The names have already changed, which I'll update soon, but being Kotlin-specific is not changing. Otherwise, your own argument works against you:
Any semantics you try to define in some annotations which are common to every JVM language (an impossible task in and of itself, surely) can be trivially undermined by inventing your own language whose semantics are different. |
|
Just updated the proposal based on 2018-05-10 JetBrains and Google/Android meeting. Change summary:
See the commit message for some raw notes. |
How import Java extensions? Ie: for the Java class class Util {
@ExtensionProperty String ca = "ca"
@ExtensionFunction void cm(String p) { }
@ExtensionProperty static String sa = "sa"
@ExtensionFunction static void sm(String p) {}
} should the follow code be valid? import Util
with(Util()) {
ca.cm()
} import Util.sa
import Util.sm
// or import Util.*
sa.sm() Explicit import made easy understand the related Java classes. |
I think this is ultimately for the compiler team to decide, but we talked about requiring an import because otherwise they have to parse a lot of Java to find the extension. (Also worth noting that |
Any status updates from the JetBrains team? This would be extremely useful... |
Any updates? |
any updates? |
We've discussed this proposal with the team and have decided that it does not worth the effort to implement and maintain. The main users of this KEEP were supposed to be existing, mature JVM libraries and to make it really work for them would have required a considerably large design and implementation effort of providing the appropriate level of backwards compatibility, too. More than two years of experience since the creation of this KEEP have shown that there are two approaches to adapting libraries to Kotlin that work well for the community: Approach 1: Rewrite the library to Kotlin, while maintaining binary compatibility for Java clients. For example, this approach was chosen by Square open source libraries (OkHttp, etc) and their experience was mostly positive. Some of Google's Android libraries are also taking this road. Moreover, we plan to continue investing in features that help Kotlin libraries to maintain the desired shape of JVM API surface to make this kind of transition from Java to Kotlin easier. The existing J2K (Java-to-Kotlin converter) tooling helps with this approach a lot and we plan to continue to maintain and improve it. Approach 2: Provide Kotlin support libraries with adapters that add idiomatic Kotlin APIs to existing Java libraries. For example, this approach was taken by the Spring framework team (see the tutorial). Most of the Android core APIs use this approach via Android KTX, too. It is worth noting, that the latter approach is easy to automate if needed. For example, instead of bolting on |
Discussion of the proposal in #111
The text was updated successfully, but these errors were encountered: