Setahun telah berlalu sejak trik sebelumnya berhasil: untuk mempublikasikan video di YouTube alih-alih sebuah pos. “Shameful talk about singleton” memperoleh 7k tampilan di YouTube dan dua kali lebih banyak tentang Habré dalam versi teks. Untuk sebuah artikel yang ditulis dalam keadaan yang benar-benar keras kepala dan menceritakan tentang akordeon tombol kuno - ini sedikit sukses.

Hari ini saya telah menginstal rilis baru sepanjang malam. Kali ini topiknya jauh lebih baru: sejarah komit terhadap teknologi eksperimental - SubstrateVM. Tetapi tingkat keuletan telah meningkat ke tingkat yang baru.



Sangat menantikan komentar Anda! Saya mengingatkan Anda bahwa jika Anda benar-benar ingin meningkatkan sesuatu di pos ini, yang terbaik adalah mengajukan yang ada di Github . Saya ingin mengatakan "suka dan berlangganan ke saluran baru , tetapi apakah semua rilisnya akan berada di hub Java Anda?"

Secara teknis: video memiliki satu perekatan lebih dekat ke akhir. Saya baru saja menulis video yang tidak dikompresi, dan m2 ssd saya yang hanya berukuran lima ratus gigabytes dengan cepat meluap. Dan tidak ada hard drive lain yang dapat menahan tekanan data seperti itu. Oleh karena itu, saya harus memutuskan sambungan selama setengah jam dan keluar dan menemukan tambahan lima puluh pertunjukan untuk merekam beberapa menit terakhir. Ini dicapai dengan menghapus file yang dikompilasi oleh GoogleChrome . Saya menulis tentang perangkat lunak perekaman di FB tepat pada saat merekam , ada banyak rasa sakit.

Lain yang secara teknis menarik: YouTube karena alasan tertentu memblokir saya streaming langsung. Pada saat yang sama, tidak ada satu pun pemogokan dan stigma pada akun tersebut. Mari berharap ini hanya sebuah kusen, dan setelah 90 hari semuanya akan dikembalikan kembali.

Artikel ini akan mengutip dari kode yang dimiliki oleh Oracle. Anda tidak dapat menggunakan kode ini untuk diri sendiri (kecuali jika Anda membaca lisensi aslinya, dan memungkinkannya dalam kondisi, misalnya, GPL). Ini bukan lelucon. Olso, aku memperingatkan.

Prikazka (dan dongeng akan ada di depan)

Banyak yang sudah mendengar cerita bahwa "Jawa baru akan ditulis di Jawa" dan bertanya-tanya bagaimana ini bisa terjadi. Ada dokumen kebijakan Project Metropolis dan surat yang sesuai dari John Rose , tetapi semuanya cukup samar di sana.

Kedengarannya seperti sihir yang menyeramkan dan menyeramkan. Dalam hal yang sama yang dapat Anda coba sekarang, bukan hanya tidak ada sihir, tetapi semuanya bodoh seperti bagian belakang sekop ketika Anda merontokkan gigi Anda dengannya. Tentu saja, ada beberapa nuansa, tetapi ini suatu hari nanti akan sangat.

Saya akan menunjukkannya pada contoh satu kisah instruktif yang terjadi di musim panas. Bagaimana mereka menulis esai "Bagaimana Aku Menghabiskan Musim Panas" di sekolah.

Untuk memulai ucapan kecil. Proyek yang saat ini melakukan kompilasi Ahead-of-Time di Oracle Labs adalah GraalVM. Komponen yang, pada kenyataannya, melakukan nishtyaki dan mengubah kode Java menjadi file yang dapat dieksekusi (menjadi file yang dapat dieksekusi) adalah SubstrateVM atau SVM. Jangan bingung dengan singkatan yang sama yang digunakan oleh satanis data (mesin vektor dukungan). Itu tentang SVM, sebagai bagian penting, kita akan berbicara lebih lanjut.

