Pyjnius: PyJnius 대 JPype

문의해 주셔서 감사합니다.

몇 년 동안 jpype를 보지 않았기 때문에 잘못 기억할 수 있지만 공유 메모리가 아닌 서버(IPC)를 통해 JVM과 이야기하는 다른 접근 방식을 사용하고 있었지만 readme는 반대를 암시합니다. 그리고 나는 코드를 한 눈에 봐도 그것을 반증하는 힌트를 볼 수 없기 때문에 아마도 완전히 틀렸을 것입니다. 그리고 이 접근 방식은 예를 들어 안드로이드에서 작동하지 않게 만들었습니다. 어떤 사람들은 데스크탑 플랫폼에서 그것을 사용합니다). 반면에, jni.h가 AOSP에서 가져온 것 같기 때문에 native 디렉토리에 관한 것이 아니라면 JPype 코드베이스에서 Android 지원에 대한 힌트를 많이 볼 수 없습니다.

하지만 솔직히 말해서, 우리는 프로젝트가 시작되었을 때 JPype를 전혀 인식하지 못했습니다. kivy 지원을 위해 특정 안드로이드 클래스에 인터페이스하기 위해 수동으로 jni 코드를 코딩해야 하는 것에서 한 단계 더 올라간 것입니다. 나는 @tito 가 나중에 우리가 그것에 대해 알게 되었을 때 비교하기 위해 약간의 파고를 했다고 생각하지만 그가 전환을 시도하지 말아야 할 구체적인 이유를 보았는지 기억이 나지 않습니다.

안녕하세요. JPype 이름은 기억나는데, 뭘 쓸 수 있는지 검색할 당시 솔직히 8년 전만 해도 왜 전혀 사용하지 않았는지 기억이 안 나네요 :) 처음의 유일한 목표는 Android와 통신할 수 있는 것이었습니다. API를 사용하지만 중간 RPC 서버를 P4A 프로젝트로 사용하지 않는 것은 그 당시 하고 있었습니다.

저는 약 2년 전에 모든 Java 브리지 코드에 접근했습니다. 불행히도, PyJnius 코드는 내 검색에 결코 나타나지 않았기 때문에 분명히 놓쳤습니다. 지난번에 멋진 기술 보도 자료를 제공한 페이지를 검색하다가 두 프로젝트에 대해 논의하는 블로그를 우연히 발견한 것을 제외하고는 이번 라운드에서도 놓쳤을 것입니다. 2년 동안 같은 분야에서 진행 중인 다른 프로젝트를 어떻게 놓쳤는지 잘 모르겠지만 분명히 내 잘못이었습니다.

JPype가 다른 주요 브리지 코드인 Py4J와 혼동되는 것처럼 들립니다. 그들은 수반되는 이점과 단점을 모두 가진 소켓을 사용하여 모든 것을 수행합니다. 마찬가지로 프로젝트가 내 요구 사항을 충족하지 않는다는 것을 알았습니다.

나는 안드로이드를 지원하는 데 필요한 것에 대한 연구를 하지 않았습니다. 비록 내가 가능한 것보다 약간의 기술 사양이 있다면. 네이티브 JNI와 Python의 C API에 대한 일반 이전 호출 외에는 우리가 하고 있는 작업이 없습니다.

접근 방식에 관한 한 JPype는 "startJVM()" 명령을 사용하여 JVM을 Python과 결합하기 위해 독점적으로 JNI를 사용합니다. 다음 버전(2.0)도 Java 내에서 Python을 시작할 수 있는 반대의 기능을 제공할 것입니다. 레이어 접근 방식을 통해 이 작업을 수행합니다. 프론트 엔드 역할을 하는 모든 고급 클래스를 보유하는 Python 계층, 진입점을 보유하는 기본 클래스가 있는 CPython 개인 모듈, 모든 유형 변환 및 일치를 처리하고 기본 모듈로 작동하는 C++ 지원 계층이 있습니다. Java 라이브러리 및 모든 유틸리티 작업(객체 수명 유지, 슬라이스 및 예외에 대한 지원 클래스 생성, javadoc 추출기/렌더링)을 수행하는 Java 라이브러리.

8년 전 JPype는 약간 엉망이었습니다. Ruby와 Python을 모두 지원하려고 했기 때문에 C++ 레이어는 작업할 래퍼가 얽혀 있고 프런트 엔드는 모두 Python으로 되어 있어서 매우 느렸습니다. 또한 numpy 지원이 컴파일되어 다른 객체가 반환될 수 있으므로 반환 유형에서 분기되었습니다. 네이티브 Python과 Java 객체가 다른 프록시 역할을 하려면 JException과 같은 많은 어댑터 클래스가 필요했습니다. 하지만 프로젝트에 합류한 지 3년 만에 모든 문제가 해결되었습니다. JPype의 두 가지 주요 목표(저를 위해)는 물리학자들이 프로그래밍에 익숙하여 Java를 사용할 수 있고 과학적인 Python 코드와 높은 수준의 통합을 가질 수 있을 만큼 충분히 간단한 구문을 제공하는 것입니다. 우리는 자바가 지원하는 객체가 "모든 장식" CPython 객체 래퍼를 갖도록 함으로써 이를 수행합니다. Java 원시 배열을 변환하는 대신 Java 원시 배열을 numpy와 동일한 진입점을 모두 구현하는 새로운 원시 Python 유형으로 만들고 이 모든 것이 메모리 버퍼 전송으로 지원됩니다. 따라서 list(jarray) 또는 np.array(jarray) 를 호출하여 빠른 변환이 가능합니다.

Android에 적용하려면 시작 시퀀스를 다시 작업해야 하며 내부 라이브러리를 로드하는 데 사용하는 썽크 코드를 보다 전통적인 JNI 모델로 교체해야 합니다. 다음 버전에서 이미 썽크 코드를 제거했으므로 이후 버전은 이미 충족되었습니다. 전자만 필요합니다.

내가 볼 수있는 접근 방식의 주요 차이점은 PyJnius가 배열을 오가는 배열을 변환한다는 것입니다. 이것은 큰 배열(종종 변환되지 않음)을 뒤로 전달하는 것이 선호되는 JPype 스타일인 과학적 코딩에 매우 금지된 것으로 보입니다. 변환을 요구하기로 결정하면 값에 의한 전달 및 참조에 의한 전달과 같은 옵션이 강제 적용되지만, 이는 다중 인수 호출이 있는 것처럼 모든 인수에 대해 하나의 정책을 선택하는 것처럼 잠재적으로 더 큰 문제로 이어집니다. 또한 다차원 배열을 다루기 어렵게 만듭니다. ( obj.method(1, jnius.byref(list1), list2) 와 같이 사용되는 어댑터 클래스가 달성될 수 있다면 더 나은 제어를 제공했을 것이라고 생각합니다.) 이 외에도 GC 연결, 호출자에 민감한 메서드 등 JPype가 해결한 문제가 많습니다. 다른 것이 없다면 JPype 코드를 살펴보고 사용할 수 있는 좋은 아이디어가 있는지 확인하십시오.

