Hacker News new | past | comments | ask | show | jobs | submit login

When Google will completely deprecate Java for Go on Android (could be a number of years, if ever), then Java should imminently become irrelevant (over a number of years, maybe a decade, or maybe it will never disappear completely, but the point is it will rapidly decline with new and existing developers).



Given Android's core team statements at Google IO 2014 about Java being the only official language, with no plans to improve the NDK beyond the existing support, I find it very hard to ever happen.

Unless Management forces the team to change their mind, that is.


> no plans to improve the NDK beyond the existing support

:| really? Got a link to that?

I really thought that they'd finally gotten over themselves and realized that lots of people want and use the NDK.


Yes,

https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566

- Java is the official language, that is what the team has invested into

- You can use the NDK for your favorite language, but beware that you are required to use JNI anyway for Android APIs

- Not possible to do any comment regarding Java 8 support.

- Only use Scala for business logic, no tooling support plans


I really hope Google deprecates Java on Android, because Android is even having problems with the standard library in Java SE 6, let alone Java 7 or 8. I rooted for them in the Oracle lawsuit, but they are holding back progress on the Java platform, as now library authors have to worry about the "Android problem" - every other JVM vendor is able to keep up the pace of updates, but not Google, because hey, ART / Dalvik is not a JVM, haven't you heard? So they should either get their shit together and keep up with the latest standard library, class format and bytecode in their toolchain or drop it.


I don't see any reason why Java usage would rapidly decline. The only thing that's likely to replace Java is Java 8, since everyone wants lambdas and there's a clear upgrade path. Even that's a big change and migration will take a while on Android.

It's unclear what the big missing feature is after lambdas. I think there will be little incentive for further change, so large companies will keep on running it.


> It's unclear what the big missing feature is after lambdas.

- Value types, GPGPU, replacing JNI with an improved JNR, reified generics, making Unsafe an official package, modularity, AOT compilation, replacing Hotspot by Graal...

Some things discussed here,

http://www.oracle.com/technetwork/java/javase/community/jlss...

http://openjdk.java.net/projects/panama/

http://openjdk.java.net/projects/sumatra/

http://openjdk.java.net/projects/valhalla/

https://wiki.openjdk.java.net/display/Graal/Publications+and...


Yes, there are many more features to come, but they don't look like they will be as important as lambdas (and default methods) for everyday coding.

Thanks for the links.


I think you underestimate you important some of those are.

Specially for people doing big data analysis in JVM languages or jumping out of Java to languages like C and C++ for the last performance increase.


The Java community is so large that these are important communities in themselves. But they're still subsets. Someone writing a portable Java library isn't going to want to call into native code or rely on specific hardware. Changing the language itself affects everyone.


If you bothered to follow the links, they imply language changes.


I did, actually. Value types are nice but annotation processing can do pretty well:

https://github.com/google/auto/tree/master/value

I'm honestly not seeing as big as lambdas (or generics in Java 5). If you think they really are that big, perhaps you could explain why?


> It's unclear what the big missing feature is after lambdas.

I agree. I think Java pretty much is what it is by now. As someone said, "For those who like this kind of thing, this is the kind of thing they like."

Java-the-language is pretty complete. (Even though Haskell people complain about the lack of a decent type system, and Lisp users complain about the verbose syntax, and C++ folks wish they had destructors.) Java-the-platform is in fine shape (the library is Java's unsung best selling point.)

Java-the-enterprise-bloatware-behemoth... well, it really needs to be shot in the head and the body incinerated, but it may actually do the jobs it's given to do about as well as anything that might replace it.


In terms of language features, lack of properties are the thing that is keeping me from using java. I would love to be able to have public variables, with the understanding that I could just convert them to properties later on if I need to. Instead, java conventions suggest that I always make a getter and setter for every single variable that I want to expose.


Some Java conventions are unfortunate. Setters aren't a great idea, actually. The Guava team recently open-sourced AutoValue as a more modern approach:

https://github.com/google/auto/tree/master/value


Fixing this stupid issue seems like such an obvious thing to do I can't imagine why it wasn't addressed ages ago. Having property notation would immediately get rid of 30% of the code in the codebase I currently work with, and that seems incredibly valuable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: