
Ask HN: Why is “advice in Effective Java considered inappropriate for Android”? - amolgupta
I came across this statement on Dagger&#x27;s documentation at [http:&#x2F;&#x2F;google.github.io&#x2F;dagger&#x2F;android.html]. Also there is a discussion on reddit [https:&#x2F;&#x2F;reddit.com&#x2F;r&#x2F;androiddev&#x2F;comments&#x2F;4smncj&#x2F;is_this_true&#x2F;] but it does not cover much.
======
ng12
Android 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.

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

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

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

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

~~~
edblarney
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'.