@Thrameos 최근 병합하려고 하는 것은 Java Functional 인터페이스에 Python 람다를 사용하는 것입니다. https://github.com/kivy/pyjnius/pull/515 참조 ; 나는 JPype에서 그것을 보지 못했다?

JPype는 1.0.0부터 기능 인터페이스의 람다를 지원합니다. 이는 3월 30일 1.0으로의 푸시 30개 중 일부였습니다.

JPype는 오랜 잠복기를 가지고 있습니다. 원래 2004년에 시작되어 2007년까지 실행되었습니다. 그 후 사용자 그룹이 2015년경 Python 3으로 이식하기 위해 부활시켰기 때문에 큰 힘을 얻었습니다. 그런 다음 2017년에 국립 연구소에서 사용하기 위해 선택되어 0.6에서 사용되었습니다. 3 ~ 0.7.2. 그 기간 동안 인터페이스를 제공하는 핵심 기술을 개선하고 강화하는 데 모든 노력이 집중되었습니다. 그러나 두 번째 핵심 재작성 후 3월에 마침내 완료되어 마침내 1.0.0을 푸시할 수 있었습니다. 그 이후로 우리는 "30일 밤에 30개 뽑기" 위시리스트 캠페인에서 "누락된" 모든 것을 추가해 왔습니다. 너무 많은 작업으로 인해 구현할 수 없었던 모든 백로그가 마침내 해결되었습니다(문제가 50개에서 20개로 감소하고 사용자에게 무엇이 필요한지 묻는 등). 따라서 현재 사용 가능한 이전 버전에서는 찾을 수 없었던 여러 기능이 있을 수 있습니다. 저는 대부분의 기능 요청을 1주일도 채 안 되어 처리했고 나머지 3가지(역 브리지, Python의 클래스 확장, 두 번째 JVM을 시작하는 기능)만 남게 되었습니다.

Java가 Python을 호출하고 Java 기본 라이브러리로 사용할 수 있도록 Python 라이브러리에 대한 스텁을 생성할 수 있도록 하는 리버스 브리지 코드를 완료하기 위한 6개월의 긴 노력 중 2개월이 걸리기 때문에 프로젝트는 다시 잠이 들 것입니다. Python에 대한 기본 지원을 달성할 수 있도록 ASM을 사용하여 즉석에서 Java 클래스를 빌드합니다. 여전히 Jython처럼 완전히 통합되지는 않았지만 큰 차이가 없을 정도로 충분히 가깝습니다.

자세한 설명에 감사드립니다. 실제로 우리가 사용할 수 있는 아이디어가 있다면 코드를 공부할 가치가 있을 것입니다. 앞서 코드를 살펴보면 코드 품질과 구조 모두에서 내가 본 것이 매우 깨끗해 보입니다. 모든 작업을 축하합니다. 당신은 Py4J와의 혼합에 대해 옳았습니다. 제 생각에 JPype를 보았을 때 당신이 설명하는 지저분한 상태에 있어야 하고 그것을 사용하는 것이 이 시점에서 PyJNIus보다 훨씬 더 복잡했을 것입니다.

값/변환에 의한 전달에 대한 귀하의 요점은 매우 사실이며 @hx2A 가 성능을 개선하는 방법을 조사하고 파이썬 유형으로 다시 변환을 선택 사항으로 만들었기 때문에 여기에서도 최근 토론을 촉발했습니다. 자바 목록으로 변환되고, 자바에 의해 수정되고, 파이썬으로 다시 변환되어 가비지 수집을 위해 확실히 차선책이었습니다. 이제 키워드 인수를 사용하는 비용으로 두 번째 부분을 피할 수 있습니다. 자바는 그것들을 지원하지 않기 때문에 서명 충돌은 없지만 확실히 문법적으로 좀 더 시끄럽습니다).

JPype와 PyJNIus의 가능한 차이점에 관해서는 Python 클래스를 사용하여 Java 인터페이스를 구현하고 이를 Java에 전달하여 콜백으로 사용할 수 있습니다. 반면에 Java 클래스를 확장하려면 Java 바이트코드를 생성해야 합니다. 파이썬에서, 그것은 우리가 지금 다룰 수 없는 일부 안드로이드 API를 사용해야 하는 요구 사항이기 때문에 귀하의 의견에서 올바르게 추론했는지 확실하지 않지만 아마도 Java 클래스가 귀하를 호출하도록 할 수 있는 능력이 없을 수도 있습니다. 이와 같은 파이썬 코드(인터페이스 사용).

JPype는 Python에서 인터페이스를 구현할 수 있습니다. 일반 Python 클래스에 데코레이터를 추가하기만 하면 됩니다.

from java.util.function import Consumer

@jpype.JImplements(Consumer)
class MyConsumer:
   @jpype.JOverride
   def apply(self, obj):
       pass

JVM이 시작되기 전에 클래스가 정의된 경우 @JImplements 에서 문자열을 사용합니다. 여러 인터페이스를 한 번에 구현할 수 있지만 모든 메소드가 구현되었는지 확인하기 위해 확인합니다. 주요 차이점은 JPype는 오버로드된 메서드가 아닌 디스패치 메서드(모든 오버로드는 동일한 메서드로 이동)를 사용한다는 것입니다. 이는 Java와 Python 모두에서 메서드를 호출할 수 있기를 원하기 때문입니다. 원하는 기능인 경우 개별 오버로드를 추가할 수 있지만 아무도 요청하지 않았습니다.

(편집: 우리가 Python 상속을 사용하지 않은 이유는 이것이 추가되었을 때 많은 메타 클래스 문제를 일으킨 Python 2를 여전히 지원하고 있었기 때문입니다. 클래스 확장이 배치되면 더 정리할 것입니다. 따라서 주석은 선언 시간에 한 번 평가하는 것이 더 깨끗했습니다.)

우리는 동일한 시스템을 사용하여 클래스에 대한 커스터마이저(dunder?)를 구현합니다.

@jpype.JImplementationFor("java.util.ArrayList")
class ArrayListImpl:
    def __getitem__(self, i):
        return self.get(i)
    @jpype.JOverride
    def addAll(self, list):
        # Decide if we need to convert or can call directly.
        ...

또한 주석을 사용하여 "모든 Python 경로 개체가 java.io.File로 변환됨"과 같은 암시적 변환기를 정의합니다.

 @jpype.JConversion("java.io.File", instanceof=pathlib.PurePath)
 def _JFileConvert(jcls, obj):
       Paths = jpype.JClass("java.nio.file.Paths")
       return Paths.get(str(obj))