Pernyataan masalah

Jadi, "bagaimana saya menghabiskan musim panas." Saya duduk berlibur, menghabiskan dua F5 di Grail github dan menemukan yang ini :



Seseorang menginginkan os.version memberikan nilai yang tepat.

Nah cho, saya ingin memperbaiki bug? Kata bocah itu - bocah itu tahu.

Kami akan memeriksa apakah klien kami berbohong.

 public class Main { public static void main(String[] args) { System.out.println(System.getProperty("os.version")); } } 

Pertama, seperti apa bentuk knalpot di Java asli: 4.15.0-32-generic . Ya, ini adalah Ubuntu LTS Bionic yang baru.

Sekarang coba lakukan hal yang sama pada SVM:

 $ ls Main.java $ javac -cp . Main.java $ ls Main.class Main.java $ native-image Main Build on Server(pid: 18438, port: 35415) classlist: 151.77 ms (cap): 1,662.32 ms setup: 1,880.78 ms error: Basic header file missing (<zlib.h>). Make sure libc and zlib headers are available on your system. Error: Processing image build request failed 

Ya benar. Ini karena saya membuat mesin virtual yang sama sekali baru khusus untuk tes "bersih".

 $ sudo apt-get install zlib1g-dev libc6 libc6-dev $ native-image Main Build on Server(pid: 18438, port: 35415) classlist: 135.17 ms (cap): 877.34 ms setup: 1,253.49 ms (typeflow): 4,103.97 ms (objects): 1,441.97 ms (features): 41.74 ms analysis: 5,690.63 ms universe: 252.43 ms (parse): 1,024.49 ms (inline): 819.27 ms (compile): 4,243.15 ms compile: 6,356.02 ms image: 632.29 ms write: 236.99 ms [total]: 14,591.30 ms 

Angka runtime absolut bisa mengerikan. Tapi, pertama, itulah yang dimaksudkan untuk dilakukan: optimisasi yang sangat neraka diterapkan di sini. Dan kedua, ini adalah mesin virtual lemah yang Anda inginkan.

Dan akhirnya, momen kebenaran:

 $ ./main null 

Tampaknya tamu kita tidak berbohong, benar-benar tidak berfungsi.

Pendekatan pertama: mencuri properti dari tuan rumah

Kemudian saya mencari os.version global untuk os.version dan menemukan bahwa semua properti ini ada di kelas SystemPropertiesSupport .

