Hari ini di studio virtual kami, pembicara paling terkenal di dunia untuk Spring adalah Josh Long.

Laporannya membuka konferensi Jawa di seluruh dunia. Dialah yang menjawab pertanyaan komunitas, melakukan Tips Musim Semi di YouTube, itu adalah "Minggu ini di Musim Semi" yang kita baca setiap minggu dan banyak lagi.

Ngomong-ngomong, Josh mengizinkan untuk menggunakan semua materi dalam “This week in Java” kita sendiri, tetapi dia membuatnya dalam volume dan kedalaman sedemikian rupa sehingga data ini tidak pernah dapat dikompres ke format “15 menit digest”.

Kadang-kadang tampaknya dia ada di semua kota pada saat yang sama, membaca laporan dan menulis artikel pada satu saat. Hari ini kita akan mencari tahu bagaimana dia melakukannya. Kita belajar tentang "kode yurisdiksi", alasan vitalitas Spring yang luar biasa dan bagaimana ia berhasil hidup bertahun-tahun tanpa penulisan ulang global dari awal dan trik menarik lainnya.

Anggota

Josh Long, Spring Developer Advocate at Pivotal

Evgeny Trifonov, Oleg Chirukhin - editor Grup JUG.ru

Semua orang tahu bahwa Anda sering bepergian, tetapi akan menarik jika Anda bisa memberikan statistik - berapa banyak konferensi yang Anda hadiri tahun lalu, berapa banyak penerbangan yang Anda buat dan sejenisnya.

Pertanyaan yang bagus Saya memiliki tabel yang mencatat semua pertemuan yang saya hadiri tahun ini. Asisten saya, Tasha, membantu saya mengatur jadwal dan tabel ini. Jadi, mari kita buka tablet ini di telepon ... Dua ratus empat puluh. Pada tahun 2018, saat ini, saya menghadiri 240 acara yang berbeda. Beberapa pertemuan ini berlangsung secara online (seperti kami), tetapi saya harus terbang ke sebagian besar. Lebih dari tahun ini, saya terbang lebih dari setengah juta mil. Biarkan saya memeriksa jarak dari Bumi ke Bulan ... Itu 239 ribu mil, sehingga saya bisa terbang ke Bulan dan kembali.

"Ke Bulan dan kembali dari Musim Semi." Judul yang bagus untuk buku Tolkien.

Apakah maskapai menawarkan Anda penawaran istimewa karena Anda banyak terbang?

Yah, saya tidak mengeluh tentang layanan ini. Saya sering terbang dengan United Airlines dan mereka memiliki program Layanan Global. Anda bisa sampai di sana hanya dengan menerima undangan - Anda sendiri tidak bisa memintanya sendiri, dan kriteria apa yang tidak diketahui. Setiap tahun mereka mengundang orang yang paling sering terbang. Tahun lalu, seseorang mengatakan bahwa mereka memilih 1% dari pelanggan paling sering di seluruh dunia. Atau mungkin mereka menyaring berdasarkan jumlah biaya. Dengan satu atau lain cara, mereka memperlakukan saya dengan sangat baik. Ini bagus Tetapi bahkan dalam kasus ini, saya pikir, bagi kebanyakan orang, penerbangan adalah beban. Itu jelas membuatku khawatir. Saya tidak terbang untuk penerbangan itu sendiri, tetapi untuk bertemu orang-orang yang menggunakan Spring. Saya akan teleport jika ada kesempatan seperti itu. Hidup akan jauh lebih sederhana dan lebih menarik.

Alasan bagus untuk menunggu Hyperloop.

Ya, tetapi ini harus menunggu lama.

Mari kita bicara tentang topik yang lebih dekat ke Spring. Anda membicarakannya dengan orang-orang di seluruh dunia - adakah perbedaan regional dalam prevalensinya?

Saya tidak akan mengatakannya. Spring selalu menjadi sumber terbuka 100%, dan selama orang menulis perangkat lunak yang berfungsi di Internet, Spring akan terus menjadi sukses di seluruh dunia. Benar, ada proyek sumber terbuka lainnya di mana kekhasan daerah terlihat. Saya tidak dapat mengonfirmasi statistik sekarang, tetapi bagi saya sepertinya GridGain sangat umum di Rusia.

Ya itu benar.

Dan di China, MyBatis sangat populer. Di Amerika Serikat dan Eropa, saya belum melihatnya selama 10 tahun, dan di Cina itu sama lazimnya dengan Musim Semi. Dan, pada kenyataannya, tidak ada yang salah dengan MyBatis, ini cepat dan kuat - jadi mengapa tidak menggunakannya?

Kami melakukan proyek di mana MyBatis bekerja dengan GridGain, ada di dalamnya.

(tertawa) Jadi Anda menggunakan keduanya - bagus! Saya suka kedua teknologi ini. Tidak ada dukungan normal untuk MyBatis, dan saya terus-menerus bertanya berbagai perusahaan besar di China yang melakukan hal-hal luar biasa - mengapa mereka membutuhkan MyBatis dengan Spring? Ada banyak opsi lain, Hibernate berfungsi dengan sangat baik, dan MyBatis praktis tidak digunakan di Barat. Akibatnya, saya memutuskan bahwa sekali program digunakan, maka perlu untuk memastikan operasi normal. Jika Anda melihat sumber Spring Boot Starter untuk MyBatis sekarang, Anda akan melihat nama saya di sana. Saya ingin mereka yang membutuhkan program ini di timur untuk dapat bekerja secara normal dengannya. Secara umum, sebagian besar pekerjaan saya berasal dari jenis penemuan yang saya buat di berbagai negara selama perjalanan saya.