분명히 이러한 종류의 논리를 사용하는 것은 특수 C 방법보다 약간 느리지만 가독성과 유연성을 높게 유지합니다. 저는 병목 현상이 입증된 중요한 경로를 필요에 따라 C로 되돌려 놓았습니다.

우리는 또한 깔끔하게 만들기 위한 몇 가지 구문 설탕을 제공합니다. MyJavaClass@obj => MyJavaClass로 캐스트(Java에 상응하는 (MyJavaClass)obj ) 또는 cls=JInt[:] => 배열 유형 생성( cls=int[].class ) 또는 a=JDouble[10][5] => multidim 배열을 만듭니다( double[][] a = new double[10][5] ).

저는 JPype에서 클래스를 확장하기 위한 프로토타입 작업을 해왔습니다. 일부 Swing 클래스 및 기타 API에서 클래스 확장이 필요한 것과 동일한 문제가 있습니다. 지금까지 내가 만든 솔루션은 재정의된 각 메서드에 대해 HashMap이 있는 확장 클래스를 만드는 것입니다. 해당 진입점에 대한 해시맵에 아무 것도 없으면 이를 super에 전달하고, 그렇지 않으면 프록시 메소드 핸들러를 호출합니다. 그러나 나는 이것이 역 브리지가 완료된 후에 구현하는 것이 가장 쉬울 것이라고 판단하여 Java가 실제로 Java 프록시 메소드를 거치지 않고 Python 메소드를 처리할 수 있도록 합니다. 그래서 프로토타입이 작동하기까지 약 6개월이 남았습니다. epypj 분기(역 브리지의 경우 내 이름)를 보면 Java에서 Python으로 다시 호출이 작동하는 방식과 ASM을 사용하여 즉석에서 Java 클래스를 만드는 호출자를 생성하는 패턴을 볼 수 있습니다.

가비지 수집을 관리하는 것과 관련하여 해당 작업을 수행하는 JPype는 거의 없습니다. 먼저 Python 객체의 수명을 Java 객체에 바인딩하는 JPypeReferenceQueue(native/java/org/jpype/ref/JPypeReferenceQueue)가 있습니다. 이것은 Java가 일정 기간 동안 Python 개념에 액세스해야 하는 버퍼 및 기타 항목을 만드는 데 사용됩니다. 두 번째는 전역 참조를 사용하여 Python이 범위 내에서 Java 객체를 보유할 수 있도록 하는 것입니다. 이를 위해서는 특정 조건(풀 크기, 상대적 증가)이 있을 때 시스템 중 하나가 GC를 트리거하고 이를 다른 시스템에 ping하는 가비지 수집기 링크(native/common/jp_gc.cpp)가 필요합니다. 마지막 프록시는 약한 참조를 사용해야 합니다. 그렇지 않으면 루프를 형성할 수 있기 때문입니다(프록시는 Java 절반에 대한 참조를 보유하고 Java 절반은 Python 구현을 다시 가리킴). 결국 저는 Python이 Java를 트래버스할 수 있도록 에이전트를 사용하려고 하지만 이는 곧 갈 길입니다.

저는 안드로이드가 아닌 데스크탑에서 pyjnius를 사용하는 사람들 중 한 명입니다. 프로젝트 구축을 시작할 때 JPype에 대해 몰랐지만 차이점이 무엇인지 알아보기 위해 조사를 했습니다.

pyjnius의 고유한 기능 중 하나는 호출자가 보호 및 비공개 메서드와 필드를 포함할지 여부를 결정할 수 있다는 것입니다. 내 선호 사항은 공개 전용이지만 비공개 필드와 메서드를 사용 가능하게 만드는 것이 유용하다는 주장을 이해합니다.

성능은 내 프로젝트에 매우 중요합니다. 아래 클래스로 몇 가지 테스트를 수행했습니다.

package org.pkg;

public class MyClass {

  public MyClass() {
  }

  public int number = 42;

  public float add1(float x, float y) {
    return x + y;
  }

  public float add2(float x, float y) {
    return x + y;
  }

  public float add2(int x, int y) {
    return x + y;
  }
}

JPype에서:

In [1]: import jpype
   ...: import jpype.imports
   ...: jpype.startJVM()
   ...: from org.pkg import MyClass
   ...: myInstance = MyClass()
   ...:

In [2]: %timeit myInstance.number
640 ns ± 2.65 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [3]: %timeit myInstance.add1(10.3, 20.5)
2.13 µs ± 24.8 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [4]: %timeit myInstance.add2(10.3, 20.5)
2.19 µs ± 9.41 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

피니우스에서:

In [1]: import jnius

In [2]: MyClass = jnius.autoclass('org.pkg.MyClass')

In [3]: myInstance = MyClass()

In [4]: %timeit myInstance.number
161 ns ± 0.104 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [5]: %timeit myInstance.add1(10.3, 20.5)
1.04 µs ± 8.16 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [6]: %timeit myInstance.add2(10.3, 20.5)
2.71 µs ± 11.2 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

Pyjnius는 오버로드된 방법을 제외하고는 상당히 빠릅니다. 메서드가 오버로드될 때 호출할 메서드를 결정하는 방법에 대한 참고 사항을 비교해야 합니다. Pyjnius에는 많은 오버헤드를 추가하는 것으로 보이는 이러한 점수 매기기 메커니즘이 있습니다. JPype는 그 결정을 훨씬 더 빠르게 만듭니다.

마지막으로 벤치마크 목적으로:

In [9]: def add(x, y):
   ...:     return x + y
   ...:

In [10]: %timeit add(10.3, 20.5)
82.9 ns ± 0.187 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

물론 몇 µs의 차이는 사소하지만 수천 개의 작은 호출을 매우 빠르게 수행하는 경우에는 더해지므로 수행해야 합니다.

JPype와 numpy의 통합은 매우 훌륭하고 사용하기 쉽습니다. 연구자들이 복잡한 구문 없이 Java 라이브러리에 큰 배열을 전달하는 스크립트를 작성하기 위해 이것을 어떻게 사용할 수 있는지 알 수 있습니다. 또한 큰 배열을 전달해야 하고 tobytes() 및 바이트를 수신할 수 있는 특수 Java 코드를 사용하여 이를 수행하지만 분명히 그렇게 깔끔하거나 편리하지는 않습니다.

불행히도 JPype 속도는 일종의 전망입니다. JPype는 나쁜 일로부터 보호하기 위해 매우 방어적입니다. 이는 사소하지 않은 오버헤드가 많다는 것을 의미합니다. 이는 예를 들어 Java 호출이 수행될 때마다 스레드가 연결되어 있는지 확인하므로 IDE와 같은 외부 스레드에서 호출되는 경우 segfault가 발생하지 않습니다. 내 로컬 사용자 그룹은 모두 과학자이므로 진입점은 모두 매우 끔찍한 교차 배선으로부터 보호됩니다. 어떤 것이 그들에게 세그폴트(segfaults)가 있다면(아무리 미쳤어도), 나는 실패했습니다. (이는 의도적으로 나쁜 객체를 구성하는 것을 포함하여 1500번의 테스트를 설명할 것입니다.)

