nova eldono de intertavolo , kiu permesas al Python-aplikoj havi plenan aliron al klasbibliotekoj en la Java lingvo. Kun JPype de Python, vi povas uzi Java-specifajn bibliotekojn por krei hibridajn aplikaĵojn, kiuj kombinas Java kaj Python-kodon. Male al Jython, integriĝo kun Java estas atingita ne per kreado de Python-variaĵo por la JVM, sed per interagado sur la nivelo de ambaŭ virtualaj maŝinoj uzante komunan memoron. La proponita aliro permesas ne nur atingi bonan rendimenton, sed ankaŭ disponigas aliron al ĉiuj CPython kaj Java bibliotekoj. Projekta kodo licencita sub Apache 2.0.
Ĉefaj ŝanĝoj:
- Kaŝmemoro estis aldonita al metodovokoj por eviti troŝarĝan rezolucion, kiu multe reduktas la efikecon de efika rezolucio, precipe se la sama troŝarĝo estas vokita multajn fojojn, kiel dum buklo-ekzekuto.
- De 4 ĝis 100 fojojn, depende de la datumtipo, la translokigo de listoj, opoj kaj bufroj al tabeloj de Java primitivoj estas akcelita. La konvertiĝo uzas optimumigitan pretigon de en-memoraj bufroj, anstataŭe de la Sequence API. Kiam Python-bufro estas renkontita, nur la unua elemento estas kontrolita por konvertiĝo, ĉar tiuj bufroj estas homogenaj.
- Prilaborado de haltoperacioj (efektivigitaj en JPype 1.0.0, sed estis preterlasita dum preparado de la ŝanĝprotokolo). JPype nun nomas la JVM-fermrutinon, kiu provas eliri gracie. Ĉi tio kondukas al pluraj ŝanĝoj en konduto. Ne-fonaj fadenoj (proxilvokoj) nun povas teni la JVM malfermita ĝis ili finiĝos. Prokuralvokoj prilaboros malŝalton ĝis la alvoko finiĝos, sed ricevos interrompan mesaĝon. Dosieroj nun estas konvene fermitaj kaj fluitaj al disko se la fadenoj pritraktas la escepton kiel atendite. Rimedopurighokoj kaj finigiloj estas ekzekutitaj. Kiam fadenoj estas generitaj, AtExit-hokoj estas nomitaj. Per la demono, aŭtomata fadenaldonaĵo estas efektivigita kiam oni uzas la JVM de Python. Buggy-kodo, kiu ne povas ĝuste pritrakti fadenan purigadon, verŝajne pendos kiam malŝalto estos efektivigita. Plia dokumentaro troveblas en la uzantmanlibro.
- La envolvaĵo por Throwable ricevis envolvaĵon por Object anstataŭ la atendata rezulto, kiu kaŭzis strangajn konvertiĝojn de Python-klasoj.
- Korektis tajperarojn en la importsistemo, kiuj rezultigis la eraron '»jname» ne trovita'.
- Certigis ke "^C" estis antaŭenigita ĝuste en KeyboardInterrupt.
- Riparita problemo kun simboloj ekde Python 3.5.3. PySlice_Unpack estis enkondukita en posta flikeldono (3.5.4) kaj ne devus esti uzata.
- Korektis cimon kun numpy.linalg.inv, kiu kaŭzis kraŝon. La problemo estis spurita al fadena komunikado inter la JVM kaj kelkaj numpy gustoj. La proponita solvo estas voki numpy.linalg.inv antaŭ ol komenci la JVM.
fonto: opennet.ru