Anda adalah Advokat Pengembang Penting untuk proyek Musim Semi. Apa artinya ini dalam praktik? Apa yang sebenarnya kamu lakukan?

Pertanyaan yang sulit. Konsep Advokat Pengembang telah menyebar berkat Apple dan, khususnya, Microsoft. Itu dimulai sekitar 30 tahun yang lalu, ketika Microsoft menyadari bahwa itu adalah pengembang yang memiliki kekuatan nyata. Jika Anda ingin platform Anda sukses dan bermanfaat, Anda perlu pengembang untuk membuat hal-hal baru yang berharga di platform ini. Karenanya, Anda harus meyakinkan mereka tentang manfaat platform Anda. Microsoft mulai mencoba memotivasi pengembang dengan sejumlah cara berbeda. Mereka membuat Visual Studio sangat murah, yaitu, mereka menyediakan alat yang terjangkau. Mereka menciptakan banyak API yang sangat menarik yang dapat Anda gunakan di Windows. Secara umum, Microsoft menyadari bahwa perlu berkolaborasi dengan komunitas. Orang tidak mempercayai perangkat lunak, tetapi orang lain. Orang tidak memiliki ikatan emosional dengan perangkat lunak. Anda dapat membayangkan sebanyak mungkin bahwa Anda akan menjadi terkenal hanya dengan menulis sebuah program dalam kesendirian di kamar hotel Anda, dan siapa pun yang membutuhkannya akan menemukan sendiri dokumentasinya. Tetapi pada kenyataannya ini biasanya tidak terjadi. Bagian penting dari tanggung jawab saya adalah berkomunikasi dengan orang-orang dari komunitas. Saya mendengarkan apa yang dikatakan orang dan membawanya ke pengembang, dan kemudian menyampaikan kepada komunitas apa yang dikatakan pengembang. Dengan kata lain, saya adalah sejenis kendaraan.

Tim Spring itu aneh dan cantik. Dia sudah lebih dari satu setengah dekade. Pada awalnya, dia sangat kecil, dan pengembang sendiri terlibat dalam konsultasi. Mereka terus-menerus bekerja dengan tim lain, membantu mereka membuat perangkat lunak mereka sendiri, yaitu, mereka memecahkan masalah nyata, dan tidak duduk terkunci di menara gading. Mereka tidak berpura-pura tahu sebelumnya apa perangkat lunak yang dibutuhkan, tetapi menulis apa yang benar-benar dibutuhkan orang lain, dan keuntungan mereka selalu menjadi kriteria utama mereka. Mereka berbagi dengan klien mereka tentang penderitaan mereka dalam menyelesaikan masalah. Kami tidak menciptakan hal-hal yang tidak berguna. Dan ini, seperti yang Anda tahu, sering menjadi masalah saat membuat perangkat lunak. Bahkan, tim Spring pertama sudah terdiri dari Pengembang Advokat. Mereka tidak mirip dengan apa yang biasanya mewakili programmer. Ya, mereka adalah pengembang yang berbakat, tetapi pada saat yang sama mereka dengan bersemangat mendiskusikan ide-ide mereka dengan orang lain, menghadiri presentasi, bertemu orang-orang, berkenalan, dan melakukan dialog. Berkat ini, Spring dengan cepat mendapatkan popularitas besar.

Masalahnya adalah bahwa pendekatan ini tidak memiliki skala yang baik. Tidak mungkin bagi semua pengembang menghabiskan sebagian waktu mereka untuk bepergian, mengobrol, dan bertemu. Pada saat saya bergabung dengan tim, saya sudah menulis kode untuk Spring, karena ini adalah proyek open source. Selain itu, saya sudah menerbitkan buku, saya menulis artikel dan membuat presentasi. Jadi saya sudah mencoba memperkenalkan Spring kepada komunitas sebaik mungkin dan memberi kesempatan sebanyak mungkin orang untuk mengetahuinya. Oleh karena itu, tim Spring mengundang saya untuk melakukan hal yang sama, tetapi secara berkelanjutan dan untuk uang. Saya pikir saya 80% Pengembang Advokat dan 20% programmer, sedangkan tim Pengembang Advokat lainnya adalah 20% dan 80% programmer.