둘째, 개별 작업의 속도는 수행되는 작업의 아주 작은 차이에서 크게 다를 수 있습니다. 당신이 준 사소한 예는 최악의 경우 중 하나였습니다. 액세스 중인 필드 유형에 따라 경우에 따라 액세스 속도가 실제로 변경될 수 있습니다.

속도 예제의 경우 int 필드를 요청하고 있습니다.

• PyJnius에서는 객체 조회를 위한 설명자를 생성하고 필드에 액세스하여 새로운 Python long을 생성한 다음 반환합니다.
• JPype에서는 객체 조회를 위한 디스크립터를 생성하고 필드에 액세스하고 새로운 Python long을 생성한 다음 Java int에 대한 래퍼 유형을 생성하고 Python long 메모리를 JInt에 복사합니다. 정수 클래스 직접), 그런 다음 슬롯을 Java 값으로 바인딩하고 마지막으로 결과 JInt를 반환합니다.

따라서 필드에 액세스할 때 속도 벤치마킹을 수행하는 것과 같은 사소한 일이라도 실제로는 그렇게 사소하지 않습니다.
차이점은 하나는 Python long을 반환하고 다른 하나는 실제 Java 정수(Java 변환 규칙을 따름)를 반환했기 때문에 다른 오버로드된 메서드에 전달되고 제대로 바인딩될 수 있다는 것입니다. 래퍼 유형을 반환하는 작업은 단순히 Python 유형을 반환하는 것 이상이므로 속도에서 큰 차이가 있습니다.

몇 가지 다른 필드 유형을 테스트하여 이를 보여주려고 했습니다. 불행히도, 내가 Object 필드를 테스트했을 때 jnius는 "harness.objectField = 마구" 코드에서 segfault를 발생시켰습니다. 그 특정 교차 배선이 왜 문제를 일으켰는지 잘 모르겠지만 나에게는 실패했습니다. 나는 호출 속도가 3-5배, 특정 어레이 액세스가 300배 빨라진 심각한 위반자를 제거하는 것 외에 JPype의 속도에 그다지 관심이 없었습니다. 그러나 아마도 어떤 부분이 개선될 수 있는지 검토하고 확인해야 할 것입니다. 나는 안전을 제거하거나 반품 계약을 제거하지 않고 PyJnius와 같은 맨 뼈로 줄일 수 있는지 의심합니다(나는 할 수 없음). 기껏해야 10-30%의 속도 향상이 여전히 가능합니다.

private 및 protected 필드에 액세스하는 기능은 확실히 가능합니다. 나는 사용자가 개체를 직접 노출하는 것보다 반사 또는 기타 내부 액세스 방법을 사용하는 것을 선호합니다. 그런 것을 제공해야 한다면 공개적으로 노출되지 않는 필드를 포함하는 _private 라는 필드를 만들 것입니다. JPype는 각 유형에 대해 하나의 클래스 래퍼만 제공하므로 세밀한 제어 방법이 별로 없습니다. 따라서 비공개 액세스 권한이 있는 클래스를 만든 다음 동일한 유형의 두 번째 개체를 만들고 비공개가 노출되지 않도록 선택할 수 없습니다. 나는 문자열 변환으로 그 길을 갔고 어떤 도서관은 하나의 정책을 선택하고 다른 도서관은 다른 정책을 선택하여 비호환성을 초래하는 재앙이었습니다.

배열 목록을 사용하여 몇 가지 테스트를 실행했습니다.

import jpype
import timeit
jpype.startJVM()
ArrayList = jpype.JClass("java.util.ArrayList")

def pack():
    ja = ArrayList()
    for i in range(1000):
        ja.add(i)

def iter(ja):
    u = 0
    for i in ja:
        u+=i

def access(ja):
    u = 0
    for i in range(len(ja)):
        u+=ja.get(i)

def access2(ja):
    u = 0
    for i in range(len(ja)):
        u+=ja[i]


ja = ArrayList()
for i in range(1000):
   ja.add(i)

print("Pack arraylist %e"%( timeit.timeit("pack()", globals=globals(), number=1000)/1e6))
print("Iterate arraylist %e"%(timeit.timeit("iter(ja)", globals=globals(), number=1000)/1e6))
# Get is a direct call
print("Access(get) arraylist %e"%(timeit.timeit("access(ja)", globals=globals(), number=1000)/1e6))
# [] is emulated
print("Access([]) arraylist %e"%(timeit.timeit("access2(ja)", globals=globals(), number=1000)/1e6))

제이파이

팩 배열 목록 2.768904e-06
배열 목록 5.208071e-06 반복
액세스(가져오기) 배열 목록 4.037985e-06
액세스([]) 배열 목록 4.690264e-06

쥬니우스

팩 배열 목록 3.322248e-06
배열 목록 4.099314e-06 반복
액세스(가져오기) 배열 목록 5.653444e-06
액세스([]) 배열 목록 7.762727e-06

매우 다른 기능을 제공하는 경우를 제외하고는 사소하게 다를 수 있다는 것 외에는 매우 일관된 이야기가 아닙니다. 당신이 하는 모든 것이 메소드에 접근하는 것이라면 그것들은 꽤 비슷할 것입니다. JPype로 사전 변환된 배열을 전달하는 것은 100배 더 빠르며 목록과 튜플을 변환하는 JPype는 2배 더 느립니다(현재 벡터 액세스를 사용하지 않거나 튜플에 대한 특수 우회가 있음). 따라서 결론은 코딩 스타일에 따라 어느 쪽이 훨씬 빠를 수 있다는 것입니다. 그러나 내 사용자는 일반적으로 속도보다는 사용 편의성과 방탄 구성을 위해 JPype를 선택합니다. (아 농담이야! JPype가 우연히 Google에서 찾은 첫 번째 링크이기 때문에 인터넷에서 우연히 발견했을 가능성이 큽니다.)