Saya tidak akan menulis path lengkap ke file, karena kemampuan untuk menghasilkan proyek yang benar untuk IntelliJ IDEA dan Eclipse dibangun langsung ke dalam SVM. Ini sangat keren dan sama sekali tidak mengingatkan pada siksaan yang dialami sebagian besar OpenJDK. Biarkan IDE membuka kelas untuk kita. Jadi:

 public abstract class SystemPropertiesSupport { private static final String[] HOSTED_PROPERTIES = { "java.version", ImageInfo.PROPERTY_IMAGE_KIND_KEY, "line.separator", "path.separator", "file.separator", "os.arch", "os.name", "file.encoding", "sun.jnu.encoding", }; //... } 

Lalu saya, tanpa menyertakan kepala sama sekali, hanya pergi dan menambahkan variabel lain ke set ini:

 "os.arch", "os.name", "os.version" 

Saya membangun kembali, menjalankan, mendapatkan baris yang didambakan 4.15.0-32-generic . Hore!

Tapi ini masalahnya: sekarang di setiap mesin tempat kode ini berjalan, selalu mengeluarkan 4.15.0-32-generic . Bahkan di mana uname -a mengembalikan versi bucket sebelumnya, pada Ubunt lama.

Menjadi jelas bahwa variabel-variabel ini ditulis ke file sumber pada saat kompilasi.
Dan sungguh, Anda perlu hati-hati membaca komentar:

 /** System properties that are taken from the VM hosting the image generator. */ private static final String[] HOSTED_PROPERTIES 

Metode lain perlu diterapkan.

Kesimpulan

• Jika Anda ingin properti sistem dari "main Java" muncul di SVM, ini sangat sederhana. Kami menulis properti yang diinginkan di tempat yang tepat, itu saja.
• Anda dapat bekerja di IDE, yang mendukung Java dan Python secara bersamaan. Misalnya, di IntelliJ IDEA Ultimate dengan plugin Python atau yang sama di Eclipse.

Pendekatan kedua

Jika Anda mencari-cari melalui SystemPropertiesSupport SystemPropertiesSupport, kami menemukan hal yang jauh lebih masuk akal:

 /** System properties that are lazily computed at run time on first access. */ private final Map<String, Supplier<String>> lazyRuntimeValues; 

Antara lain, penggunaan properti ini masih tidak menghalangi proses membangun yang dapat dieksekusi. Jelas bahwa jika kita menjejalkan banyak hal di HOSTED_PROPERTIES , maka semuanya akan melambat.

Pendaftaran properti malas terjadi dengan cara yang jelas, dengan mengacu pada metode yang mengembalikan:

 lazyRuntimeValues.put("user.name", this::userNameValue); lazyRuntimeValues.put("user.home", this::userHomeValue); lazyRuntimeValues.put("user.dir", this::userDirValue); 

Selain itu, semua referensi metode ini adalah antarmuka, dan this::userDirValue sama diimplementasikan untuk masing-masing platform yang didukung. Dalam hal ini, ini adalah PosixSystemPropertiesSupport dan WindowsSystemPropertiesSupport .

Jika kita penasaran dengan implementasi untuk Windows, kita akan melihat hal yang menyedihkan:

 @Override protected String userDirValue() { return "C:\\Users\\somebody"; } 

Seperti yang Anda lihat, Windows belum didukung :-) Namun, masalah sebenarnya adalah bahwa generasi executable untuk Windows belum selesai, jadi mendukung metode ini sebenarnya merupakan upaya yang sama sekali tidak perlu.

Artinya, Anda perlu menerapkan metode berikut:

 lazyRuntimeValues.put("os.version", this::osVersionValue); 

Dan kemudian mendukungnya dalam dua atau tiga antarmuka yang tersedia.

Tetapi apa yang harus ditulis di sana?

Kesimpulan

• Jika Anda ingin menambahkan properti baru yang dihitung dalam runtime, maka ini adalah masalah penulisan satu metode. Hasilnya mungkin tergantung pada sistem operasi saat ini, mekanisme switching sudah berfungsi dan tidak bertanya.

Sedikit arkeologi

Hal pertama yang terlintas dalam pikiran adalah untuk mengintip implementasi di OpenJDK dan dengan berani menyalin-menempel. Sedikit arkeologi dan penjarahan tidak akan pernah mencegah seorang penjelajah pemberani!

Jangan ragu untuk membuka proyek Java apa pun di Idea, tulis System.getProperty("os.version") , dan dengan ctrl + klik buka penerapan metode getProperty() . Ternyata semua kebodohan ini terletak pada Properties .

Tampaknya, cukup salin-tempel tempat di mana Properties ini dipenuhi, dan tertawa keras, lari ke kehampaan. Sayangnya, kami menemukan masalah:

 private static native Properties initProperties(Properties props); 

Noooooooooooooo.



Tapi semuanya dimulai dengan sangat baik.

Apakah ada anak laki-laki?

Seperti yang kita ketahui, menggunakan C ++ itu buruk. Apakah C ++ digunakan dalam SVM?

Seperti itu saja! Bahkan ada paket khusus untuk ini: src/com.oracle.svm.native .

Dan dalam paket ini, horor-horor, terdapat file getEnviron.c dengan sesuatu seperti ini:

 extern char **environ; char **getEnviron() { return environ; } 

