hehe, no problem

and even if ART will become better in the next years, we will still have to support Dalvik for a while

which is why all optimizations on the Kotlin side are welcome to Android devs

I think when you’re an Android developer, you shouldn’t rely on any optimizations of JVM or language. We check generated bytecode for most stuff usually.

I actually expect more to come since we are more or less settled with 1.1.

I check it from time to time

is optimizing away

Ref$IntRef

and friends for inline functions on the roadmap for 1.1?

so that I can swap two variables with maximum efficiency using

a = b.apply { b = a }

🧌

1.1 is mostly about new language features. Everything else is prioritized as usual.

sounds good to me, love me some features 😉

hm, did ART decrease app install time that much?

i thought it was just my imagination some apps being really slow to install

lollipop and marshmallow were horrible slow, on N it should become really fast again

hopefully not at the expense of startup

i mean app startup

when it is, it'll be years before it gets even approachable adoption

marshmallow is at like what, 10-15%?

Existing tools can already create, manipulate, and consume JAR files, so for ease of adoption and migration we define modular JAR files. A modular JAR file is like an ordinary JAR file in all possible ways, except that it also includes a module-info.class file in its root directory. A modular JAR file for the above com.foo.bar module, e.g., might have the content:

```

META-INF/ META-INF/MANIFEST.MF module-info.class com/foo/bar/alpha/AlphaFactory.class com/foo/bar/alpha/Alpha.class ... ```

A modular JAR file can be used as a module, in which case its module-info.class file is taken to contain the module’s declaration. It can, alternatively, be placed on the ordinary class path, in which case its module-info.class file is ignored. Modular JAR files allow the maintainer of a library to ship a single artifact that works both as a module, on Java SE 9 and later, and as a regular JAR file on the class path, on all releases. We expect that implementations of Java SE 9 which include a jar tool will enhance that tool to make it easy to create modular JAR files.

There's sections in here concerning compat.

yeah but that doesn't cover the other changes like classloader stuff, jre security stuff (only having a few things in bootstrap)

thanks, i'll add that to my reading list

I see a brief mentions of classloaders, but not security. Might not have those answers for you.

this can’t be serious https://youtrack.jetbrains.com/issue/IDEA-159511

What about it seems like a joke? There is another issue (can’t remember the number, nor care enough to look it up) for updating the packaged Maven version (current packaged version is 3.0.3)

I’m assuming that is what the real problem is...

the fact that it was “resolved” as can’t reproduce without as much as a comment

i’d expect some more for an issue that makes idea highlight dozens of lines of valid code as syntax errors, essentially making it unusable

and regardless of the version used, real issue is that idea tries to resolve dependencies itself instead of getting them from maven (I’m pretty sure it can be done)

otherwise it wouldn’t even know these artifacts exist, since maven executable would only give one