Secara keseluruhan, tugas saya adalah tetap berhubungan dengan komunitas, dan ada banyak cara untuk melakukan ini. Saya menulis buku keenam saya, disebut The Reactive Spring Book; yang sebelumnya diterbitkan oleh O'Reilly bernama Cloud Native Java. Saya membuat banyak tutorial video yang dapat Anda tonton di Safari Books Online , yang masing-masing membutuhkan 4-5 jam. Selain itu, setiap hari Rabu saya memposting video Kiat Musim Semi di YouTube , yang masing-masing didedikasikan untuk aspek sempit tertentu dari ekosistem. Mereka biasanya berlangsung dari 45 menit hingga satu jam, setiap tahun saya melakukan setidaknya dua musim, kadang-kadang tiga. Jadi, dari tahun ke tahun, setiap dua minggu saya menyiapkan bahan yang cukup untuk laporan lengkap di konferensi. Mulai Januari 2011, setiap Selasa, tanpa kecuali, saya membuat entri blog baru, "This week in Spring" , di mana saya meninjau semua yang paling menarik di ekosistem. Saya juga punya blog lain, dua malam terakhir yang saya lakukan hanya itu. Selain itu, saya juga menulis kode dan berbicara di konferensi. Jadi pekerjaan saya termasuk maksimum dari berbagai kegiatan - tetapi saya bisa membatasi diri hanya untuk satu hal. Ada orang yang hanya membuat blog atau membuat video, dan mereka melakukannya dengan sangat baik. Beberapa bahkan tidak bepergian, tetapi mengadakan seminar online. Pendekatan saya berbeda dari yang lain, tetapi, pada akhirnya, semua kegiatan ini mengejar tujuan yang sama.

Ngomong-ngomong, tanggung jawab saya juga termasuk membuat tutorial, blogging, dan sebagainya. Bagi saya itu sangat sulit dan dapat memakan waktu yang sewenang-wenang. Seberapa keras itu diberikan kepada Anda? Katakanlah berapa lama waktu yang dibutuhkan untuk menyiapkan satu video Spring Tips?

Saya lupa mengatakan - Saya mendapat podcast baru, belum ada yang keluar dari sana, tetapi tujuh wawancara sudah disiapkan :-) Adapun waktu untuk persiapan, itu terjadi dengan cara yang berbeda. Jika saya sudah terbiasa dengan topik yang saya putuskan untuk dibahas, maka saya hanya perlu duduk dan merekam semuanya dua atau tiga kali - saya selalu membuat banyak kesalahan. Dibutuhkan sekitar empat jam seminggu sekali, yaitu sedikit. Tetapi dalam kasus lain ini tidak cukup. Kadang-kadang saya mempelajari masalah dan membuat catatan selama berbulan-bulan, dan kemudian memutuskan bahwa karena pekerjaan ini telah dilakukan, mengapa tidak membuat video dari catatan ini. Saya terus-menerus belajar, seperti Anda mungkin. Tetapi situasi di mana saya perlu belajar sesuatu yang khusus untuk video jarang terjadi. Bagian tersulit di sini adalah untuk memutuskan apa yang Anda butuhkan untuk duduk dan mempelajari topik, dan bukan proses belajar itu sendiri.

Terkadang programmer dari tim kami merilis sesuatu yang belum pernah dibuat sebelumnya. Dalam situasi ini, orang, tentu saja, akan memiliki pertanyaan, dan pertanyaan-pertanyaan ini akan jatuh secara default pada programmer. Dan saya bisa membuat video di mana semuanya akan dijelaskan, dan mengunggahnya ke jaringan sehingga orang punya waktu untuk saling mengenal. Jelas, dalam situasi ini, saya juga harus belajar - karena kita berbicara tentang sesuatu yang sama sekali baru.

Berapa banyak proyek saat ini ada di Spring?

Pertanyaan yang bagus Saya pikir beberapa lusin. Ada modul yang sangat khusus, beberapa di antaranya dikembangkan oleh komunitas, beberapa oleh tim Spring di Pivotal, atau perusahaan besar lainnya. Semua dukungan untuk Google GCP dibuat di Google, dukungan untuk Microsoft Azure - di Microsoft. Tetapi banyak - seperti MyBatis, misalnya - sedang dikembangkan oleh masyarakat. Selain itu, kami memiliki modul terpisah, misalnya, Spring Data Neo4j, modul untuk basis data grafik Neo4j. Itu adalah bagian dari proyek Data Spring, tetapi itu dilakukan dalam kolaborasi dengan Neo4j, mereka melakukan pekerjaan utama pada proyek ini, dia hanya tinggal di repositori git kami. Ada banyak contoh seperti itu.

Adapun Spring Boot, kami memiliki mekanisme luar biasa yang bekerja dengannya yang disebut Konfigurasi otomatis. Ini memberi orang cara mudah untuk mengelompokkan apa yang akan mereka kerjakan. Orang tersebut cukup mengunduh file JAR ke classpath-nya, dan secara otomatis ditambahkan ke aplikasi Boot Spring yang sedang berjalan. Ada banyak konfigurasi otomatis seperti itu di ekosistem, saya hanya tidak tahu tentang bagian penting. Mereka bekerja seperti plugin.

Dan bagaimana memahami pengguna dalam semua proyek yang beragam ini? Apakah ada struktur atau ide umum?

Kemungkinan besar, Anda tidak akan membutuhkan semua proyek. Tentukan tujuan Anda, dan pilih proyek yang diinginkan berdasarkan itu. Saya tidak suka ketika orang mencoba untuk "belajar Spring" - ini adalah latihan yang tidak berarti. Pertanyaannya harus diajukan seperti ini: Saya perlu menulis, katakanlah, REST API. Langkah pertama saya adalah menuju ke spring.io/guides , di mana Anda dapat menemukan panduan sederhana dan terjangkau yang membutuhkan waktu 10-15 menit. Ini akan memiliki semua yang perlu Anda ketahui: kode apa yang harus ditulis, di folder mana, bagaimana melakukannya di IntelliJ atau di Eclipse atau di sesuatu yang lain. Kami mencoba menjelaskan semuanya dengan sangat terperinci dan tidak menghilangkan apa pun, karena kami ingin panduan ini dapat diakses oleh semua orang. Apa pun yang Anda lakukan - JMS, Neo4j, keamanan, pemutus sirkuit, Kafka - kami memiliki panduan terpisah untuk setiap topik. Tentukan tugas Anda dan pilih panduan yang sesuai. Anda tidak perlu berpikir tentang Spring, tetapi tentang apa yang akan Anda integrasikan dengan sistem Anda - Spring hanyalah alat yang memungkinkan integrasi ini. Oleh karena itu, tidak ada gunanya dalam "belajar Musim Semi" - Anda harus menggunakannya jika dapat menyederhanakan tugas spesifik Anda.