Saatnya main-main dengan C ++

Sekarang selami sedikit lebih dalam dan buka sumber OpenJDK lengkap.

Jika seseorang belum memilikinya, maka Anda dapat melihat di web atau mengunduh. Saya memperingatkan Anda, mereka berayun dari sini , masih dengan bantuan Mercurial, dan masih akan memakan waktu sekitar setengah jam.

File yang kita butuhkan ada di src/java.base/share/native/libjava/System.c .

Melihat bahwa ini adalah jalur ke file, dan bukan hanya namanya? Itu benar, Anda dapat mendorong Ide modis mengkilap baru Anda, dibeli seharga $ 200 setahun. Anda dapat mencoba CLion , tetapi untuk menghindari kerusakan mental yang tidak dapat dipulihkan, lebih baik mengambil Visual Studio Code . Dia sudah menyoroti sesuatu, tetapi masih tidak mengerti apa yang dilihatnya (dia tidak mencoret semuanya dengan warna merah).

Menceritakan kembali System.c :

 java_props_t *sprops = GetJavaProperties(env); PUTPROP(props, "os.version", sprops->os_version); 

Pada gilirannya, mereka diambil dalam src/java.base/unix/native/libjava/java_props_md.c .
Setiap platform memiliki file sendiri, mereka beralih melalui #define .

Dan ini dia mulai. Ada banyak platform. Setiap necrophilia seperti AIX dapat dinilai, karena GraalVM tidak secara resmi mendukungnya (sejauh yang saya tahu, GNU-Linux, macOS dan Windows direncanakan pada awalnya). GNU / Linux dan Windows mendukung penggunaan <sys/utsname.h> , yang memiliki metode yang telah ditentukan untuk mendapatkan nama dan versi sistem operasi.

Tapi macOS memiliki govnokod yang mengerikan .

• Nama "Mac OS X" di-hardcoated (meskipun sudah lama menjadi macOS);
• Itu tergantung pada versi makoshi. Sebelum 10.9, SDK tidak memiliki fungsi operatingSystemVersion , dan Anda harus membaca SystemVersion.plist tangan;
• Untuk pengurangan ini, ia menggunakan ekstensi ObjC seperti ini:

 // Fallback if running on pre-10.9 Mac OS if (osVersionCStr == NULL) { NSDictionary *version = [NSDictionary dictionaryWithContentsOfFile : @"/System/Library/CoreServices/SystemVersion.plist"]; if (version != NULL) { NSString *nsVerStr = [version objectForKey : @"ProductVersion"]; if (nsVerStr != NULL) { osVersionCStr = strdup([nsVerStr UTF8String]); } } } 

Jika awalnya ada ide untuk menulis ulang ini secara manual dalam gaya yang baik, maka dengan cepat menabrak kenyataan. Bagaimana jika saya mengacaukan suatu tempat di hutan mie ini dari jika, seseorang akan memecahkannya, dan mereka akan menggantung saya di alun-alun? Baik nafig. Perlu menyalin-tempel.

Kesimpulan

• IDE tidak diperlukan;
• Setiap komunikasi dengan C ++ menyakitkan, tidak menyenangkan, tidak dipahami pada pandangan pertama.

Copy-paste adalah norma?

Ini adalah masalah penting di mana jumlah siksaan lebih lanjut tergantung. Saya benar-benar tidak ingin menulis ulang secara manual, tetapi sampai ke pengadilan karena melanggar lisensi bahkan lebih buruk. Jadi saya pergi ke github dan bertanya langsung kepada Codrut Stancu. Inilah yang dia jawab :

»Menggunakan kembali kode OpenJDK, misalnya, salin-tempel adalah hal yang normal dari sudut pandang perizinan. Namun, ada alasan yang sangat bagus untuk ini. Jika suatu fitur dapat diimplementasikan dengan menggunakan kembali kode JDK tanpa menyalin, misalnya, menambalnya dengan substitusi, itu akan jauh lebih baik. "