JPype가 메소드 바인딩을 수행하는 방법에 대해서는 개발자/사용자 가이드에 세부사항이 있어야 합니다. 메소드 바인딩은 Java 사양에 제공된 규칙에 따라 디스패치에 대한 메소드 목록을 사전 정렬하여 시작하여 무언가가 다른 것을 숨기면 목록에서 먼저 표시되도록 합니다(코드는 다음과 같이 native/java/org/jpype에서 찾을 수 있습니다. 디스패치가 처음 생성될 때 정렬을 수행하기 위해 Java 유틸리티 클래스를 사용). 또한 각 방법에는 다른 방법을 숨기는 기본 설정 목록이 제공됩니다. 해결은 먼저 각 인수를 확인하여 인수에 대한 "Java 슬롯"이 있는지 확인하는 것으로 시작됩니다. Java 슬롯은 변환이 필요 없는 기존 개체를 가리키므로 일치하기 전에 이러한 개체를 제거하면 암시적 규칙이 아닌 직접 규칙을 사용할 수 있습니다. 그런 다음 유형에 따라 인수를 4단계(정확, 암시적, 명시적, 없음)로 일치시킵니다. 다음 메서드로 건너뛰기 위해 명시적 및 없음에 대한 바로 가기입니다. 정확한 정보를 얻으면 전체 프로세스를 단축하여 호출로 이동합니다. 일치하는 항목이 있으면 덜 구체적인 바인딩이 있는 메서드를 숨깁니다. 숨겨지지 않은 두 개의 암시적 일치 항목이 발견되면 TypeError가 진행됩니다. 모든 일치 항목이 소진되면 변환 루틴이 실행됩니다. 그런 다음 Python 전역 잠금을 해제하고 호출하고 전역 잠금을 다시 획득합니다. 반환 유형이 조회되고 반환된 유형을 기반으로 새 Python 래퍼가 생성됩니다(공변 반환을 사용하므로 반환된 유형이 메서드의 유형이 아니라 가장 많이 파생됨). 가변 인수에 대한 약간의 복잡성이 있지만 사전 구성된 테이블은 foo(double, double)를 시도하기 전에 foo(long, long)를 시도하고 (long , long)은 Java 메소드 확인 규칙으로 인해 모든 일치 항목에서 double, double을 방지합니다. 내가 구현할 수 있는 몇 가지 속도 향상이 있지만 추가 캐싱 테이블이 필요합니다.

2017년에 프로젝트를 시작할 때 바로 가기가 있는 주문 시스템을 상속받았습니다. 오버헤드의 대부분을 밀어내기 위해 캐시와 자바 슬롯을 숨기는 메서드를 추가했습니다.

메서드의 실행 경로를 최적화했습니다. JPype의 수정된 숫자는 다음과 같습니다.

팩 배열 목록 2.226081e-06
배열 목록 4.082152e-06 반복
액세스(가져오기) 배열 목록 2.962606e-06
액세스([]) 배열 목록 3.644642e-06

내 로컬 사용자 그룹은 모두 과학자이므로 진입점은 모두 매우 끔찍한 교차 배선으로부터 보호됩니다. 어떤 것이 그들에게 세그폴트(segfaults)가 있다면(아무리 미쳤어도), 나는 실패했습니다.

예, segfaults는 끔찍하며 pyjnius를 사용하기 시작했을 때 수백 개의 오류가 발생했습니다. 나는 아마도 안전 문제를 해결하고 내 코드에 내장했기 때문에 오랫동안 아무 것도 얻지 못했습니다. 이제 모든 것이 안정적으로 작동합니다. 나는 당신의 사용 사례를 이해합니다. 사용자가 다양한 Java 라이브러리로 데이터 분석을 수행하기 위해 Java 객체로 직접 작업하는 과학자인 경우 segfault로 인해 모든 작업이 손실됩니다. JPype는 최종 사용자가 Python을 통해 Java 객체로 직접 작업하는 과학 작업을 수행하는 데 더 적합해 보입니다. pyjnius의 주요 사용 사례는 Android와 통신하는 것과 다릅니다. 이 경우 안전 문제는 개발자의 문제이므로 안전 대 속도에 대해 다른 선택을 하는 것이 적절할 수 있습니다.

나는 "당신이 이 순서대로 이 사각형을 밟는 한 안전합니다"의 열렬한 팬이 아님을 인정합니다. JPype 작업을 시작했을 때 로컬 그룹에 코드를 전달할 수 있을 만큼 모든 진입점을 방탄 처리하는 데 거의 1년이 걸렸습니다. 그리고 그 이후로 2년의 API 아머를 추가했습니다. JVM이 로드되지 않는(해결하기 매우 어려운) 소수의 드문 사람들을 제외하고는 JPype가 프로덕션 코드 표준으로 올라왔기 때문에 남아 있는 문제가 거의 없습니다.

속도와 안전의 절충에 관해서는 속도는 훌륭하지만 안전한 작업을 소홀히 하여 속도를 얻고 있다면 일반적으로 대부분의 사용자에게 좋지 않은 거래입니다. 프로토타이핑 코드를 돌리든 프로덕션 시스템을 작성하든 작업을 중단하고 segfault를 해결하려고 시도해야 하는 것은 사용자가 직면해서는 안 되는 주의를 산만하게 하는 일입니다.

누군가가 Android 에뮬레이터에서 JPype를 테스트하는 방법에 대한 몇 가지 예를 기꺼이 제공한다면 필요한 수정 작업에 대해 알 수 있습니다.

Android에서 사용하려면 pyjnius를 python-for-android에 의해 빌드된 Python 배포판의 예술로 패키징하고(종종 buildozer를 더 쉬운 인터페이스로 사용하지만 동일함) 이 배포판을 제공하는 Python 애플리케이션을 빌드합니다. 그러면 python 코드는 pyjnius 또는 사용자가 앱을 실행할 때 python 배포판에 빌드된 다른 python 라이브러리를 가져올 수 있습니다.

