5 ms·

Wine makes programs written for Windows work on Linux. The key difference is that Linux is an independently developed system. The extent that wine copies Wind

by treis 6y ago

Wine makes programs written for Windows work on Linux. The key difference is that Linux is an independently developed system. The extent that wine copies Windows code is limited to a compatability layer. It doesn't transform Linux into just a copy of Windows. In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.

jayd16 6y ago
Didn't they though? They've had their own vm and bytecode for as long as Android has been released. The use of Java is for making libraries compatible.
- treis 6y ago
  They did have their own vm and byte code but not a programming language.
  - jayd16 6y ago
    Is bytecode not a language?
    - tmccrary55 6y ago
      Yeah, so mov or iload instructions would be protected copyright if Oracle wins.
    - treis 6y ago
      I would say no but either way it's not what Google copied.
CobrastanJorji 6y ago
If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay? How would such a programming language be detectably different from being an implementation of Java?
- treis 6y ago
  >If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay? Yes >How would such a programming language be detectably different from being an implementation of Java? It would have it's own unique API. As an example, Ruby can run on the JVM via JRuby and it's clear that Ruby is a different language than Java.
  - ClumsyPilot 6y ago
    This doesnt make sence - you jyst replaced the textual API used at compiletime with a binary API used at runtime. Its literally same difference.
    - treis 6y ago
      They're clearly different. In this example Google independently developed a language and made it compatible with the JVM. In the real world Google wanted Java and didn't like the licensing terms. So they copied the Java API and from that starting point built out their own version of Java.
      - CobrastanJorji 6y ago
        But "making it compatible with the JVM" would involve implementing the Java standard library, right? Recognizing terms like "java.lang.String" or "java.lang.Math.max" and doing the right thing? To do that, aren't you creating a copy of the Java API?
        treis 6y ago
        Nobody is arguing that you can't copy the API if it's fair use. Copying the API in order to make a copy of the software isn't fair use.
Wowfunhappy 6y ago
But one of the reasons Android chose Java was for compatibility with existing Java software. It was code rather than binary compatibility, but I'm not convinced that's a meaningful distinction. I mean, a programming language is fundamentally a set of instructions that produces output, right? So, a Java programmer writes `System.out.print("Hello")` and the Java implementation does the work to make "Hello" appear on screen. Similarly, a Windows executable running via Wine will tell the Windows API to print "Hello", and Wine will do the work to make that message appear on the screen.
nl 6y ago
> In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java. This isn't an argument that has been made in court in anyway, and Google's use of the Java language hasn't been questioned. Google could have used the Java language with completely different APIs (google.lang instead of java.lang for example). It's the APIs that this case is about. Also, the key analogy is wrong anyway: while Android used java.lang and java.util and other related APIs, the key functionality of the phone was accessible via custom APIs that aren't copied. Note that the "interoperability" argument was lost by Google because of this exact thing.
- monocasa 6y ago
  > Google could have used the Java language with completely different APIs Well, no, because many Java language constructs are defined in context to the standard library, for instance all classes being children of java.lang.Object. They'd need quite a bit of java.lang at the very least.
  - pjmlp 6y ago
    Which even after their adoption of OpenJDK still isn't compatible out of the box with the standard library available at https://adoptopenjdk.net/ https://adoptopenjdk.net/ In 2020 it is still pretty much hint and miss getting a Java library working without changes on Android, given that the Android team cherry picks whatever they feel like from OpenJDK for their own Android API implementation purposes. Easily to find that out from Gerrit commits and AOSP source code. Meanwhile, effort has been spent ensuring that 100% of ISO C and ISO C++ are available on Android NDK. Thus out of the window goes the interoperability argument.
    - monocasa 6y ago
      Nothing happens to the interoperability argument. Nothing says it need to be 100% interoperable, or else you wouldn't be able to ship an MVP for any reimplementation of an API. And hell, the official JDK isn't even 100% interoperable with it's past selves. Maybe if Sun didn't play games with access to the TCK in the past we wouldn't be here adn there'd be a valid test for compliance that wasn't "do what the official JDK does".

