Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Future of Java 8 Language Feature Support on Android

android-developers.googleblog.com

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Future of Java 8 Language Feature Support on Android

#81

Post by khana »

pjmlp wrote: post #29
dkarl wrote: post #10

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…

Google has no interest in providing the right support for Java developers it seems. Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement. And of course, lack of many of the SE APIs in any case. The fun of writing portable libraries between Java and Android Java is only getting better.

I would think Google endeavors to move AWAY from Java given its current stewardship. I think Go is the future of Android.

Re: Future of Java 8 Language Feature Support on Android

#82

Post by pjmlp »

oblio wrote: post #76
pjmlp wrote: post #44

Earlier quoted context omitted.

Our customers do, if it isn't a vendor supported language on platform X, usually their IT doesn't allow it on their list of languages for project delivery.

Are they the kind of folks that demand that you use .NET or C++ on Windows? I had a colleague like that. I had to explain to him that people are actually using Java or Python in production, on Windows.

Depends on the customer, but yes that is usually the case.

Re: Future of Java 8 Language Feature Support on Android

#83

Post by bad_user »

ptx wrote: post #58
pkolaczk wrote: post #52

Earlier quoted context omitted.

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…

> ...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 hierarchy and you want different behavior for a ChildClass extending a BaseClass.

Speaking of Scala, it's the only one out of the ones mentioned here that can do that based on the compile-time time, by letting you define the same extension for both ChildClass and BaseClass, but with different priorities, such that the compiler can disambiguate.

Re: Future of Java 8 Language Feature Support on Android

#84

Post by lmm »

Larrikin wrote: post #80
lmm wrote: post #71

Earlier quoted context omitted.

If Kotlin wasn't just CoffeScript for Java but a whole new language then there would be no reason to use it instead of Scala. There's an excluded middle here: either it's a very-close-to-Java language (in which case probably not worth the cost of using) or it's a language that's significantly different from Java (in which case it has no interop/familiarity advantage over Scala and the two languages have to be compare…

One of the arguments against Scala is that its large and simply too feature rich. https://agilewombat.com/2016/02/01/scala-vs-kotlin/

The parts it does add are small and orthogonal. They can be combined to make surprising things, but that's the mark of a good language - it lets people write very complex libraries, but by combining simple features in ways that make sense.

Specifically, call by name is highlighted in the IDE these days (though I agree we would be better off without it), implicit parameters are really important and it's not hard to ensure consistency, for comprehension is the opposite of what that site is saying (dealing with multiple monads is a lot harder without it, and it's not like ignoring monads as Kotlin does makes the problems you need monads for go away), and the rule about operators is incredibly simple (your method name is just your method name, if you want to write a "" operator you call it "" rather than having to remember what the magic name for overloading that is).

Meanwhile your link ignores the many complex features in Kotlin e.g. delegation, platform types. Maybe they were added since it was written - Kotlin seems to add a lot of ad-hoc features very quickly.

Re: Future of Java 8 Language Feature Support on Android

#85

Post by pkolaczk »

cel1ne wrote: post #57
pkolaczk wrote: post #52

Earlier quoted context omitted.

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.

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…

> Kotlin has generics that are in most circumstances reified enough ;).

They are not more reified than what you can achieve by just putting Class fields in Java objects to represent the runtime type of the generic type parameter. Sure, Java solution is kinda more verbose and ugly, but this is basically what people already said here: Kotlin has some nice syntax sugar.

But you still can't have two different methods differing only with the generic type parameter (e.g. List and List). And the code is still not-specialized properly, read "slow".

Real reification will be possible if project Valhalla arrives (maybe Java 10, who knows?)

Re: Future of Java 8 Language Feature Support on Android

#86

Post by nradov »

izacus wrote: post #50
pjmlp wrote: post #46

Earlier quoted context omitted.

Swift is officially an Apple language. While Kotlin is nowhere to be seen on Android SDK and Google is officially silent on its use. This matters a lot to customers IT departments, writing the set of delivery languages on their Requests For Proposal to consulting companies.

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.

Re: Future of Java 8 Language Feature Support on Android

#87

Post by AnimalMuppet »

_pmf_ wrote: post #51
pjmlp wrote: post #29

Earlier quoted context omitted.

Google has no interest in providing the right support for Java developers it seems. Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement. And of course, lack of many of the SE APIs in any case. The fun of writing portable libraries between Java and Android Java is only getting better.

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

Re: Future of Java 8 Language Feature Support on Android

#88

Post by AnimalMuppet »

pjmlp wrote: post #54
_pmf_ wrote: post #51

Earlier quoted context omitted.

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.

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?

Re: Future of Java 8 Language Feature Support on Android

#89

Post by AnimalMuppet »

pjmlp wrote: post #26
bitmapbrother wrote: post #17

Earlier quoted context omitted.

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.

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.

Re: Future of Java 8 Language Feature Support on Android

#90

Post by pjmlp »

AnimalMuppet wrote: post #89
pjmlp wrote: post #26

Earlier quoted context omitted.

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.

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.
Post reply on HN