Every other commercial JDK vendor is able to comply with licenses and still provide language extensions and their own VM stacks. There are quite a few examples to chose from. Why should Google be a special snowflake that doesn't play by the same rules?
Why should they have to play by the same rules? If the rules they are playing by are judged to be legal, what's wrong with what they're doing?
To avoid doing a Microsoft move on us that now enjoy the pain of writing not so portable Java code across official standar Java™ and Android devices, thus making a fork in the Java ecosystem.
I think their legal shenanigans regarding usage of Java technology plays a major role here: they simply do not own Java technology. It was a horrible mistake to use it without Sun's/Oracle's approval and as soon as the first lawsuit ends in favor of Oracle, they will be milked to an extent that has not yet been seen.
First, Oracle's legal theories have not held up very well in court. Second, Oracle has explicitly said that OpenJDK is OK, and Google has shifted to an implementation based on OpenJDK. So I wouldn't hold my breath for your prediction coming true...
> Google has shifted to an implementation based on OpenJDK.
No they have not, just go look at AOSP source code.
Yes they are using it instead of Harmony nowadays, but they are cherry picking features and APIs, instead of providing 100% compatibility with the language standard.
AFAIK they did this to 1) improve runtime link/startup times (so, a similar reason why many other mobile devices have their own class file formats; for more information, read my introduction to the subject, linked below), and 2) to make sure they were not violating various bytecode-related patents from Sun that relied upon a stack machine. http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0...
1) I don't believe. I'm not talking sun's JVM, just the byte code. We have jvms with super fast boot times already, just not openjdk. 2) interesting. I wasn't aware of these. It would have been useful to get sun involved in the project, but they didn't.
Did you read my article? (Because your comment doesn't seem to bring up any actual rebuttal of the point, which makes me think you didn't, which makes me hesitant to waste more of my time explaining it, particularly as it might make it seem OK to just toss aside arguments with "I don't believe" as the other person will then just do more work in the conversation.) The problem with bytecode is that it has complex linking and relocation issues. DEX was specifically designed to convert trivially to ODEX, and which hardcodes vtable and field offsets to make interpretation trivial and fast, while also letting the code be memory mapped between processes. FWIW, current versions of Android have expanded the optimization step all the way up to something more like a compiler, but it took them many many years to get to that point. Since you are speaking with someone who is extremely familiar with VM design, as well as the history of the Android project and its unique limitations, would you mind being more specific with what you feel is inaccurate? (I am totally willing to believe I missed something, as I spend way way more of my time on iOS internals, and I am "rusty" with VMs--though not so much that the students I teach to about them notice horribly ;P--but it just doesn't seem like that so far.)
I'm no expert on Java 8, but it looks like the new feature they call "extension methods" is just the ability to define methods in interfaces and inherit them, essentially like a concrete method in an abstract base class, isn't it? The "extension methods" in Kotlin (and C#) is a completely different feature: syntactic sugar for static utility methods, which allow you to add new methods to any class without needing to…
> ...whereas in Java you would have to change (and have access to) the implementation of one of the classes or interfaces that String inherits from. Or, you know, just define a plain function. > which allow you to add new methods to any class without needing to modify the original class No, those aren't methods, because they don't do dynamic dispatch. This is actually a problem in case you have an inheritance hierarc…
> Or, you know, just define a plain function.
My comment was about extension methods and how the name refers to different features in Java and Kotlin, so I meant "...whereas in Java [if you wanted to use the Java feature to do the same thing the Kotlin feature by the same name does] you would have to ...".
> those aren't methods
I know, they're only sugar for static methods, as I said.
Well, when you have an ongoing lawsuit with Oracle you have to careful of what you say in public.
They are the ones to blame for it. Apparently every other commercial JVM vendor doesn't have any issue to comply with licenses, while offering their own changes to Java stack. IBM, MicroEJ, Atego, just to cite three examples out of many.
Perhaps, but I will say that none of them are nearly as juicy of a lawsuit target as Android, which controls like 70%-ish of the multi-billion device smartphone market right now.
The possibility of running Scala >=2.12 (or any other language that is committed to Java 8[1]) on Android seems even more remote now. Jack+Jill at least promised a way of running Java 8 bytecode on Android[2]. What now? Is Java source code going to be the only common currency between the Java 8 and Android ecosystems? [1] https://www.scala-lang.org/download/#Software_Requirements [2] http://stackoverflow.com/question…
IMO having Android VM fully compatible with Java 8/9/10 is a non-realistic dream considering what Google is doing now :/
It never was, even the adoption of OpenJDK is a marketing gig, as they are actually cherry picking features, as anyone reading the AOSP source code history can validate.
> ...whereas in Java you would have to change (and have access to) the implementation of one of the classes or interfaces that String inherits from. Or, you know, just define a plain function. > which allow you to add new methods to any class without needing to modify the original class No, those aren't methods, because they don't do dynamic dispatch. This is actually a problem in case you have an inheritance hierarc…
> Or, you know, just define a plain function. My comment was about extension methods and how the name refers to different features in Java and Kotlin, so I meant "...whereas in Java [if you wanted to use the Java feature to do the same thing the Kotlin feature by the same name does] you would have to ...". > those aren't methods I know, they're only sugar for static methods, as I said.
Right, and I was pointing out that your comment doesn't make much sense.
They are the ones to blame for it. Apparently every other commercial JVM vendor doesn't have any issue to comply with licenses, while offering their own changes to Java stack. IBM, MicroEJ, Atego, just to cite three examples out of many.
Perhaps, but I will say that none of them are nearly as juicy of a lawsuit target as Android, which controls like 70%-ish of the multi-billion device smartphone market right now.
James Gosling stated multiple times that the only reason Sun didn't sue Google and Jonathan made that public announcement was the state of Sun's bank account.
Kotlin doesn't really have true reified generics (any more than e.g. Scala has), Java 8 has first class lambdas, extension methods and @Nullable now. Kotlin is just Java 8 with cleaner syntax.
I'm no expert on Java 8, but it looks like the new feature they call "extension methods" is just the ability to define methods in interfaces and inherit them, essentially like a concrete method in an abstract base class, isn't it? The "extension methods" in Kotlin (and C#) is a completely different feature: syntactic sugar for static utility methods, which allow you to add new methods to any class without needing to…
Also in Kotlin you can have extension methods with multiple receivers:
class Dictionary {
val wordList = setOf()
fun String.isWord(word): Boolean =
word in wordList
}
...
val myDictionary = Dictionary()
with (Dictionary) {
println("dog".isWord)
}
(you can skip the "with" when being inside Dictionary)
Kotlin has generics that are in most circumstances reified enough ;). Optionals of Java8 and Guava are a terrible idea. @Nullable is just an annotation. Null-safety built in the language is the only way to go. You could always argue that a language is just cleaner syntax. Kotlin is a cleaner syntax for interacting with JVM-bytecode. Scala is a also cleaner syntax for interacting with JVM-bytecode. JVM-Bytecode is a c…
Optional is a concept that you need even in a null-safe language (e.g. Haskell has Maybe). With language-level nullability you can sort-of emulate a pseudo-Optional type, but why would you want to? It's inherently second-class because it can't ever be properly compositional (Option[A] is always a different type from A and can be understood without knowing anything about A, whereas A? might or might not be a different…
I think it most real code you're better off without the Optional monad.
A variable being null is not a condition you can always a have a name for. You want to use it sometimes, but not built your entire vocabulary around it.
You also don't usually want to pass wrapped nulls around, you just want nulls available in local state.