Apa proyek di Spring, menurut Anda, yang paling menjanjikan? Atau yang paling diremehkan?

Perpustakaan Spring Retry sangat populer. Awalnya dikembangkan di Spring Batch. Saya tidak tahu apakah Anda pernah menggunakan Spring Batch, ini memungkinkan Anda untuk memproses volume besar data yang dikirimkan secara berurutan, misalnya, dokumen dari sistem file, XML, file CSP, dan sebagainya. Dalam satu kasus penggunaan untuk alat ini, Anda membaca catatan dan kemudian menulisnya - misalnya, dari layanan web ke antrian pesan. Pemrosesan data ini bisa memakan waktu berjam-jam, dan akan sangat tidak diinginkan jika sistem, karena satu kesalahan di bagian paling akhir, memutar kembali semua pekerjaan yang dilakukan pada malam hari. Anda tidak bisa melakukan itu. Spring Batch bekerja dengan paket data, ia memproses catatan bukan hanya satu, tetapi sepuluh atau seribu. Bahkan jika pemrosesan ribuan catatan hilang, semua sisanya akan disimpan. Selain itu, saat menulis sistem paket, Anda harus ingat bahwa Anda perlu mengakses layanan lain yang mungkin gagal. Ada Spring Retry untuk ini. Perpustakaan ini memungkinkan Anda melakukan panggilan berulang ke layanan. Selain itu, Anda dapat menggunakan kecepatan rana eksponensial. Selain Spring Batch, Spring Retry juga digunakan dalam Spring Integration, Spring Cloud Stream, Spring Cloud Data Flow. Dalam dua yang terakhir, kami mendukung Spring Retry karena hubungannya dengan beberapa hal lain. Dengan demikian, perpustakaan ini digunakan di banyak proyek Musim Semi, dan saya tidak yakin semua orang tahu tentang itu. Spring Retry adalah perpustakaan yang sangat sering digunakan yang kadang-kadang hanya diabaikan. Secara umum, kami memiliki banyak hal reaktif yang berbeda. Mereka biasanya yang paling menarik.

Mengapa tepatnya reaktivisme?

Kami memiliki reaktivitas di mana-mana. Keuntungan dari Spring adalah Anda dapat memulai dan mengakhiri proyek dengan itu. Minggu ini kami mengumumkan bahwa kami akan mendukung proyek Facebook RSocket . Ini adalah analog sepenuhnya reaktif dari gRPC, tetapi secara signifikan lebih fleksibel. Ini dapat digunakan untuk pub / sub, streaming data, permintaan / tanggapan klien - secara umum, dengan itu Anda dapat menerapkan banyak pola pesan yang berbeda. Dan itu digunakan di Facebook. Ada dua bundel, satu di C ++, yang lain di Jawa. Yang di Jawa ditulis menggunakan Reactor, perpustakaan reaktif kami. Dia menggunakan Salesforce. Tentu saja, ada opsi lain. Pernahkah Anda mendengar tentang gRPC dari Google? Ini sangat berkualitas tinggi dan menarik, tetapi tidak reaktif, secara default tidak bekerja dengan baik dengan tipe reaktif. Salesforce gRPC tidak memiliki kekurangan ini. Dia memiliki kompiler yang menciptakan layanan berdasarkan Spring Reactor. Jadi baik Facebook dan Salesforce dapat mengukur Reactor sesuai kebutuhan mereka.

Reactor sendiri adalah salah satu proyek kami yang paling menarik. RxJava keluar lebih awal, tetapi Reactor adalah yang pertama memberikan dukungan thread reaktif. Ini sebagian besar terjadi karena programmer hebat David Karnock, manajer proyek RxJava, bekerja bersama kami di Reactor. Jadi sebagian besar dari semua hal baru dan menarik yang terjadi di ekosistem kita, entah bagaimana, menyentuh Reactor. Berkat ini, proyek ini menjadi sangat menarik bagi perusahaan yang menciptakan sistem besar. Reactor juga mendasari kerangka Spring WebFlux. Juga, berdasarkan Reactor, kami membuat dukungan untuk olahpesan reaktif, soket web reaktif, Spring Cloud Stream, pemutus sirkuit reaktif, dan sebagainya - semua komponen ini dapat diintegrasikan ke dalam aplikasi reaktif. Anda dapat, tentu saja, hanya menggunakan Spring, tapi saya lebih suka menggunakan seluruh ekosistem dengan tipe reaktif ini.