Kedengarannya seperti izin salin-tempel resmi!

Kami berbicara secara normal ...

Saya mulai porting kode ini, tetapi berlari ke kemalasan saya. Untuk menguji macOS untuk versi yang berbeda, Anda harus menemukan setidaknya satu dengan Singa Gunung necrophilic 10.8. Saya memiliki dua perangkat apple saya yang tersedia dan satu dari seorang teman, ditambah lagi saya dapat menyebarkannya ke beberapa VMWare percobaan.

Tapi kemalasan. Dan kemalasan ini menyelamatkan saya.

Saya pergi ke ruang obrolan dan bertanya kepada Chris Seaton toolchain mana yang paling cocok untuk perakitan. Versi OS mana yang didukung, kompiler C ++, dan sebagainya.

Sebagai tanggapan, dia menerima kesunyian yang mengejutkan dari obrolan dan Chris menjawab bahwa dia tidak mengerti inti dari masalah tersebut.

Butuh waktu sebelum Chris bisa mengetahui apa yang ingin aku lakukan, dan memintanya untuk tidak melakukannya lagi .

Itu benar-benar melewatkan ide SVM. SVM adalah Java murni, tidak seharusnya kode dimasukkan ke dalamnya dari OpenJDK. Anda dapat membacanya, mengubahnya menjadi Java, tetapi tidak ada yang menginginkan kode C ++ dari OpenJDK. Itu hal terakhir yang kita inginkan.

Contoh perpustakaan matematika tidak meyakinkannya. Paling tidak, mereka ditulis dalam C, dan dimasukkannya C ++ berarti menghubungkan bahasa yang sama sekali baru ke basis kode. Dan satu yang fufufu.

Apa yang perlu kamu lakukan? Tulis di System Java .

Dan jika panggilan ke C / C ++ Platform SDK tidak dapat dihindari, maka ini haruslah panggilan sistem tunggal yang dibungkus dalam C API. Data ditarik di Jawa dan kemudian logika bisnis ditulis secara ketat di Jawa, bahkan jika Platform SDK memiliki cara siap pakai yang nyaman untuk melakukannya secara berbeda di sisi C ++.

Saya menghela nafas dan mulai mempelajari kode sumber untuk memahami bagaimana hal ini dapat dilakukan secara berbeda.

Kesimpulan

• Berbicara dengan orang-orang dalam obrolan tentang detail yang tidak jelas. Mereka menjawab jika pertanyaannya tidak sepenuhnya bodoh. Meskipun contoh ini menunjukkan bahwa Chris siap untuk membahas masalah-masalah konyol, bahkan jika ini tidak menghemat waktu secara pribadi;
• C ++ sama sekali tidak ada dalam proyek. Tidak ada alasan untuk percaya bahwa seseorang akan membiarkannya menyeretnya ke bawah lantai;
• Sebagai gantinya, Anda perlu menulis di System Java menggunakan C sebagai upaya terakhir (misalnya, saat memanggil platform SDK).

Pemain biola tidak diperlukan

Seorang pemain biola tidak diperlukan, sayang. Dia hanya makan bahan bakar berlebih.

Kemudian saya diliputi kesedihan, karena lihat di sini. Jika pada Windows kita memiliki <sys/utsname.h> , dan kita dengan bodoh berharap untuk jawabannya - mudah dan sederhana.

Tetapi jika dia tidak ada di sana, apa yang harus dilakukan?

