Closed circlespainter closed 7 years ago
@circlespainter I don't understand the Java 8/7 issue. Does it work with quasar-core-jdk8 ?
@pron Yes it does.
The problem is that when using a JDK7 (and Java 7 deps), the Kotlin build prints:
w: Running the Kotlin compiler under Java 6 or 7 is unsupported and will no longer be possible in a future update.
And some test/lib code using Kotlin overloads breaks (I could actually see the wrong overloads called in bytecode), with the workaround simply being renaming the problematic overloaded methods (but of course this can happen in user code as well).
Instead with JDK8 no such warning is printed and everything works fine, no matter what the target source or bytecode (that is, both with target 7 and 8).
Actually, given such a warning, I think it would be sensible to avoid building the Kotlin module when using < JDK8.
I added conditional (on java8
) inclusion for quasar-kotlin
and I also added a quasar-kotlin-jdk8
project with the same inclusion condition and using the very same sources as quasar-kotlin
, except that it depends on the jdk8
Quasar, on the jdk8
Kotlin stdlib and it compiles both Java and Kotlin sources with a 1.8 target.
Since the quasar-kotlin-jdk8
's deps are different than quasar-kotlin
I think the former can't be just an additional quasar-kotlin
artifact and instead it needs to be a separate subproject.
Do you have a timeline on the release cycle? I would love to be using this today but I can't seem to get anything working...
@circlespainter Why do we need both quasar-kotlin
and quasar-kotlin-jdk8
if Kotlin only works with JDK 8 anyway?
quasar-kotlin
works with Java7 and the user Kotlin code can work with Java7 too (of course appropriate deps and target must also be used) but it has to be compiled with Kotlin running on Java 8 as the Kotlin compiler doesn't officially support anymore being run on Java7 and probably such support will be removed completely.
Now I got it. Thanks. So why not make quasar-kotlin
support JDK 8 only instead of adding yet another artifact?
Currently quasar-kotlin
can only be used by people compiling with JDK 8 (because the Kotlin compiler only supports that) but it uses at most the Java 7 class format and APIs [1]; this means that people depending on it could still target the Java 7 class format and APIs and so support JRE 7 users.
quasar-kotlin-jdk8
instead uses the Java 8 APIs and class format [2] so there's no choice: all depending artifacts can only run on JRE 8.
As a simplifying choice we can surely drop the Java 7 quasar-kotlin
and have only a Java 8 one, at the cost of losing JRE 7 users.
--
[1] More precisely the Kotlin jdk7
stdlib dependency uses the Java 7 class format and APIs but the Kotlin compiler targets the Java 6 class format (because it has no Java 7 target, only 6 and 8).
[2] Because it uses the Kotlin compiler's Java 8 target, the jdk8
Quasar and the jdk8
Kotlin stdlib.
I think we can drop JDK 7 support for Kotlin, seeing that the Kotlin compiler has also done that. There's no need for a new artifact name. We can make quasar-kotlin
JDK 8 only.
Done, in addition I found a better workaround for the plugin issue (it's enough to disable timewarp
for quasar-kotlin
) and I upgraded to 1.1.3-2
.
Any idea how long til this goes to release?
Released.
@pron Cheers!
Some notes:
for
s restored when the identifier is used in the body.quasar-core
(better but harder) or with a separatequasar-kotlin-jdk8
artifact (worse but easier, many people doing it anyway incl. the Kotlin guys). Not sure if better to tackle this now or later, for now there's only a pre-8quasar-kotlin
artifact. @pron What do you think?receive
functions fromAny
toAny?
because (seemingly a bug but needs investigation) else the Kotlin 1.1 compiler seems to choose the Java base class'receive
with theMessageProcessor
(without even complaining about the ambiguity).synchronized
used (viaUnsafe
it seems) in the stdlib. The other 2 lazy impls. in the stdlib ("safe for publishing" and "unsafe") instead seem to work OK with fibers.Lazy
I'm not instrumenting higher-order stdlibs because most often they won't call into suspendables and, when they do, the user can annotate them externally anyway (this is not auto-instrumentation for Kotlin).@Ignored
test for https://github.com/puniverse/quasar/issues/275 (ignored because it's not fixed yet).On Java 8, tests run fine with verification enabled in all of the following configs:
(Yes, Kotlin's compiler has now 2 targets: 1.6 and 1.8; the stdlib instead has now 3 versions: 1.6, 1.7 and 1.8).