Selain itu, kami baru-baru ini membuat pengumuman tentang R2DBC - API kami untuk mengakses data berbasis SQL untuk driver jet. JDBC reaktif belum ada. Masalahnya adalah jika Anda menggunakan kode reaktif, maka Anda tidak dapat menggunakan kunci. Jika penguncian digunakan, maka interaksi ini harus ditingkatkan, meningkatkan jumlah utas. Dan ini bertentangan dengan tujuan awal, karena kami hanya ingin menghindari penskalaan dengan menambah jumlah utas - ini terlalu mahal. Oleh karena itu, R2DBC menyediakan abstraksi yang menyediakan akses data reaktif. Ada driver database yang awalnya reaktif - misalnya, Postgres. Jadi Anda dapat menggunakan R2DBC, antara lain, dengan Postgres dan bekerja dengan SQL reaktif tanpa menggunakan kunci, karena Anda tidak memiliki utas. Seluruh topik ini tampaknya sangat menarik bagi saya.

Mungkin Anda bisa menjawab beberapa pertanyaan teknis yang sering diajukan? Salah satu masalah adalah ketika menggunakan beberapa proyek Pegas, banyak anotasi muncul secara bersamaan. Menjadi sulit untuk mengetahui apa yang mereka lakukan - Anda tidak bisa mengkliknya sambil menahan Ctrl dan pergi ke definisi. Bagaimana berperilaku dalam situasi seperti itu?

Ini harus dijalankan dengan opsi `--debug`. Sebagian besar ekosistem Spring sekarang ada sebagai konfigurasi otomatis. Beberapa bagian seperti konfigurasi yang diimpor, jika dalam hal ini Anda mengklik anotasi, Anda akan melihat tulisan `@ Impor`, yang kemudian akan menunjukkan kelasnya. Jika kemudian Anda mengkliknya, Anda akan melihat objek-objek yang dibuat untuk Anda. Tetapi kadang-kadang Spring bertindak melalui mekanisme konfigurasi otomatis - dalam situasi ini tidak ada penjelasan yang dibuat. Hanya ada perpustakaan dan classpath. Maka sangat sulit untuk mencari tahu apa yang terjadi dan mengapa. Tetapi kami ingin membuatnya semudah mungkin bagi orang-orang untuk mengetahui hal ini. Untuk ini, ada parameter `--debug`, yang harus dimasukkan saat aplikasi dimulai. Kemudian Anda akan melihat laporan di mana semua langkah yang dilakukan oleh aplikasi saat startup akan dijelaskan. Aplikasi memeriksa apakah ada beberapa bidang atau kelas, dan, tergantung pada ini, ia memutuskan apakah akan membuat beberapa objek untuk itu atau tidak. Laporan menunjukkan kepada Anda kondisi mana yang dipenuhi, mana yang tidak, dan konfigurasi mana yang tidak bergantung pada pemeriksaan apa pun. Jadi jika, katakanlah, Anda tidak bisa mengerti mengapa koneksi Anda ke Kafka tidak berfungsi, Anda dapat melihat kondisi yang sesuai - mungkin Anda tidak memiliki kelas yang diperlukan di classpath.

Sekarang akan ada pertanyaan trolling kecil. Penentang Spring sering mengklaim bahwa itu adalah penyebab arsitektur berkualitas rendah, karena Anda dapat menggunakan @Autowired mana saja dan di mana saja. Apakah Anda setuju dengan pendapat ini? Sepuluh tahun yang lalu, arsitektur dibuat dalam tiga lapisan, nilai-nilai ditransfer dari konstruktor ke konstruktor, dan DTO dibuat. Dengan Spring, Anda dapat menyingkirkan semua ini. Apakah itu baik atau buruk?

Musim semi adalah alat. Ini memungkinkan lebih banyak orang untuk membuat perangkat lunak yang diproduksi dan bekerja dengan benar, jadi saya tidak berpikir itu berbahaya. Dalam beberapa tahun terakhir, jutaan orang telah membuat aplikasi menggunakannya, dan semuanya berfungsi dengan baik untuk mereka. Menganggap bahwa Spring secara keseluruhan berbahaya adalah tidak masuk akal, pendapat seperti itu tidak bisa disebut bodoh.

Di Spring, Anda dapat membuat kabel yang cukup eksplisit. Jika Anda khawatir tidak akan jelas dari mana objek yang diberikan berasal, Anda dapat mengikatnya sendiri. Anda dapat membuat konfigurasi java di mana satu metode akan memanggil yang lain, dan nilai output dari metode yang disebut akan menjadi bin - Spring akan menanganinya. Bahkan ketika Anda memanggil tempat sampah yang sama berulang kali atau ribuan kali, Anda tidak akan pernah memiliki lebih dari satu tautan jika objek ini adalah singleton. Anda ingin semuanya eksplisit - itu bisa dilakukan. Jika mau, Anda dapat beralih ke opsi yang bahkan lebih membosankan - XML. Intinya adalah bahwa jika Anda tidak ingin menggunakan `@ Autowired`, maka ini dapat sepenuhnya dihindari.

