3 ms·

"None of binder is in Java" is too strong a statement: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Parcel.java https

"None of binder is in Java" is too strong a statement: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Parcel.java https://android.googlesource.com/platform/frameworks/base/+/... This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/tests/binderRpcTest.cpp https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs. Even the use of C++ is likely to frown many people. (Not me).

charcircuit 10mo ago
That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both. https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/include/binder/Parcel.h https://cs.android.com/android/platform/superproject/main/+/...
- AshamedCaptain 10mo ago
  No, it is not. It is the Java class which has native methods that call into the C++ version, as someone said above. But it is still primarily a Java class.
  - kllrnohj 10mo ago
    dbus-java exists, does that magically turn dbus into being primarily implemented in Java? No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
    - AshamedCaptain 10mo ago
      > dbus-java exists, does that magically turn dbus into being primarily implemented in Java? it does if the only other implementation is basically the JNI native methods of dbus-java. This is what libbinder_ndk looks like from the outside. If there's a newer libbinder that does not look like a Java mess , I have not yet seen it. Not negating that it may exist; the libbinder you quoted above looks similar to openbinder but I have never used it.
p_l 10mo ago
The C++ origin of Binder is annoying, but unlike original Binder[1] easily workable around especially given the exact format of messages is left up for implementation to decide outside few standard bits [1] BeOS, the docs still match what is in Android :D
- AshamedCaptain 10mo ago
  Not entirely , you need to agree on some constraints for wire protocol since the kernel ends up doing reference counting on objects sent through it.
  - p_l 10mo ago
    That was in the "few standard bits", yes.

charcircuit 10mo ago

That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both. https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/include/binder/Parcel.h https://cs.android.com/android/platform/superproject/main/+/...

AshamedCaptain 10mo ago
No, it is not. It is the Java class which has native methods that call into the C++ version, as someone said above. But it is still primarily a Java class.
- kllrnohj 10mo ago
  dbus-java exists, does that magically turn dbus into being primarily implemented in Java? No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
  - AshamedCaptain 10mo ago
    > dbus-java exists, does that magically turn dbus into being primarily implemented in Java? it does if the only other implementation is basically the JNI native methods of dbus-java. This is what libbinder_ndk looks like from the outside. If there's a newer libbinder that does not look like a Java mess , I have not yet seen it. Not negating that it may exist; the libbinder you quoted above looks similar to openbinder but I have never used it.

p_l 10mo ago

The C++ origin of Binder is annoying, but unlike original Binder[1] easily workable around especially given the exact format of messages is left up for implementation to decide outside few standard bits [1] BeOS, the docs still match what is in Android :D

AshamedCaptain 10mo ago
Not entirely , you need to agree on some constraints for wire protocol since the kernel ends up doing reference counting on objects sent through it.
- p_l 10mo ago
  That was in the "few standard bits", yes.