• Panggil perintah built-in cmd atau utilitas Windows? Mengeluarkan teks dalam bahasa Rusia yang perlu diuraikan. Ini adalah yang paling bawah, dan mungkin tidak sesuai dengan apa yang akan dijawab OpenJDK di tempat ini.
• Ambil dari registri? Bahkan di sini ada nuansa, misalnya, ketika beralih dari Windows 7 ke 10, metode penyimpanan angka digital di Registry berubah, dan di Windows 10 Anda perlu merekatkan tangan dari komponen utama dan kecil, atau hanya menjawab bahwa itu adalah Windows 10 dengan satu digit. Manakah dari metode ini yang lebih benar (tidak akan membuat penilaian pengguna bertobat) tidak jelas.

Untungnya, kesedihan saya terganggu oleh pencarian-tarik Paul Woegerer, yang memperbaiki semuanya.

Menariknya, pada awalnya semuanya diperbaiki dalam wizard (versi. Ops berhenti memberi null dalam tes), dan hanya kemudian saya melihat permintaan pullre. Masalahnya adalah komit ini tidak ditandai di github sebagai pullrequest - ini adalah komit sederhana dengan tulisan PullRequest: graal/1885 dalam komentar. Faktanya adalah bahwa dudes di Oracle Labs tidak menggunakan Github, mereka hanya membutuhkannya untuk berinteraksi dengan committer eksternal. Kita semua yang tidak cukup beruntung untuk bekerja di Oracle Labs perlu berlangganan notifikasi komitmen baru ke repositori dan membaca semuanya.

Tetapi sekarang Anda dapat bersantai dan melihat bagaimana menerapkan fitur ini dengan benar .

Mari kita lihat binatang apa ini, Sistem Java.

Seperti yang saya katakan sebelumnya, semuanya sederhana, seperti bagian belakang sekop, ketika mereka mencoba mencabut gigi Anda. Dan sama menyakitkannya. Lihatlah kutipan dari kolam:

 @Override protected String osVersionValue() { if (osVersionValue != null) { return osVersionValue; } /* On OSX Java returns the ProductVersion instead of kernel release info. */ CoreFoundation.CFDictionaryRef dict = CoreFoundation._CFCopyServerVersionDictionary(); if (dict.isNull()) { dict = CoreFoundation._CFCopySystemVersionDictionary(); } if (dict.isNull()) { return osVersionValue = "Unknown"; } CoreFoundation.CFStringRef dictKeyRef = DarwinCoreFoundationUtils.toCFStringRef("MacOSXProductVersion"); CoreFoundation.CFStringRef dictValue = CoreFoundation.CFDictionaryGetValue(dict, dictKeyRef); CoreFoundation.CFRelease(dictKeyRef); if (dictValue.isNull()) { dictKeyRef = DarwinCoreFoundationUtils.toCFStringRef("ProductVersion"); dictValue = CoreFoundation.CFDictionaryGetValue(dict, dictKeyRef); CoreFoundation.CFRelease(dictKeyRef); } if (dictValue.isNull()) { return osVersionValue = "Unknown"; } osVersionValue = DarwinCoreFoundationUtils.fromCFStringRef(dictValue); CoreFoundation.CFRelease(dictValue); return osVersionValue; } 

Dengan kata lain, kita menulis dalam bahasa Jawa kata demi kata apa yang akan kita tulis dalam C.

DarwinExecutableName bagaimana DarwinExecutableName ditulis:

  @Override public Object apply(Object[] args) { /* Find out how long the executable path is. */ final CIntPointer sizePointer = StackValue.get(CIntPointer.class); sizePointer.write(0); if (DarwinDyld._NSGetExecutablePath(WordFactory.nullPointer(), sizePointer) != -1) { VMError.shouldNotReachHere("DarwinExecutableName.getExecutableName: Executable path length is 0?"); } /* Allocate a correctly-sized buffer and ask again. */ final byte[] byteBuffer = new byte[sizePointer.read()]; try (PinnedObject pinnedBuffer = PinnedObject.create(byteBuffer)) { final CCharPointer bufferPointer = pinnedBuffer.addressOfArrayElement(0); if (DarwinDyld._NSGetExecutablePath(bufferPointer, sizePointer) == -1) { /* Failure to find executable path. */ return null; } final String executableString = CTypeConversion.toJavaString(bufferPointer); final String result = realpath(executableString); return result; } } 