Jika Anda menggunakan Spring Boot dengan cara yang paling umum, maka Anda hanya akan memiliki satu kacang. Anda tahu bahwa Anda memerlukan kacang jenis `ConnectionFactory` - dalam hal ini tidak ada masalah dalam melakukan injeksi berdasarkan jenis. Anda masih memiliki satu objek, Anda tidak akan memiliki dua `ConnectionFactory` untuk satu` Connection`. Anda tidak akan memiliki dua sesi Hibernasi, jadi tidak ada yang mencegah Anda menyuntikkan `HibernateSession` - itu masih ada dalam satu contoh. Jika Anda ingin semuanya eksplisit, Anda dapat menggunakan anotasi `@ Kualifikasi`. Dengan itu, Anda menandai apa yang Anda suntikkan berdasarkan jenis. Ini akan memungkinkan untuk membedakan berbagai implementasi bin dari satu sama lain. Misalkan Anda memiliki layanan yang aplikasi di satu tempat dapat berkomunikasi dengan iTunes, di tempat lain - dengan Amazon, di tempat ketiga - dengan Android Play Store. Ini akan menjadi tiga kacang yang berbeda dari jenis yang berbeda, tetapi masing-masing akan memiliki penjelasan `@ Kualifikasi`. Selanjutnya, anotasi ini dapat ditumpangkan pada anotasi lain, sehingga memastikan keamanan tipe. Anda akan mengikat jenis ini, dan Anda akan memiliki anotasi di atasnya, dan ketika kacang dibuat, ia akan memiliki anotasi `@ Kualifikasi`, termasuk di situs konsumen. Dengan demikian, anotasi ini akan memberi Anda tautan, dan bahkan jika Anda memiliki tiga implementasi saat program sedang berjalan, Anda masih dapat menemukan yang Anda butuhkan.

Artinya, secara umum, menurut Anda, fleksibilitas adalah fitur positif. Apakah Anda dan tim Spring mematuhi beberapa prinsip dasar seperti Zen Zen?

Ya, patuhi. Ngomong-ngomong, saya telah memprogram dalam Python sejak akhir 90-an, dan saya adalah pendukung besar Python Zen, dia memiliki ide umum yang sangat benar. Adapun pertanyaan Anda, di sini Anda perlu berbicara tentang Jürgen Höller, co-pendiri Spring dan pengembang kedua yang bekerja pada proyek tersebut. Ini adalah pria yang baik hati, sangat pendiam, salah satu yang terbaik yang dengannya saya harus berkomunikasi. Sangat mudah untuk berbicara dengannya jika, misalnya, Anda bertemu dengannya di sebuah konferensi. Pada saat yang sama, ia memiliki kecerdasan yang kuat, dan kontribusinya pada Spring sulit ditaksir terlalu tinggi. Konferensi JAX - sangat penting, meskipun, tentu saja, tidak mencapai Joker :) - memberinya penghargaan khusus untuk pekerjaan yang tidak pernah diterima oleh siapa pun kecuali dia sebelumnya. Biasanya penghargaan diberikan dalam beberapa kategori khusus, tetapi yang ini tanpa kategori dan hanya milik Jürgen. Mata air adalah satu-satunya proyek di ekosistem Jawa yang tidak pernah ditulis ulang dalam 15 tahun - karena tidak perlu. Jürgen memiliki ide yang sangat jelas tentang cara menulis modul, cara mengekspresikan tipe, secara umum - cara membuat basis kode berkualitas tinggi yang dapat hidup selama beberapa dekade dan mudah berubah jika perlu. Tidak ada proyek serupa lainnya di ekosistem Jawa. Sebagian besar proyek tidak lagi ada, dan bahkan di antara proyek-proyek yang pernah ditulis ulang dari awal, sangat sedikit yang hidup 15 tahun.

Tanpa ditulis ulang, hanya Spring yang bertahan 15 tahun, karena ditulis dengan sangat rapi sejak awal. Jürgen mengajari kami beberapa prinsip dasar yang kami ikuti: cara membuat modul, cara membuat paket implementasi (sebagai lawan dari bagian publik), cara menggambarkan tingkat permukaan API dan jenis desain untuknya, pola mana yang harus digunakan. Menggunakan Spring, Anda pasti berkenalan dengan pola desain, dan selalu begitu. Contoh pola Pola segera terlintas dalam pikiran. Spring Integration memperkenalkan pola integrasi perusahaan kepada Anda, Spring MVC memperkenalkan MVC. Semua pola ini adalah bagian dari kerangka kerja, dan kami menggunakannya berdasarkan praktik yang telah terbukti. Zen kami adalah prinsip yang diajarkan Jurgen kepada kami. Dalam hal ini, kita semua adalah murid-muridnya. Jürgen dikenal karena pendekatannya yang agak aneh tentang cara menulis kode - karena sikapnya bahkan istilah khusus, "jurgenize" muncul. Tim kami memiliki banyak orang yang sangat pintar dengan pengalaman hebat, beberapa sudah memiliki derajat dan patch botak. Namun demikian, Jürgen membuat perubahan sendiri pada kode mereka. Terkadang hal-hal kecil seperti menambahkan spasi, membersihkan, dan sebagainya, tetapi kadang-kadang itu menulis ulang kode dari awal seribu kali lebih baik, dan pada saat yang sama itu tidak mengubah kepengarangan kode, yaitu, melakukan dengan nama penulis asli. Dalam kasus ini, dikatakan bahwa kode itu "dilegalisasi", yaitu diperbaiki. Berkat Jürgen, kode kami sangat bersih. Untuk alat analisis kode, dianggap sebagai tanda berkualitas tinggi untuk menemukan setidaknya beberapa jenis kerusakan di Spring, karena ada kode yang sangat bersih. Secara umum, saya tidak dapat menetapkan prinsip-prinsip kami secara rinci sekarang, tetapi mereka ada di sana, mereka ditetapkan oleh Jürgen, dan semua proyek Musim Semi mengikutinya. Sedangkan untuk Boot Spring, kami memiliki aturan yang sangat tepat untuk membuat modul, yang kami sebut pemula.

