I came across this statement on Dagger's documentation at [http://google.github.io/dagger/android.html]. Also there is a discussion on reddit [https://reddit.com/r/androiddev/comments/4smncj/is_this_true/] but it does not cover much.
Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
1–8 of 8 posts
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#2Simple answer: because Android is not Java. It's a compeletely different platform, that just happens to use a programming language similar to Java to write programs for it's virtual machine.
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#3Simple answer: because Android is not Java. It's a compeletely different platform, that just happens to use a programming language similar to Java to write programs for it's virtual machine.
It's java, but it has a different standard library and different api.
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#4I would say most of it IS appropriate. A lot of the advice is good for Java development in general, regardless of platform. Enums are one area that is hotly debated in the Android community, but there is no consensus on it.
Generally, I would say follow the advice in Effective Java, but be aware of some potential performance issues and how you can avoid/fix them if need be.
Edit: I noticed there is a chapter on serialization. This can be ignored by Android developers in favor of Parcelable.
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#5Android uses Dalvik/ART, which is an alternative to the JVM that has an entirely different set of optimizations for mobile. The most important one is that object creation is significantly more expensive -- if your code is allocating lots of objects it will significantly impact performance. This is why Android has the whole Recycler paradigm. My gut reaction is that Effective Java recommends a lot of heavy-OO practices which may impact Android performance.
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#6Simple answer: because Android is not Java. It's a compeletely different platform, that just happens to use a programming language similar to Java to write programs for it's virtual machine.
It is de-facto Java.
It uses java syntax, java libraries.
To say it is 'not Java' is borderline disingenuous.
Technically, there are differences which are real, and it's very fair to point them out.
But - Java syntax + java.lang/java.io/java.net/java.reflect/java.util + a vm, can use a JAVA IDE and java build chain, use 3rd party java libs ...
=> it's java.
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#7Simple answer: because Android is not Java. It's a compeletely different platform, that just happens to use a programming language similar to Java to write programs for it's virtual machine.
It is de-facto Java. It uses java syntax, java libraries. To say it is 'not Java' is borderline disingenuous. Technically, there are differences which are real, and it's very fair to point them out. But - Java syntax + java.lang/java.io/java.net/java.reflect/java.util + a vm, can use a JAVA IDE and java build chain, use 3rd party java libs ... => it's java.
I don't think this analogy is accurate.
It uses Java as the development language, but it has different runtime, not simply a different platform / target, and thus different rules apply.
In regards with the Java libraries, I think this is pretty much already covered in the Google vs Oracle case. Android provides a system implementation that matches the interface, thus these code can work almost seamlessly. Similar to how .NET and Mono works.
Re: Ask HN: Why is “advice in Effective Java considered inappropriate for Android”?
#8Earlier quoted context omitted.
It is de-facto Java. It uses java syntax, java libraries. To say it is 'not Java' is borderline disingenuous. Technically, there are differences which are real, and it's very fair to point them out. But - Java syntax + java.lang/java.io/java.net/java.reflect/java.util + a vm, can use a JAVA IDE and java build chain, use 3rd party java libs ... => it's java.
I don't think this analogy is accurate. It uses Java as the development language, but it has different runtime, not simply a different platform / target, and thus different rules apply. In regards with the Java libraries, I think this is pretty much already covered in the Google vs Oracle case. Android provides a system implementation that matches the interface, thus these code can work almost seamlessly. Similar to…
The Google case showed that they had the right to implement the interface - legally, but that doesn't mean it's not Java.
Syntax = Java Standard Libs = Java 3rd Party Libs = Java Fully interoperable with Java Java IDE's Java Toolchain
= It's Java.
There can hardly be a pragmatic argument against this.
The Google case is a weird one that ultimately involved the nature of APIs and if they can be copyrighted, but by any reasonable definition ... it's Java.
Note that they don't give it 'another name' - so what programming language do you use for Android?
Ask 1000 developers and they will say 'Java'.
They won't say 'something that is exactly like Java, but not actually Java, and which has no name'.
If they deviated the syntax, used a totally different set of core libs, wasn't interoperable with other JVM's and libs ... then I think we could say 'it's not java'.