7 ms·

> they keep cherry picking standard Java APIs, forcing Java library developers to write two versions of their libraries Can you give some examples of what Andr

> they keep cherry picking standard Java APIs, forcing Java library developers to write two versions of their libraries Can you give some examples of what Android is missing? I know it doesn't implement various packages like awt, swing, javafx, etc., and of course sun.misc.Unsafe. But I wouldn't consider any of that "core Java", and a lot of it doesn't exist in Java ME either. Are there any disparities in "core Java" libraries, like java.util?

pjmlp 8y ago
They don't exist in Java ME, but a large majority does in Embedded Java, depending on which compact profiles are supported. They also existed in SavaJe OS. As for examples, just use the API diff tool and search for java.lang* modifications. https://developer.android.com/sdk/api_diff/<version>/changes https://developer.android.com/sdk/api_diff/<version>/changes Or play around with the API level on the reference docs. To be more concrete: - Locale.Builder, Java 7, introduced in Android 21 - java.lang.invoke package, Java 7, introduced in Android 26 - java.nio.file package, Java 7, introduced in Android 26 So one needs to do API hunting or just target the very latest versions to be on the safe side that an APK won't just blow up on user's device.
- wtallis 8y ago
  > To be more concrete: > - Locale.Builder, Java 7, introduced in Android 21 > - java.lang.invoke package, Java 7, introduced in Android 26 > - java.nio.file package, Java 7, introduced in Android 26 Should the legal status of Android really depend in any way on whether or not it is done? Is there any practical way to define public policy that allows a work-in-progress reimplementation for competitive purposes but prohibits an incomplete reimplementation that you don't intend to flesh out to 100% compatibility?
  - pjmlp 8y ago
    Yes, Google Android J++ should be slammed 100% the same way as Microsoft one was. Google has created a fork in the Java community.
    - wtallis 8y ago
      Can you please try to address the distinction between work in progress vs. not even trying for 100% compatibility? Are you saying that neither should be legal, but a complete and 100% compatible reimplementation should? Or are you saying that reimplementations should not be legal regardless of how complete and compatible they are?
      - pjmlp 8y ago
        I am saying that Google has done exactly the same to the Java community as Microsoft did with J++ and should suffer the same outcome in court as Microsoft did. It was wrong for Microsoft, it is just as wrong for Google. Implement whatever Android specific APIs they feel like, but just like ISO C or ISO C++, don't fork the Java standard library.
        wtallis 8y ago
        > I am saying that Google has done exactly the same to the Java community as Microsoft did with J++ and should suffer the same outcome in court as Microsoft did. As far as I can tell, Sun sued Microsoft for trademark infringement, and Microsoft settled. Which part of that applies to Google? It really seems that you've decided you want Google to lose regardless of the legal basis used by Oracle. Whereas I think Google should win because of the legal basis Oracle is attempting to use. I don't actually care whether Google ends up having to pay Oracle some money; I just don't want the entire legal foundations of the software industry to be retconned by this case.
        pjmlp 8y ago
        Sun sued Microsoft for changes to the Java platform, making it not compliant with the trademark. I want Google to loose because they succeed where Microsoft failed, forking Java eco-system, and having a bunch of people that call Microsoft the evil empire, actually supportive of Google's actions.
    - curt15 8y ago
      But forking has always been a fact of life in software. E.g. MariaDB vs mysql
- monocasa 8y ago
  SavaJe had fundamental battery life issues by using the standard Java process models.
  - pjmlp 8y ago
    Android was also full of battery issues until project Volta and Buttercake. Stealing Sun's revenue apparently did not help.
    - monocasa 8y ago
      SavaJe was much worse, like fundamentally wouldn't last a whole business day.
      - pjmlp 8y ago
        Strangely Gemalto and other Java licensees are doing pretty well with their Embedded Java deployments on the field lasting years between deployments. But lets ignore that because it doesn't suit Google's PR message.
        monocasa 8y ago
        Those are heavily constrained envs that don't even always have a GC or allow 'long'. SavaJe's whole shtick was it allowed full J2SE, and it's full J2SE that's intrinsically a battery hog.
        pjmlp 8y ago
        Embedded Java is also the full J2SE minus GUI. But even if it was the full J2SE, better don't let people understand that implementations get improved, that there are commercial Java vendors with better implementations than Android. Google's PR message would suffer from everyone understanding that improving a platform does not require forking, after all.

