dalexander: true true. Allows you to hide a lot of really ugly shit

@aaronhe: Really what?

hah wrong aaron

but the java 8 thing

oops

especially considering how we saw kotlin’s foreach break on android because of jdk8

@asarazan: When was last time you added a dependency to

build.gradle

and at deployment time, it crashed because of that?

good point

Ah, yeah. I mean inner classes have always been an option, but at least to me having the cleaner syntax makes it easier to think about using that kind of pattern to solve problems.

You’re pulling in libraries written by people who have probably never written a single line of Android code and blam, it works.

libraries were a big problem when i was doing android work. almost everything needed forking to be made android compatible (or we had to use some poor quality substitute library instead). @jw's various libraries saved my life several times

think that'll be the main thing that a switch to openjdk's class library will fix

@rm: the only library I can think of with that constraint these days is joda

because of that weird class loader issue or whatever it is

you generally don't find out until you try to call a method that results in a class being loaded that has a missing annotation type or something along those lines

the problems are pretty widespread and lurking

thankfully i don't do android work anymore! 😁

@rm: I don’t remember any of this library problem (as long as they don’t use awt or similar stuff)

the switch to OpenJDK is not going to alleviate any of these alleged problems

Same functionalities, different implementation

a lot of the problems were libraries using things that are in the standard libraries but are missing in apache harmony

so either you fork and create a replacement class (which the android tools would then loudly complain about, due to inevitably being in the

java.*

or

javax.*

namespaces) or use a different and android-specific library

this was only 4-5 months ago, i doubt the landscape has changed that much since then

In my experience (and I suspect a lot other people), this is hardly ever a problem. The most noteworthy classes missing are graphical ones, but for the rest, I can’t remember when was last time I added a dependency to

build.gradle

and my Android app blew up.

well i'm not up for arguing about anecdotal evidence. it happened to me frequently, it was painful, i'm glad it's over, and they'll probably fix it later

🎉

I’d actually be interested in hearing specific examples if you can dig them up, @rm.

Not to argue anecdotal evidence, just haven’t run into it and am curious

i'd have to go back searching through slack logs. most of it didn't make it into git as we'd test, find issues, replace the dependency, commit

http://xom.nu was one i do remember, and that was down to it containing classes in the

javax.*

namespace