Ok terima kasih atas jawabannya. Pertanyaan terakhir saya adalah tentang kinerja dan Java 11. Sejauh yang saya tahu, Spring selalu menghasilkan konteks dalam runtime. Ini dapat berlangsung dari beberapa menit hingga beberapa jam di beberapa program perbankan lama.

Ayo Saya tidak percaya.

Jujur, dilihat dengan mata kepala sendiri.

Tapi itu tidak mungkin musim semi. Kemungkinan besar, sesuatu yang buruk dilakukan di sana dengan Hibernate. Kacang dapat dihasilkan dalam jutaan, kacang kosong dapat dikompilasi dan dijalankan dengan sangat cepat. Dibutuhkan waktu untuk memuat informasi dari database, validasi, dan sebagainya, ini dapat menyebabkan Spring tertunda. Tapi Spring sendiri sangat cepat.

Ya, saya pikir benar-benar ada semacam horor dengan Hibernate. Namun demikian, Spring dimulai 30 detik, kadang-kadang satu atau dua menit - ini masih cukup lama, bukan begitu? Jika, katakanlah, kita menjalankannya di Docker, maka kita perlu wadah untuk memulai segera. Apakah mungkin untuk mengurangi waktu startup Spring?

Butuh waktu kurang dari dua detik untuk memulai Spring. Dan dengan Fungsi Cloud Spring, kali ini dapat dikurangi menjadi setengah detik atau kurang. Kami memiliki proyek yang berjalan tanpa masalah dalam setengah detik - misalnya, Boot Musim Semi dalam Fungsi Cloud Spring. Jadi, sekali lagi, masalahnya bukan di Spring, tetapi pada apa yang Anda lakukan pada mereka, apa yang terjadi di latar belakang - apakah Anda mendapatkan akses ke sumber data lain di Internet, apakah Anda mengunduh file dari Internet, apakah Anda mengunggah data ke grid . Jika semua yang Anda lakukan adalah layanan microser kecil, maka sistem Anda harus bekerja sangat cepat. Jika aplikasi Anda berjalan untuk waktu yang sangat lama, ada sesuatu yang salah dengannya.

Saya melihat. Omong-omong, apakah Anda pernah mendengar tentang GraalVM dan AOT?

Ya Saya akan memberi tahu Anda lebih banyak: kami memiliki proyek Spring Fu. Dia eksperimental, saya merekam video dari seri Spring Tips tentang dia. Kami menulisnya di Kotlin, sekarang memiliki Java API. Proyek ini dibuat untuk lingkungan seperti GraalVM. Spring Fu tidak menggunakan proksi yang dibuat secara dinamis atau `@ Konfigurasi`. Generator gambar asli di GraalVM perlu tahu kelas mana yang akan dimuat. Tetapi jika Anda memiliki pemuatan dinamis menggunakan cglib atau Byte Buddy, maka ini membuat sulit menggunakan GraalVM. Hibernate, Spring, dan semua perpustakaan lain yang menggunakan proxy yang dihasilkan secara dinamis sangat tidak cocok untuk membuat gambar asli. Oleh karena itu, tidak ada yang seperti ini di Spring Fu, ini dinyatakan secara langsung. Masih menggunakan Spring, tetapi pendekatan untuk membangun aplikasi berbeda. Dan salah satu kelebihan Spring Fu adalah ia bekerja dengan baik dengan GraalVM. Dan sekarang aplikasi dimulai secara instan. Maksud saya, umumnya secara instan: setelah benar-benar ada di memori! Harus diingat bahwa generator gambar asli di GraalVM masih pada tahap pengembangan yang sangat awal. Karena itu, kadang-kadang timbul kesulitan, karena tampaknya orang bahwa aplikasi yang diluncurkan oleh GraalVM akan segera mulai memuat dengan sangat cepat, dan dalam runtime kecepatannya akan sama seperti sebelumnya. Tapi itu tidak terjadi seperti itu, karena pada runtime GraalVM Anda tidak lagi menggunakan JVM, perilaku sistem akan berbeda. Jadi ujilah proyek ini untuk kesehatan, tetapi ingat bahwa ini bukan akselerasi peluncuran gratis. Namun, saya senang dengan GraalVM, tim mereka berusaha keras untuk membuatnya bekerja lebih baik dengan kerangka kerja.

Pertanyaan terakhir saya, tentu saja, tentang Java 11.

Ya, dia cantik.

Apa yang berguna untuk Spring di dalamnya?

Untuk pengembang Spring, ada dua kriteria utama dimana kami memilih teknologi ini atau itu: 1. apakah itu cocok untuk kebutuhan bisnis, 2. apakah itu cocok untuk kita sebagai programmer. Adapun kriteria pertama, apakah teknologi ini memberikan kecepatan, stabilitas, apakah memiliki dukungan jangka panjang. Semua ini ada di Jawa 11. Dukungan untuk Java 8 akan segera berakhir, jadi masuk akal untuk meningkatkan ke rilis berikutnya dengan dukungan jangka panjang. Ngomong-ngomong, teman-teman saya, jika Anda meningkatkan ke versi berikutnya, mengambil perakitan OpenJDK - itu sangat baik dalam segala hal. Versi yang benar sangat mudah didapat, saya sudah menulisnya di Twitter. Rilis ini bekerja sangat baik dengan Spring - stabil. Setidaknya Anda sekarang dapat pergi ke https://start.spring.io , menghasilkan proyek baru, pilih Java 11 dan itu akan berhasil. Dukungan Java 11 tersedia di IntelliJ dan Eclipse.