by treis 6y ago

jayd16 6y ago

Didn't they though? They've had their own vm and bytecode for as long as Android has been released. The use of Java is for making libraries compatible.

treis 6y ago
They did have their own vm and byte code but not a programming language.
- jayd16 6y ago
  Is bytecode not a language?
  - tmccrary55 6y ago
    Yeah, so mov or iload instructions would be protected copyright if Oracle wins.
  - treis 6y ago
    I would say no but either way it's not what Google copied.

CobrastanJorji 6y ago

If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay? How would such a programming language be detectably different from being an implementation of Java?

treis 6y ago
>If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay? Yes >How would such a programming language be detectably different from being an implementation of Java? It would have it's own unique API. As an example, Ruby can run on the JVM via JRuby and it's clear that Ruby is a different language than Java.
- ClumsyPilot 6y ago
  This doesnt make sence - you jyst replaced the textual API used at compiletime with a binary API used at runtime. Its literally same difference.
  - treis 6y ago
    They're clearly different. In this example Google independently developed a language and made it compatible with the JVM. In the real world Google wanted Java and didn't like the licensing terms. So they copied the Java API and from that starting point built out their own version of Java.
    - CobrastanJorji 6y ago
      But "making it compatible with the JVM" would involve implementing the Java standard library, right? Recognizing terms like "java.lang.String" or "java.lang.Math.max" and doing the right thing? To do that, aren't you creating a copy of the Java API?
      - treis 6y ago
        Nobody is arguing that you can't copy the API if it's fair use. Copying the API in order to make a copy of the software isn't fair use.

Wowfunhappy 6y ago

But one of the reasons Android chose Java was for compatibility with existing Java software. It was code rather than binary compatibility, but I'm not convinced that's a meaningful distinction. I mean, a programming language is fundamentally a set of instructions that produces output, right? So, a Java programmer writes `System.out.print("Hello")` and the Java implementation does the work to make "Hello" appear on screen. Similarly, a Windows executable running via Wine will tell the Windows API to print "Hello", and Wine will do the work to make that message appear on the screen.

nl 6y ago

> In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java. This isn't an argument that has been made in court in anyway, and Google's use of the Java language hasn't been questioned. Google could have used the Java language with completely different APIs (google.lang instead of java.lang for example). It's the APIs that this case is about. Also, the key analogy is wrong anyway: while Android used java.lang and java.util and other related APIs, the key functionality of the phone was accessible via custom APIs that aren't copied. Note that the "interoperability" argument was lost by Google because of this exact thing.

monocasa 6y ago
> Google could have used the Java language with completely different APIs Well, no, because many Java language constructs are defined in context to the standard library, for instance all classes being children of java.lang.Object. They'd need quite a bit of java.lang at the very least.
- pjmlp 6y ago
  Which even after their adoption of OpenJDK still isn't compatible out of the box with the standard library available at https://adoptopenjdk.net/ https://adoptopenjdk.net/ In 2020 it is still pretty much hint and miss getting a Java library working without changes on Android, given that the Android team cherry picks whatever they feel like from OpenJDK for their own Android API implementation purposes. Easily to find that out from Gerrit commits and AOSP source code. Meanwhile, effort has been spent ensuring that 100% of ISO C and ISO C++ are available on Android NDK. Thus out of the window goes the interoperability argument.
  - monocasa 6y ago
    Nothing happens to the interoperability argument. Nothing says it need to be 100% interoperable, or else you wouldn't be able to ship an MVP for any reimplementation of an API. And hell, the official JDK isn't even 100% interoperable with it's past selves. Maybe if Sun didn't play games with access to the TCK in the past we wouldn't be here adn there'd be a valid test for compliance that wasn't "do what the official JDK does".