Future of Java 8 Language Feature Support on Android • Hacker News Board

Re: Future of Java 8 Language Feature Support on Android

#101

Post by SureshG » Thu, Mar 16, 2017, 9:39 AM UTC

nradov wrote: post #86

izacus wrote: post #50

Earlier quoted context omitted.

Ruby, Python, JavaScript, Java and others also aren't "official Google", "Apple", "Microsoft" languages and they still run the whole web. It really question the brokenness of a company processes that refuses to use good tooling just because a corpo didn't tell them to. Kotlin is full interoperable with Java APIs and libraries and at this point there's really very few cases where it's not a significantly better choice…

That's true for now. But there's nothing stopping Google from making changes to Android which break Kotlin support in ways we could never predict. From that standpoint, Java seems much less risky if you're building a large app that you expect to have to maintain and support for years to come.

> But there's nothing stopping Google from making changes to Android which break Kotlin support

It won't, that's what they addressed in this post by ditching jack and switching back to javac bytecode.

"Over time, we realized the cost of switching to Jack was too high for our community when we considered the annotation processors, bytecode analyzers and rewriters impacted."

Re: Future of Java 8 Language Feature Support on Android

#102

Post by lmm » Thu, Mar 16, 2017, 11:16 AM UTC

cel1ne wrote: post #100

lmm wrote: post #79

Earlier quoted context omitted.

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.

> You want to use it sometimes, but not built your entire vocabulary around it.

Sure, which is why it should be an ordinary library type written in the language (and operated on with normal methods), not a magic special type with direct compiler support and custom operators.

> 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.

Why are you thinking in terms of "null" and "wrapping"? Think in terms of the business condition you want to represent. Often you have the possibility of some value being not-set or unknown in your data model - this comes up often enough that it's worth having a standard library type to represent it. "A variable being null" is not something that happens a priori, it's just an unfortunate representation certain languages adopt.

Re: Future of Java 8 Language Feature Support on Android

#103

Post by AnimalMuppet » Thu, Mar 16, 2017, 5:31 PM UTC

pjmlp wrote: post #90

AnimalMuppet wrote: post #89

Earlier quoted context omitted.

Um, do you realize that those licenses prohibit using it on a phone, because Sun/Oracle wanted to protect JavaME? So what you're asking for is for Google to not do Android, and then they wouldn't have the problems that they're having doing Android. That's... not a useful suggestion.

Google could use them on the phone, they just needed to PAY Sun just like everyone else, but of course they wanted to have the cake for free.

Given that APIs can't be copyrighted, why shouldn't they have that particular cake for free?

(Actually, the current court ruling is that APIs can be copyrighted, but re-implementing them is fair use. My personal IANAL opinion is that that won't stand - it will either turn into "APIs can't be copyrighted" or else into "APIs can be copyrighted, and the copyrights are not worthless - you can't copy it and have it be fair use". We shall see. Nevertheless, at the time Google copied the API, the assumption in the whole industry was that an API could not be copyrighted. Your statement that Google "wanting their cake for free" carries a tone of moral criticism that is unwarranted by the circumstances.)