Adapun kriteria kedua, tidak ada perubahan signifikan untuk pengembang Spring di Jawa 11. Sangat menyenangkan bahwa `var` dan Klien HTTP muncul, tetapi Spring sudah memiliki WebClient reaktif, jadi saya tidak yakin bahwa kita akan mendapat manfaat dari Klien HTTP. Beberapa hal yang mudah ditambahkan di Java 10 dan Java 9. Selain itu, menjadi mungkin untuk menjalankan program Java sebagai skrip - ini tidak buruk. Saya tidak yakin masuk akal untuk melakukan ini dengan Spring - meskipun di sisi lain, mengapa tidak. Bagaimana kelihatannya, saya tidak tahu.

Apakah sulit bagi Spring untuk beralih ke Java 11?

Tidak. Di jantung Spring adalah perpustakaan dan ekosistem yang sangat berkualitas tinggi. Perlu diingat bahwa kerangka kerja Spring itu sendiri mendukung classpath dan modulepath, tapi saya pribadi tidak merekomendasikan menggunakan modulepath. Untuk menggunakannya dengan benar, semua yang lain juga harus mendukung modulepath. Dan ini belum memungkinkan, sekarang ada terlalu sedikit orang yang menyediakan dukungan modulepath di perpustakaan. Mode classpath bekerja dengan sangat baik. Kami memiliki masalah standar dengan CGLib, AspectJ, dan pustaka JAXB XML yang dimiliki semua orang ketika berpindah ke Java 9. Semua masalah ini diselesaikan sekitar tahun lalu, sehingga memudahkan transisi ke Java 11 bagi kami.

Ngomong-ngomong, kami merencanakan banyak hal menarik untuk versi Java di masa depan, misalnya, proyek Loom adalah serat untuk Java.

Apakah di Jawa 12?

Kemungkinan besar tidak, mereka akan melakukan ini selama beberapa waktu.

Kotlin juga menggunakan coroutine, jadi proyek ini sangat menarik bagi kami. Setiap kali dia keluar, dia akan sangat bermanfaat. Kemampuan untuk mengekspresikan pipa reaktif tanpa membuat kode reaktif sangat penting. Secara pribadi, saya menantikan kemunculan String multi-line. Mungkin ini bukan cara terbaik untuk bersaksi kepada saya - Saya punya banyak kode yang membutuhkan banyak baris, misalnya, pertanyaan SQL dan sejenisnya.

Ini karena Anda memiliki bagian penting dari kode yang dioptimalkan untuk peragaan slide. Pada slide selama laporan, akan lebih mudah untuk menampilkan seluruh string di layar.

Ya, kalau tidak maka akan sulit dibaca. Dalam IDE, mereka akan terlihat jauh lebih baik. Sekali lagi, Python, Kotlin, Scala, Groovy - bahasa apa pun dalam 20 tahun terakhir telah memberikan dukungan multi-line String. Menurut saya, ini sangat wajar.

Mungkin Anda ingin memberikan saran kepada pembaca kami? Ini bisa menyangkut Musim Semi atau Penting, dan bisa menyangkut Jawa secara keseluruhan.

Seperti halnya teknologi apa pun, bagian terbaik dari Spring adalah komunitasnya. Secara teknis, Spring adalah serangkaian proyek yang sangat menarik, tetapi rahasia umur panjangnya adalah komunitas yang luar biasa. Tidak ada yang membutuhkan perangkat lunak Anda yang luar biasa jika Anda perlu berkomunikasi dengan orang-orang yang tak tertahankan untuk itu. Karena itu, kami berusaha untuk bersikap ramah. Pengembang kami, termasuk manajer proyek, menjawab pertanyaan tentang Stack Overflow dan mengikuti berbagai tag di sana. Kami memiliki chatroom di Gitter, dan setiap chatroom di dalamnya sesuai dengan repositori di GitHub. Misalnya, https://gitter.im/spring-projects/spring-boot . Di sana Anda dapat menemukan pengembang Spring dan mengajukan pertanyaan yang menarik bagi Anda.

Orang sering bertanya kepada saya bagaimana membantu proyek, bagaimana memulai menulis kode untuk Spring. Kami memiliki banyak masalah dengan tag seperti "ideal untuk kontribusi" di GitHub. Kami senang untuk semua orang, tetapi tidak semua proyek cocok untuk semua orang, beberapa bug lebih rumit daripada yang lain. Jadi, jika Anda ingin bekerja bersama kami, cari tag ini dan bantu masalahnya. Inilah bagaimana pengisian kembali komunitas kami terjadi. Kami menghargai pekerjaan semua orang yang membantu meningkatkan ekosistem kami.

Menit periklanan. Josh Long tiba di konferensi Joker 2018 dengan ceramah Reaktif Spring . Tiket dapat dibeli di situs resmi konferensi .