pjmlp 8y ago

They don't exist in Java ME, but a large majority does in Embedded Java, depending on which compact profiles are supported. They also existed in SavaJe OS. As for examples, just use the API diff tool and search for java.lang* modifications. https://developer.android.com/sdk/api_diff/<version>/changes https://developer.android.com/sdk/api_diff/<version>/changes Or play around with the API level on the reference docs. To be more concrete: - Locale.Builder, Java 7, introduced in Android 21 - java.lang.invoke package, Java 7, introduced in Android 26 - java.nio.file package, Java 7, introduced in Android 26 So one needs to do API hunting or just target the very latest versions to be on the safe side that an APK won't just blow up on user's device.

wtallis 8y ago
> To be more concrete: > - Locale.Builder, Java 7, introduced in Android 21 > - java.lang.invoke package, Java 7, introduced in Android 26 > - java.nio.file package, Java 7, introduced in Android 26 Should the legal status of Android really depend in any way on whether or not it is done? Is there any practical way to define public policy that allows a work-in-progress reimplementation for competitive purposes but prohibits an incomplete reimplementation that you don't intend to flesh out to 100% compatibility?
- pjmlp 8y ago
  Yes, Google Android J++ should be slammed 100% the same way as Microsoft one was. Google has created a fork in the Java community.
  - wtallis 8y ago
    Can you please try to address the distinction between work in progress vs. not even trying for 100% compatibility? Are you saying that neither should be legal, but a complete and 100% compatible reimplementation should? Or are you saying that reimplementations should not be legal regardless of how complete and compatible they are?
    - pjmlp 8y ago
      I am saying that Google has done exactly the same to the Java community as Microsoft did with J++ and should suffer the same outcome in court as Microsoft did. It was wrong for Microsoft, it is just as wrong for Google. Implement whatever Android specific APIs they feel like, but just like ISO C or ISO C++, don't fork the Java standard library.
      - wtallis 8y ago
        > I am saying that Google has done exactly the same to the Java community as Microsoft did with J++ and should suffer the same outcome in court as Microsoft did. As far as I can tell, Sun sued Microsoft for trademark infringement, and Microsoft settled. Which part of that applies to Google? It really seems that you've decided you want Google to lose regardless of the legal basis used by Oracle. Whereas I think Google should win because of the legal basis Oracle is attempting to use. I don't actually care whether Google ends up having to pay Oracle some money; I just don't want the entire legal foundations of the software industry to be retconned by this case.
        pjmlp 8y ago
        Sun sued Microsoft for changes to the Java platform, making it not compliant with the trademark. I want Google to loose because they succeed where Microsoft failed, forking Java eco-system, and having a bunch of people that call Microsoft the evil empire, actually supportive of Google's actions.
  - curt15 8y ago
    But forking has always been a fact of life in software. E.g. MariaDB vs mysql
monocasa 8y ago
SavaJe had fundamental battery life issues by using the standard Java process models.
- pjmlp 8y ago
  Android was also full of battery issues until project Volta and Buttercake. Stealing Sun's revenue apparently did not help.
  - monocasa 8y ago
    SavaJe was much worse, like fundamentally wouldn't last a whole business day.
    - pjmlp 8y ago
      Strangely Gemalto and other Java licensees are doing pretty well with their Embedded Java deployments on the field lasting years between deployments. But lets ignore that because it doesn't suit Google's PR message.
      - monocasa 8y ago
        Those are heavily constrained envs that don't even always have a GC or allow 'long'. SavaJe's whole shtick was it allowed full J2SE, and it's full J2SE that's intrinsically a battery hog.
        pjmlp 8y ago
        Embedded Java is also the full J2SE minus GUI. But even if it was the full J2SE, better don't let people understand that implementations get improved, that there are commercial Java vendors with better implementations than Android. Google's PR message would suffer from everyone understanding that improving a platform does not require forking, after all.