따라서 첫 번째 단계는 배포판에서 jpype를 컴파일하는 것입니다. 이는 일반적으로 요구 사항의 일부라고 말할 때 p4a(https://github.com/kivy/python-for-android/)에 의해 수행됩니다. 그러나 항상 그런 것은 아님) "레시피"는 p4a에 순수 파이썬이 아닌 라이브러리를 빌드하는 방법을 설명하는 데 필요합니다. pyjnius용 라이브러리는 https://github.com/kivy/python-for-android/blob/ 에서 찾을 수 있습니다. 예를 들어 p4a.local_recipes 에 설정 buildozer.spec 당신이 포크에 파이썬를 위해 안드로이드를 필요가 없습니다, 요구 사항에 대한 조리법을 찾을 수있는 디렉토리를 선언 당신의 조리법을 사용하십시오.

https://buildozer.readthedocs.io/en/latest/installation.html#targeting -android 더 많은 작업을 자동화하고 여전히 로컬 레시피를 설정하여 시도할 수 있으므로 buildozer를 사용하는 것이 좋습니다. 첫 번째 빌드는 python과 arm에 대한 여러 종속성을 빌드해야 하므로 시간이 걸리며, 이를 위한 Android ndk 및 sdk를 다운로드해야 합니다. 앱에 기본 kivy 부트스트랩을 사용하고 jpype를 가져오고 레이블에 일부 코드의 결과를 표시하거나 심지어 인쇄를 사용하는 logcat에 표시하는 앱과 같은 "hello world"를 만들 수 있습니다. kivy가 안드로이드 에뮬레이터에서 얼마나 잘 실행되는지 기억하십시오. 나는 그것을 사용하지 않았지만 일부 사용자는 그렇게했다고 생각합니다. 가속 설정으로 작동해야합니다. afaik, 그렇지 않으면 sdl2 래퍼 또는 webview를 사용할 수 있고 플라스크를 사용할 수 있습니다. 병 서버가 물건을 표시하기 위해 가장 먼저 테스트를 거친 키비 서버로 먼저 시도할 것입니다.

Android용으로 빌드하려면 Linux 또는 osx 머신(VM은 괜찮고 Windows 10의 WSL은 괜찮음)이 필요합니다.

python-for-android용 jpype 레시피 작업을 시작하는 경우 논의가 있을 수 있도록 진행 중인 PR을 여는 것을 환영합니다. 작동한다면 특히 오래 지속되어온 pyjnius 제한 사항을 실제로 해결할 수 있다면 좋을 것입니다. 스레드의 앞부분에서 논의한 바와 같이, pyjnius는 본질적으로 kivy 사용에 대한 핵심 요구 사항을 다루지만, 이를 훨씬 뛰어넘을 만큼 충분한 개발 능력이 없습니다.

@inclement jpype-project/jpype#799에서 Android 포트에 대한 PR을 설정했습니다. 불행히도, 나는 여기에서 어디로 가야할지 잘 모르겠습니다. 실제로 올바른 빌드 경로가 아닌 gradle을 실행하려고하는 것 같습니다.

수행해야 할 조치는 다음과 같습니다.

• [x] 모든 jpype/*.py 파일을 빌드(또는 사전 컴파일된 버전)에 포함합니다.
• [x] native/build.xml에서 Apache ant를 실행하고 결과 jar 파일을 액세스할 수 있는 위치에 배치합니다.
• [x] 빌드에 jar 파일(또는 이에 상응하는 파일)을 포함합니다.
• [x] native/common 및 native/python의 C++ 코드를 빌드에 포함할 _jpype라는 모듈로 컴파일합니다.
• [x] 지금은 수동으로 테스트할 수 있도록 대화형 셸을 시작하는 main.py 파일을 포함합니다.
• [ ] 앞으로 동적으로 생성된 클래스를 로드할 수 있도록 "ASM" 또는 Android용으로 작동하는 것과 유사한 것을 포함해야 합니다.
• [x] 사용자 지정 부트스트랩을 사용하여 JVM 및 도우미 jar 파일을 로드하고 모든 기본 메서드를 연결하도록 C++ 코드를 패치합니다.
• [ ] jvmfinder를 android에서 작동하는 것으로 패치하고 "startJVM"이 메인 시작 부분이 아니라 자동으로 호출됩니다.
• [ ] jar 탐색 시스템(가져오기가 작동하는 방식)이 Android에서 작동할 수 있도록 org.jpype를 패치합니다.

일부 문서를 살펴보았지만 이를 수행하는 방법에 대해 눈에 띄는 것은 없었습니다. 내 프로젝트 레이아웃은 기본 모듈 아래에 모든 것을 넣지 않기 때문에 평소와 다소 다릅니다. 이러한 모든 작업을 수행하고 gradle 실행과 같은 바람직하지 않은 패턴을 비활성화합니다(내가 말할 수 없는 유용한 작업을 수행하지 않는 한).

실제로 올바른 빌드 경로가 아닌 gradle을 실행하려고하는 것 같습니다.

Gradle은 APK 패키징의 마지막 단계로 사용되는 빌드 도구이며 아마도 jpype를 포함하는 것과 관련이 없을 것입니다.

모든 jpype/*.py 파일을 빌드(또는 사전 컴파일된 버전)에 포함합니다.

일반적으로 jpype가 기본적으로 일반 Python 모듈로 수행되는 경우 첫 번째 레시피 시도는 아마도 대부분의 어려운 작업을 수행할 것입니다. CppCompiledComponentsPythonRecipe 는 python setup.py build_ext 및 python setup.py install 실행과 같은 작업을 수행합니다. NDK 환경을 사용합니다. 이렇게 하면 앱 내부에 포함하기 위해 빌드되는 Python 환경 내에 jpype python 패키지가 설치됩니다.

빌드에 jar 파일(또는 이에 상응하는 파일)을 포함합니다.

이것은 아마도 레시피가 수행해야 하는 추가 단계일 것입니다. 이는 python-for-android가 빌드 중인 Android 프로젝트 내의 적절한 위치에 jar 파일(또는 필요한 모든 것)을 복사하는 것입니다.

native/common 및 native/python의 C++ 코드를 빌드에 포함할 _jpype라는 모듈로 컴파일합니다.

이것이 setup.py에 의해 처리된다면 이것은 이미 작동하고 있지만 약간의 조정이 필요할 수 있습니다. 그렇지 않은 경우 레시피에 컴파일 명령을 포함할 수 있습니다(다른 레시피에서 self.get_env 를 사용하여 완료됨을 볼 수 있듯이 적절한 env 변수를 설정하여 Android 환경용으로 빌드하도록 함).

사용자 정의 부트스트랩을 사용하여 JVM 및 컴패니언 jar 파일을 로드하고 모든 기본 메소드를 연결하도록 C++ 코드를 패치합니다.

올바른 Android JNI 인터페이스 기능을 사용하는 것에 따라 이 부분이 상당히 간단하기를 바랍니다. 예를 들어 이 패치 에서 알 수 있듯이 다른 도우미 라이브러리가 다른 랩프레를 제공하기 때문에 적절한 조건부 컴파일을 수행하는 대신 pyjnius를 패치하여 약간 해킹된 방식으로 이 작업을 수행

jvmfinder를 android에서 작동하는 것으로 패치하고 "startJVM"은 main이 시작될 때가 아니라 자동으로 호출됩니다.

JVM에 대해 잘 알지는 못하지만 Android는 항상 기존 jvm에 액세스하기를 원하고 새 인스턴스를 시작할 수 없다고 생각합니다. 그게 문제가 될까요(아니면 그냥 잘못된 건가요?)?

native/build.xml에서 Apache ant를 실행하고 결과 jar 파일을 액세스할 수 있는 위치에 배치합니다.

익숙하지 않아서 이것에 대해서도 잘 모르겠습니다. 이것은 단지 내부 jpype 빌드 단계입니까? Java 버전이 어떻게 상호 작용하는지 잘 모르겠지만 여기에서는 시스템 네이티브 개미를 사용하는 것이 좋을 것 같습니다.

buildozer가 setup.py를 존중하지 않는다는 경고를 표시하므로 맨 위에서 gradle 단계로 직접 건너뜁니다. 따라서 이러한 중간 단계를 수동으로 추가해야 합니다. 우리의 setup.py는 jar 파일을 dll과 병합하기 위해 후크 파일을 생성하는 것과 같은 많은 사용자 정의 컴파일 단계를 수행합니다. 이 단계는 여기에 적용되지 않을 수 있으므로 건너뛰어도 괜찮았지만 cpp 및 Java 파일도 찾지 못했습니다. setup.py에 정의되어 있습니다. 문제의 일부는 내 setup.py가 너무 커서 setupext 모듈로 분할해야 한다는 것입니다.

먼저 프로세스를 한 번 실행하고 로그를 표시할 수 있도록 clean 명령을 실행할 수 있는 방법을 알아야 합니다. (나는 플레이하면서 처음으로 조각 식사를 실행했습니다. 그래서 깨끗한 로그가 없습니다.) 또한 우리는 이 대화를 PR로 옮겨서 스레드에 대한 주제에 더 머물 수 있도록 해야 합니다.

FWIW Android가 아닌 프로젝트의 핵심을 JPype로 이식할 수 있었습니다. 두 가지 사소한 어려움이나 차이점이 있습니다.

1. classpath 에서 kwarg jpype.startJVM() 상관없이 내가 뭘 무시 것으로 보인다. 하지만 addClassPath() 기능은 작동했습니다. 클래스 경로 순서에 관심이 있는 개발자는 jnius_config.add_classpath() 사용 방식과 비교하여 약간의 조정이 필요할 수 있습니다.

2. Java 인터페이스 구현은 훌륭하게 작동하지만 약간 다릅니다. 내 코드에는 Python 문자열 목록을 반환하는 함수가 있었습니다. 돌이켜보면 아마 각 문자열을 Java 문자열로 변환했어야 했을 것입니다. 하지만 나는 그것에 대해 생각하지 않았고 인터페이스 함수 정의가 이것이 작동하도록 하기 위해 Java 객체 목록을 반환하도록 했습니다. 이는 pyjnius에서 잘 작동하여 python 문자열을 Java 객체의 하위 클래스로 효과적으로 만듭니다. JPype에서는 작동하지 않지만 JPype의 JString 클래스로 문자열을 변환하여 쉽게 수정했습니다.

구현된 메서드에 대해 @JOverride 를 작성하는 것은 @java_method('(Ljava/lang/String;[Ljava/lang/Object;)V') 와 같은 코드보다 훨씬 간단합니다.

이 두 가지 문제를 처리하면 모든 것이 기본적으로 잘 작동했습니다. 변경해야 하는 바이트 배열을 전달하는 일부 코드가 있지만 JPype는 이를 잘 지원합니다. 또한 JPype의 암시적 유형 변환은 매우 편리하며 여기저기 뿌려야 했던 많은 데코레이터를 대체할 수 있습니다.

@Thrameos 여기에서 당신의 결단을 존중합니다. JPype가 Android에서 작동하도록 하는 행운을 빕니다.

댓글 감사합니다.

클래스 경로에서 무엇이 잘못될 수 있는지 확실하지 않지만 그것이 Python을 시작하는 곳일 것이라고 추측해야 한다면. 때때로 사람들은 모듈에서 JVM을 시작하고 시작 디렉토리에 대한 Java 경로 및 Python 경로에 대한 규칙이 다르기 때문에 jar가 누락될 수 있습니다. (이 문제에 대한 사용자 가이드 섹션이 있습니다.)

나는 매일 classpath 기능을 사용하며 이것은 우리 테스트 패턴의 일부입니다. 따라서 클래스 경로가 존중되지 않으면 꽤 큰 실패가 발생합니다. 즉, 복잡한 패턴을 작동시키는 데 필요한 마법 같은 위치와 절대 경로를 찾는 데 어려움을 겪는 첫 번째 사람은 아닙니다.

다음은 개발 영역을 기준으로 Py 디렉토리에서 테스트 시스템을 시작하는 예입니다.

import jpype
import os

devel = os.path.dirname(__file__)
devel = os.path.join(devel, '..', '..')
devel = os.path.abspath(devel)  # Notice that I converted the path to absolute so that it doesn't matter where the
# PWD of Java will be when this script is called.   Otherwise, if I import this from a different location it will use the
# original PWD and Java will find nothing in the classpath.

classpath = [
    '%s/gov.llnl.math/dist/*' % devel,
    '%s/gov.llnl.rdak/dist/*' % devel,
    '%s/gov.llnl.rnak/dist/*' % devel,
    '%s/gov.llnl.rtk/dist/*' % devel,
    '%s/gov.llnl.rtk.gadras/dist/*' % devel,
    '%s/gov.llnl.rtk.response/dist/*' % devel,
    '%s/gov.llnl.utility/dist/*' % devel,
    ]

jpype.startJVM(classpath=classpath, convertStrings=False)

상대 경로와 절대 경로가 작동하지만 시작 위치에 따라 크게 달라집니다. addClassPath에는 모든 경로가 호출자 위치와 관련되어 있는지 확인하는 특별한 마법이 있습니다. classpath 키워드 인수에도 동일한 논리가 필요하다고 생각합니다.

문자열 목록을 반환하는 문제를 볼 수 있습니다. 트리거되는 동작에 대한 반환 유형에 따라 다릅니다. 메서드가 String[] 를 반환하는 것으로 선언된 경우 반환할 때 각 Python 문자열을 Java로 강제 실행해야 합니다. 메소드가 List<String> 를 반환하는 것으로 선언된 경우 Java 제네릭이 이를 제거하여 List<Object> 가 될 때 문제가 발생합니다. JPype가 목록을 보는 방식에 따라 변환을 시도하거나 시도하지 않을 수 있지만 이는 정의된 동작이므로 확인하겠습니다. 안전한 솔루션은 반품을 위해 모든 항목을 변환할 수 있어야 하는 목록 이해입니다.

클래스 경로에서 무엇이 잘못될 수 있는지 확실하지 않지만 그것이 Python을 시작하는 곳일 것이라고 추측해야 한다면. 때때로 사람들은 모듈에서 JVM을 시작합니다.

그게 내가 하던 일이야!

나는 매일 classpath 기능을 사용하며 이것은 우리 테스트 패턴의 일부입니다. 따라서 클래스 경로가 존중되지 않으면 꽤 큰 실패가 발생합니다. 즉, 복잡한 패턴을 작동시키는 데 필요한 마법 같은 위치와 절대 경로를 찾는 데 어려움을 겪는 첫 번째 사람은 아닙니다.

예, 이것은 당신이 즉시 알아차릴 수 있는 것이며 내가 이 문제를 겪은 첫 번째 사람이 아니라고 생각했습니다. 도움이 되는 코드 샘플을 제공해 주셔서 감사합니다. 결과적으로 코드를 일부 개선했습니다.

안전한 솔루션은 반품을 위해 모든 항목을 변환할 수 있어야 하는 목록 이해입니다.

그것이 내가 한 일이며 지금 올바르게 작동합니다. 감사 해요!

몇 년 전에 py4j와 jnius를 비교한 결과 jnius가 훨씬 빠릅니다.

장소에서 언급된 jpype를 보았을 때 항상 - http://jpype.sourceforge.net/ 을 참조하고 있다고 가정하고 유지 관리되지 않는 것처럼 보이므로 멀리했습니다(새 프로젝트를 이상하게 보지 못함)

이 스레드를 읽으면서 벤치마크를 다시 시도했습니다.
일부 결과:
https://gist.github.com/AbdealiJK/1dd5b7677435ba22f9ab3e26016bb3e7

# jpype
# createjvm: 0.550s
# loadmodel: tot=1.466451 max=1.064521s avg=0.014665s
# fields   : tot=0.019881 max=0.009795s avg=0.000199s
# score    : tot=0.033356 max=0.023338s avg=0.000334s

# jnius
# createjvm: 0.249s
# loadmodel: tot=1.773011 max=1.385274s avg=0.017730s
# fields   : tot=0.039058 max=0.012234s avg=0.000391s
# score    : tot=0.067590 max=0.031904s avg=0.000676s

# py4j
# createjvm: 0.222s
# loadmodel: tot=0.616913 max=0.027464s avg=0.006169s
# fields   : tot=0.699152 max=0.026426s avg=0.006992s
# score    : tot=0.389583 max=0.017620s avg=0.003896s

공정하게 말하자면, JPype는 2020년 3월까지 Python(CPython과 반대)으로 작성된 프런트 엔드 API를 가지고 있었습니다. 따라서 JPype가 제공하는 것에 비해 다소 느리다는 것을 보여주는 이전 벤치마크가 많이 있습니다. 메모리 관리로 해결해야 하는 백엔드 문제가 너무 많았고 Ruby, 멀티스레딩 등을 지원하기 위해 전체 다층 래퍼를 제거했습니다. 그 속도가 마지막 작업이었습니다.

이 시점에서 꽤 빨라야 합니다. 그러나 다른 패키지와 관련하여 추가 작업이 필요한 것을 발견하면 문제에 메모를 남겨주세요. 반환 계약으로 인해 몇 가지 제한 사항이 있지만 호출, 배열 전송 및 메모리 버퍼링을 위한 기본 경로는 이 시점에서 꽤 잘 처리됩니다.

JPype에서도 좋은 결과를 얻고 있습니다. 특히, numpy 배열과의 통합에서 좋은 가치를 얻고 있습니다. 이전에는 할 수 없었던 새로운 기능을 추가하여 의미 있는 방식으로 성능을 개선할 수 있었습니다.

누구든지 kivy-remote-shell 도구를 업데이트하여 현재 Python3 및 buildozer로 빌드하고 지침을 단계적으로 개선하도록 친절할 수 있다면 JPype 이식 노력에 도움이 될 것입니다. 매우. 부팅 및 테스트 단계까지 모든 필수 단계를 완료했습니다. 그러나 부트스트랩 프로세스를 완료할 수 있는 환경이 없으면 진행하기 어려울 것입니다. 이번 주말에 원격 셸 도구 업데이트를 다시 시도하거나(성공할 수 있음) kivy에 대해 더 잘 알고 있는 이해 당사자가 이 전제 조건 작업을 완료할 수 있으며 주말에 내가 가장 완성할 수 있는 기술 작업을 완료하는 데 보낼 수 있습니다. . 다른 사람들을 돕기 위해 내 시간을 자유롭게 제공하지만, 리소스는 유한하며 Android 이식 작업에서 수행하는 모든 작업은 다른 많은 사람들도 관심을 갖고 있는 Python from Java 브리지에 대한 지연입니다.

나는 안드로이드 포팅 노력이 차이점을 처리할 수 있도록 핵심 코드를 재작업하는 데 몇 주를 보낸 PyPy 포팅 노력의 길을 가는 것을 피할 수 있기를 바랍니다. 그러나 그런 다음 개체 시스템의 사소한 차이가 오류를 생성하는 기술적 문제에 부딪쳤습니다. 생성된 코드에서 생성된 오류 보고서를 디버그하는 방법을 추적하는 데 도움을 줄 수 있는 사람을 찾을 수 없었습니다. 나는 엎질러진 우유에 대해 울지 않고 JPype 코드를 다른 의미 있는 방식으로 개선하기 위해 그 모든 노력을 기울였지만 결국 JPype를 사용하려는 사용자는 높고 메마른 상태로 남았습니다. 이 노력이 실패하면 다시 돌아가기 때문에 모든 것이 손실되는 것은 아니지만, 대기열의 맨 끝에 무언가가 있으면 누군가 시간을 내서 나를 도와줄 수 없다면 6개월 동안 다시 시작하기가 어렵습니다. .

이해 관계자를 위한 진행 상황 업데이트.

pythonforandroid 내에서 JPype를 성공적으로 부팅하고 기본 기능을 테스트할 수 있었습니다. JVM의 차이로 인해 일부 고급 기능이 가능하지 않을 수 있지만 대부분의 JPype는 Android 플랫폼에서 사용할 수 있을 것이라고 생각합니다. 포트는 buildozer 및 pythonforandroid 프로젝트에 대한 일부 업그레이드가 필요했기 때문에 시간이 좀 걸렸습니다(따라서 소스를 많이 읽고 도움을 요청해야 함). 한 주말에 프로세스의 가장 어려운 부분을 완료할 수 있도록 응답해 주신 개발자들에게 깊은 감사를 드립니다. 귀하의 의견이 없었다면 불가능했을 것입니다. 관련 변경사항을 PR로 넣었지만 PR의 백로그를 보면 고려 대상이 되기까지 시간이 좀 걸릴 수 있습니다. 이제 필요한 핵심 기술 사양이 있으므로 이를 통합할 수 있어야 하며 명목상 늦가을 달력에 JPype 1.2 정도의 작업 릴리스 코드가 있어야 합니다. 사용자의 관심이 크다면 추진할 수 있지만 다른 프로젝트의 중요한 기능인 Python from Java와 경쟁하고 있습니다.

누군가가 노력을 가속화하는 데 도움을 주고 싶다면, 다음 어려운 단계는 빌드를 실행하고, 에뮬레이터를 로드하고, 테스트 벤치를 실행할 수 있도록 부분 빌드 시스템으로 모든 것이 제자리에 있는 도커 이미지를 구성하는 방법을 알아내는 것입니다. azure 파이프라인(또는 일부 다른 CI 시스템)의 Android. 작동하는 것과 작동하지 않는 것을 감지할 수 있는 작동하는 CI가 있으면 안정적인 소프트웨어로 배포할 수 있는 데 훨씬 더 가까워질 것입니다. 이것이 JPype 프로젝트에 포함되어야 하는지 또는 별도의 Android 테스트 프로젝트가 있어야 하는지 확실하지 않습니다.