Semua CIntPointer ini, CCharPointer , PinnedObject , apa.

Menurut selera saya, ini tidak nyaman dan jelek. Anda perlu bekerja secara manual dengan pointer yang terlihat seperti kelas Java. Anda harus memanggil release tepat pada waktunya agar memori tidak bocor.

Tetapi jika Anda merasa bahwa ini adalah tindakan yang tidak dapat dibenarkan , maka Anda dapat melihat lagi penerapan GC di .NET dan merasa ngeri dengan apa yang menyebabkan C ++ jika Anda tidak berhenti tepat waktu. Saya mengingatkan Anda bahwa ini adalah satu file CPP besar yang lebih besar dari satu megabyte. Ada beberapa deskripsi karyanya, tetapi jelas tidak cukup untuk dipahami oleh kontributor eksternal. Kode di atas, meskipun tampak tidak menyenangkan, cukup dapat dipahami dan dianalisis dengan menggunakan analisis statis untuk Java.

Adapun esensi dari komitmen, saya punya pertanyaan untuknya. Dan setidaknya dukungan Windows tidak diterapkan di sana. Ketika codegen muncul untuk Windows, saya akan mencoba untuk mengambil tugas ini.

Kesimpulan

• Perlu menulis di System Java. Puji, sebut roti manis. Masih belum ada opsi;
• Berlangganan pemberitahuan dari repositori di GitHub dan baca komitmennya, jika tidak, PR penting akan terbang;
• Jika memungkinkan, tanyakan tentang fitur besar dari mereka yang bertanggung jawab untuk area ini. Ada banyak hal yang diimplementasikan, tetapi mereka belum diketahui masyarakat umum. Ada kemungkinan untuk menciptakan sepeda, dan jauh lebih buruk daripada yang dibuat oleh orang-orang dari Oracle Labs;
• Saat menangani fitur, pastikan untuk memberi tahu orang yang bertanggung jawab di github. Jika dia tidak menjawab - menulis surat, alamat semua anggota tim mudah di-Google-nya.

Epilog

Pertempuran ini berakhir, tetapi bukan perang sama sekali.

Fighter, dengan sabar menunggu artikel baru tentang Habré dan masuk dalam jajaran kami !

Saya ingin mengingatkan Anda bahwa Oleg Shelaev, satu-satunya penginjil GraalVM resmi dari Oracle, akan datang ke konferensi Joker berikutnya . Bukan hanya "satu-satunya penutur bahasa Rusia", tetapi "satu-satunya yang pada umumnya." Judul laporan ( “Mengkompilasi Java di muka dengan GraalVM” ) mengisyaratkan bahwa SubstrateVM tidak dapat melakukannya tanpa.

Ngomong-ngomong, Oleg baru-baru ini mengeluarkan senjata layanan - sebuah akun di Habré, shelajev-oleg . Belum ada pos di sana, tetapi Anda dapat menggunakan nama pengguna ini.

Anda dapat berbicara dengan Oleg dan Oleg di chat room-chat kami di Telegram: @graalvm_ru . Tidak seperti ishshuyev di Github, di sana Anda dapat berkomunikasi dalam bentuk apa pun, dan tidak ada yang akan diblokir ( tetapi ini tidak akurat ).

Saya juga mengingatkan Anda bahwa setiap minggu, bersama dengan podcast Debriefing, kami membuat rilis Java Digest. Misalnya, ini adalah intisari terakhir . Dari waktu ke waktu, berita tentang GraalVM dilewati di sana (pada kenyataannya, saya tidak mengubah seluruh masalah menjadi rilis berita GraalVM hanya karena menghormati penonton :-)

Terima kasih telah membaca ini - dan sampai jumpa lagi!