Java 10 Özellikler
Bu blog yazısında Java’nın hızına yetişmeye çalışacağız. Henüz aramızda mecburiyetten Java 6’da takılı kalanlar vardır. Maalesef sizler için üzgünüm. Ancak kişisel çalışmalarımızda yeni özellikleri denememize engel olacak bir durum yok. Bu şekilde eski Java sürümlerindeki sıkıntıları anlamış ve kaçınmış olabiliriz.
Java Sürümlerinin Kurulumu
Elimizin altında en azından Java 8, 9, 10 ve bir kaç ay sonra 11 sürümlerinin olması gerekecek. RVM veya NVM benzeri araçlar gibi Java’ya yönelik de bu işi kolaylaştıracak bir araca ihtiyamız olacaktır. Bunun için SDKMAN’i önerebilirim. JVM üzerinde çalışan bir çok dil ve kütüphanenin farklı sürümlerinin kurulumunu ve kullanımını çok kolaylaştırıyor.
IDE Kurulumu
Java sürümlerinin yeni özelliklerinin desteklenmesi ve kullanımı için IDE desteğine ihtiyaç duyabiliriz. Bunun için de önerim henüz kullanmıyorsanız Intellij IDEA‘ya bir sanş vermeniz olacaktır. IDEA’nın da sürümleri hızlı bir şekilde değişiklere ayak uydurabilmesi için değişmektedir. Buna da ayak uydurabilmek için henüz kullanmaya başlamadıysanız; JetBrains’ın kendi geliştirdiği Toolbox programını kullanmaya başlayabilirsiniz. Sadece IDEA için değil diğer bütün araçlarının kurulum ve güncelleme işlemlerini tek yerden yapabilirsiniz. Araçlar üzerinde yaptığınız kişiselleştirmeler de korunmuş oluyor.
IDEA içerinde Ayarlar -> Editor -> Inspection kısmında Java 10 ile ilgili özellikler aktifleştirebiliriz.
Böylece IDEA bize var
ve tipin açık hali arasında dönüştürme yapmamız için yardımcı olacaktır.
Java ve IDE’mız için en güncel sürümleri kullanmamız veya denememiz için bir sebep yok bence. Biri bir tık ile halledilirken diğeri de sadece bir iki satır komut gerektiriyor.
Java 10 Özellikleri
Şimdi gerekli ortamı sağladıktan sonra yeni özelliklere hızlıca bakabiliriz. Yeni bir çok özellik gelmesine rağmen biz geliştiricileri çoğunlukla ilgilendirecek kısımlar daha az. Genel olarak değişlikler Java platformunu iyileştirmeye yönelik geliştirmeler var.
- JDK reposundaki dağınıklığın toparlanması
- Garbage-Collector arayüzü
- Paralel Full GC for G1
- Application Class-Data Sharing
- Thread-Local handshake
- javah kaldırılması
- Java dilinde yazılmış deneysel JIT-Compiler
Bunların arasında bize direkt olarak ilgilendirecek Local-Variable Type Inference kısmına bakalım.
Local-Variable Type Inference
Metodların parametleri ve gövdesinde tanımladığımız değişkenlerimiz local yani o metodun yerel değişkenleri olmuş oluyor. Peki ‘Type Inference’ ne ola? Bunu belki başka bir yazıda daha geniş bahsedebilirim; ama bazı anahtar kelimelerden bahsedelim.
Dynamic ve static programlama dillerimiz var. Python’ı dinamik, Java’yı statik başlığı altında incelememiz gerekiyor. Python’da bir değişkenin tipini belirtmenize gerek yoktur, programın farklı kısımlarında farklı tipte değerler bile tutabilir. Ancak Java’da yani statik programlama dillerinde tipini belirtiğiniz bir değişkeni başka tipte değerler veremezsiniz(polymorphimizi göz ardı ediyoruz). Derleyici kodunuzu derlemez.
Python kodu yazanlara sorsanız tipleri her seferinde yazmak zorunda olmadıkları için mutlu olduklarını hatta bunu dili kullanmanız için size bir madde olarak sunabilirler. Öbür taraftan Javacılar da derleyicinin desteğini aldıkları için kendilerine ve kodlarına biraz daha güvenirler. Kısacası; inkar edilemeyecek şekilde iki tarafında pozitif yönleri var. Ancak bu pozitif taraflar beraberinde negatif durumları da getiriyor(tip belirtmiyoruz, kod patlıyor; sürekli tip belirtiyoruz; kod patlamıyor). Peki soru: iki tarafın pozitif yönlerini alsak ama negatiflerini geride bıraksak olmaz mı?
Oluyor. Mesela Haskell dilinde tipleri tamamen dokümantasyon için yazmamız beklenir. Haskell derleyicisi bizden tipleri belirtmenizi beklemez. Kodumuzu tipsiz tipsiz yazarız. Scala’da ise orta yollu bir durum vardır. Çoğu durumda ben anlarım, ama bazı kısımlarda(metod/fonksiyon parametleri, recursive durumlar) anlayamıyorum der. Haskell’deki durum Global Type Inference, Scala’daki durum Local Type Inference olarak adlandırılır. Çünkü; Scala sınırlı durumlarda tip çıkarımı yapabiliyor.
Peki güzelimiz Java bu durumun niye gerisinde kalsın? Java 7’de Diamond Operator(<>) yerel tip çıkarımının bir örneğidir. İkinci defa sen yazma ben anlarım diyor bize. Yine aynı şekilde Java 8’de Lambdalarda çoğu durumda tipleri belirtmemize gerek yoktur. Derleyiciler biraz daha akıllı duruma gelip bizim zaten yaptığımız diğer işlemlerden aslında hangi tiple çalışmak istediğimiz çıkarımını yapabiliyorlar. Bu durumun geneline Type Inference deniliyor. Biraz işin arka planından bahsettikten sonra bakalım Java 10 neler oluyor.
var
anahtar kelimesinin Java’ya dahil edilmesindeki motivasyon tamamen gereksiz kod fazlalığını kaldırmak, kodun okunabilirliğini artırmak (geliştiriciye de biraz iş düşüyor).
Hangimiz =
operatörünün hem solunda hem sağında aynı tip belirtmemizin salakça olduğunu düşünmedik ki?
Fonksiyonel olarak Java programlama dilinin çalışmasında bir değişiklik bulunmuyor, sadece Java ile kod yazmayı daha zevkli hale getirebilecek bir özellik (syntactic-sugar).
final var
şeklinde tanımlamalar yaparak başka programlama dillerinde var olan val
anahtar kelimesinin yokluğunu giderebiliriz.
public static void main(String[] args) {
var numbers = List.of(1, 2, 3, 4);
var random = ThreadLocalRandom.current();
var aNum = random.nextInt();
var aName = "Java";
}
Yukarıdaki kod parçasında gördüğümüz gibi ilk durumda List<Integer>
, ikincisinde Random
, üçüncüsünde int
ve sonuncusunun String
olacağı çıkarımı yapılıyor.
Bu kod parçasını Java 10’da ve Java 10 syntax’ını destekleyen araçlar ile denemelisiniz.
Son Olarak
- Bu durumdan Java’nın dinamik olarak bir şeyler yaptığı sonucu çıkarılmamalı. Her şey eskiden olduğu gibi derleyicinin onayından geçiyor, yani statik olarak kontrol ediliyor.
- Çalışma zamanında (run-time) yapılan bir işlem değil, derleme zamanında (compile-time) yapılan bir işlem.
- Sadece local yani metod değişkenleri için geçerli bir durum bu. Sınıf içerisindeki alanlar(field) için geçerli değil.
Bu özelliğin hayatımızı kısmen iyileştireceğine düşünüyorum. Ancak dikkatli bir şekilde kullanılmaması kodun okunabilirliğini ve sürdürülebilirliğini olumsuz bir şekilde etkilecektir. Böyle bir tartışma olduğundan dolayı şu linkte Java mimarları tarafından oluşturulmuş bir tavsiye listesi mevcut. Bu yeni özelliği kullanmadan önce bu listeyi okumak ileride meydana gelebilecek baş ağrılarını engellecektir.
Sizin bu yeni özellikler veya Java’nın gidişatıyla ilgili fikirleriniz nelerdir?