Java Kurulumu ve İlk Programımız

Java , , , , , ,

Bir dile yeni başlayanların en hızlı yapmak istediği şey sanırım, bir an önce dil ile ilgili gerekli araçları kurup ilk programı yazıp çalıştırmaktır. İlk programın da ekrana “Hello World” yazması gelenek haline gelmiştir. Biz de benzer yolu izleyelim, makinamıza Java ortamını kurup, ekranımıza “Selam” yazan ilk programımızı yazıp çalıştıralım.

Öncelikle belirtmek gerekir ki Java’ya yeni başlayanların sıklıkla ziyaret etmeleri gereken bir yer var: http://java.sun.com Bu sayfa Java’nın resmi sitesidir ve onunla alakalı en son gelişmeleri daima buradan takip edebilirsiniz. Biz de şimdi bu sayfadan makinamızda Java çalıştırmak için gerekli olan araçları indirebiliriz. Aslında ilk kodumuzu Notepad gibi basit bir editörde yazabileceğimizi düşünürsek, bize gerekli olan iki şey var demektir: Java derleyicisi (compiler) ve yorumlayıcısı (interpreter ya da JVM yani Java Virtual Machine (Java Sanal Makinası). JVM, Java kodlarını çalışma-zamanında (run-time) yorumlayarak çalıştırır.) Java ile alakalı bu iki aracı başka yerlerden de bulmanız mümkündür ama en kısa yoldan Java’nın ana sayfasından indirerek başlayabiliriz. Bahsedilen sayfaya bir tarayıcı üzerinden gittiğinizde, Java SE indirme linkini aramanız gerekli. Sayfanın şu anki yerleşiminde bu link sağdaki sütunde ve Populer Downloads başlığının hemen altında. Burayı tıkladığımızda gittiğimiz sayfada bulunan pek çok indirme linki kafamızı karıştırmasın. İndirmemiz gereken şey Java SE Development Kit ya da diğer adıyla JDK (Java Development Kit). Bu yazının yazılması sırasında Java SE’nin 6. versiyonu var ve geldiğimiz sayfada da JDK’in 6. Versiyonunun 17. güncellemesi (JDK 6 Update 17) için indirme linki var. Buradaki Download linkini tıklayarak gideceğiniz sayfada platformunuzu seçip, şartları kabul vs. için gerekli yerleri tıkladıktan sonra indirmeniz başlayacaktır. İndirme sayfasından da görüleceği gibi buradan Windows, Linux ve Solaris için JDK indirilebilir. Eğer farklı platformlarda çalışıyorsanız Java derleyici ve yorumlayıcısı için o platformların üreticilerinin sayfalarına gitmeniz gerekecektir. Örneğin Apple Mac kullanıyorsanız yapacağınız şey http://developer.apple.com/java/ sayfasına gidip radaki linklerden Java’yı indirmek. Şu anda Mac için Java for Mac OS X 10.5 Update 1 geçerli ve bu da Java SE 6’nın 1.6.0_05 nolu sürümünü içeriyor. Bu arada unutmadan söylemeliyim ki yukarıda bahsettiğim Java’Nın Mac kurulumu 64 bitlik ve sadece Intel işlemci içeren Mac’ler için geçerli. Önceki Power-PC ya da 32 bir Intel işlemci içeren Mac’ler için aynı sayfadaki diğer paketleri indirmeniz gereklidir.

İndirdiğiniz dosya, çalıştırılabilen bir dosyadır (örneğin Windows için şu anda bu dosyanın ismi jdk-6u17-windows-i586.exe’dir, Mac’da JavaForMacOSX10.5Update1.dmg) ve üzerine tıklayarak kurlumu başlatabilirsiniz. (Windows’da ancak yönetici (Administrator) yetkisiyle Java ortamını kurabilirsiniz.) Windows’da çalışıyorsanız JDK büyük bir ihtimalle C:\Program Files\Java adresine kurulacak ve muhtemelen tam adresi C:\Program Files\Java\jdk1.6.0_17\ gibi olacaktır. (Kurduğunuz Java ortamıyla alakalı sürüm notlarına bu adresten ulaşabilirsiniz.)

Kurulum aşağıdaki gibi bir klasör yapısına sahiptir.

Makinanıza Java’yı kurduğunuzda ilk yapmanız gereken şey, Java’yı kurduğunuz klasörün altındaki bin klasörünü (örneğin C:\Program Files\Java\jdk1.6.0_17\bin) sisteminizin Path değişkenine eklemek. Böylece komut satırından Java komutlarına ve araçlarına rahatlıkla ulaşabileceksiniz. (Bunu yapmazsanız Java araçlarını her çalıştırmanızda Java’nın kurulum klasöründeki bin klasörünün adresini komutla birlikte yazmanız gerekecektir.) (Yanılmıyorsam Mac’lerde bunu yapmaya gerek yok, sistem kurulumla birlikte kurulan araç ve komutlara terminal üzerinde erişim sağlıyor.)Bunu yapmak için XP ve Vista’da Start > Control Panel > System (ya da masa üstündeki (desktop) My Computer/Computer ikonuna sağ tık ve en alttaki Properties’den) giderek Advanced system settings’e ulaşabilirsiniz.

Adv. system settings

Daha sonra buradan  Advanced > Environment Variables ‘a gelin ve alttaki System Variables kısmından Path değişkenini işaretleyip Edit düğmesine basın ve Variable value kısmına en sona bin klasörünün adresini ekleyin, kaydedin ve çıkın.

Path setting

Artık Java ortamınız kullanıma hazır demektir. Emin olmak için yeni bir komut satırı (Windows’da CMD, Mac’de terminal, Linux ve Unix’te ise term ya da xterm.) açın ve aşağıdaki komutu yazın:

 

java -version


Bu komut size, sisteminize az önce kurduğunuz Java’nın versiyonunu yazacak. Örneğin aşağıdaki örnekten, JDK’in 1.6 sürümünün 06 nolu minör uyarlamasının ve detayınından daha sonra bahsedeceğimiz HotSpot Client sanal makinasının kurulu olduğunu anlıyoruz.

java version

Şimdi ilk Java programımızı yazmaya hazırız demektir. Yapacağımız şey, bize selam verecek basit bir Java programı yazıp önce derlemek sonra da çalıştırmak.

Önce bir klasör oluşturun, örneğin D:\Java Dersleri. Daha sonra Notepad’i açıp içine aşağıdaki kodu aynen kopyalayın:

 

public class Selam{

   public static void main(String[] args){

      System.out.println("Selam :)");
   }
}

Bu kaynak kodda Selam isimli bir sınıf oluşturduk ve bunun için class anahtar sözcüğünü kullandık. Daha sonra da, ileride üzerinde daha fazla duracağımız bir main metod (foksiyon) yazdık ve içinde “Selam :)” yazacak kod koyduk.

Daha sonra bu dosyayı az önce oluşturduğunuz klasöre Selam.java ismiyle kaydedin.
Sıra, Java derleyicisini kullanarak bu kodu derlemeye geldi. Bunun için kullanmamız gereken komut javac‘tır. Bu komut az önce Path değişkenine koyduğumuz bin klasörünün içindedir ve Java kodlarını derlemekte kullanılır. Komut satırında Selam.java‘nın olduğu klasöre gidin ve aşağıdaki komutu çalıştırın:

 

javac Selam.java



Komut satırında dir dediğinizde artık Selam.java yanında bir de Selam.class isimli bir dosyanın olduğunu farketmelisiniz. Eğer yukarıdaki satırı çalıştırınca hata almışsanız büyük bir ihtimalle kodu Selam.java dosyasına kopyalarken yanlışlık yapmışsınız demektir. Java’ya yeni başlayanlar, Java’nın küçük-büyük harf ayrımı yaptığı gerçeğine alışmakta zorlanmaktalar. Bu yüzden örneğin koddaki Selam, String ve System kelimelerinin büyük harfle başladığından ve dosyanın isminin de sınıfın ismi olan Selam ile aynı olup, uzantısının java olduğundan emin olun.

Oluşan Selam.class Java’nın çalışacak olan ara kodudur. Her sınıf derlendiğinde aynı isimde ama uzantısı class olan bir dosya oluşur. Eğer bu sınıfın içinde bir main metod varsa o sınıf doğrudan çalıştırılabilir. Bizim Selam sınıfımızda zaten tek bir metod var o da main. Bu yüzden bu sınıfın derlenmesinde oluşan Selam.class dosyasını çalıştırabiliriz. Bunun için JVM’i açıp ona Selam.class dosyasını geçmemiz lazım. JVM yani Java’nın yorumlayıcısı ya da bir başka ismiyle Java’nın çalışma-zamanı ortamı java komutuyla başlatılır. Bu komut da yine bin klasöründedir. Selam.class‘ı çalışması için JVM’e geçmek aşağıdaki komutla olur.

 

java Selam


Burada satırda komut olarak java ve geçilen argüman olarak da class uzantısı olmayan sınıf ismi yani sadece Selam olduğuna dikkat edin. Bu komutların nasıl çalıştıkları aşağıdaki resimde gösterilmektedir.

Running Selam

Böylece ilk Java programımızı yazıp çalıştırmış olduk.  Şimdi programınıza ufak tefek değişiklikler yapıp farklı şeyleri ekrana yazmasını sağlayabilirsiniz. Bunun için her değişiklikten sonra kaynak kodunuzu tekrar derlemelisiniz.

 

Toplam görüntülenme sayısı: 37483

Yazılım Hayat Döngüsü: Biraz da Gülelim

Yazılım Mühendisliği , , , , ,

Software Project Life-Cycle Cartoon

Üstteki resim 10 ayrı küçük resimden ya da karikatürden oluşuyor ve her biri, müşteriye özel geliştirilen yazılım projelerinde sıklıkla yaşanan sıkıntıları komik bir şekilde resmediyor. Aslında, hani güldürürken düşündüren şeyler vardır ya tam böyle bir resim bu. Bakınca gülüp geçiyoruz ama gerçekte öyle olmamalı, çünkü halimizin pür melali bu resimler. Ben, bu resmi proje yönetimi, nesne merkezli analiz ve tasarım ya da yazılım mimarileri gibi konuları içeren ders ve konuşmalarda, çok sıklıkla kullanıyorum. “bir resim 1000 kelimeye değer” derler Amerikalılar, bu resimler de öyle. İsterseniz bir geçelim tek tek karelerin üzerinden ve ülkemizdeki tipik bir yazılım projesi üzerine bir hikaye yazalım onlardan.

Bence sondan yani 10. kareden (What the customer really needed – Müşterinin aslında ihtiyacı olan) başlayıp, başa dönerek ilerleyelim. Aslında ihtiyaç basit: Adam ailesiyle birlikte kırlara gittiğinde, çoluk çocuğun eğlenmesi için basit bir lastik salıncak istiyor. Ama iş güç arasında da bu konuda pek de fazla düşünmemiş, düşünmeye fırsat da bulamamış. Bir kaç kelimeyle anlatıyor derdini kendince ve “hani şu salıncaklar olur ya” ya da “bilirsin işte, küçükken sallanırdık” gibisinden cümlelerle, boşlukları karşıdakinin doldurmasını ister şekilde konuşuyor. Bu 1. karede (How the customer explained it – Müşteri onu nasıl açıkladı) anlatılıyor. Ama problem şu ki, 2. karede (How the Project Leader understood it – Proje Lideri onu nasıl anladı) resmedildiği gibi, karşıda onu dinleyen ve bu isteğe göre ona bir salıncak tasarlayıp gerçekleştirecek olan teknik takımın proje lideri olan kişi belli ki çok da salıncakla sallanmamış küçüklüğünde, öyle çok kırsal bir alanda büyümemiş yani, işi pek bilmiyor da denebilir. Ve müşterinin zaten eksik anlattığını akla muhal bir şekilde algılıyor. Proje liderinin algısında öyle bir problem var ki, analist, müşteriyle konuşunca hemen anlıyor ve problemi düzeltiyor, 3. kare (How the Analyst design it – Analist onu nasıl tasarladı). Tabi hep söyleriz analistlere, “müşteri ne istediğini düzgün anlatamaz, siz işin her yönünü düşünerek, onun anlatmak istediğini kerpedenle diş çeker gibi onun ağzından alın” diye. Neyse, cevval analistimiz yöneticisinin olayı tam kavrayamadığını farkeder ve durumu aklınca düzeltir. 🙂

4. karede (How theProgrammer wrote  it – Programcı onu nasıl yazdı) analistten daha cevval olan programcımız, “tamam abi/abla ben onu biliyorum” diye işe koyulur. Zaten analist anlatmaya başlayınca, Anadolu çocuğu delikanlı programcımız, leb demeden leblebiyi anlamıştır. Pek mümkün değildir ya varsayın ki analist, ihtiyaç hakkında tonla belge üretmiş olsun: Kullanım şekilleri (use cases), iş kuralları, her türlü UML diyagramları, iş nesneleri modeli (domain model), aktivite ve ardışıl diyagramlar (aktivity, sequence diagrams) vs. Aslında analist ile programcı arasındaki mimar karesi atlanmış. Analistin analizinde olması muhtemel sıkıntılı noktaları bulan en temel kişidir mimar. (Bu resimlerde mimar olmadığı için tasarım görevi de analiste yüklenmiş ki bu durum zaten çok sıkıntılı. Gerçekte mimar yoksa ve birileri bir tasarım yapacaksa bu kişi daha çok en tecrübeli olan programcı olur.) Düzgün bir mimar olsa zaten programcı da böyle saçmalamazdı. 🙂 Zaten analist ile programcının konuşup kavga etmeden anlaştıkları pek görülmemiştir. 🙂 Neyse belli ki ne kadar doküman olursa olsun hepsini kenara koyan programcımız, “ben zaten biliyorum bunu” diyerekten işe koyulmuş ve analistin anlattıklarındaki problemli noktaları da düzelterek aslında gerçeğe bayağı bir yaklaşmıştı ki test yapmaktan hoşlanmıyor olması, kodda yaptığı ufak tefek hataları görmesini önler.

5. kare (How the Business Consultant described it – İş Danışmanı onu nasıl anlattı) Türkiye’de pek de alışık olmadığımız, iş ile ilgili konularda yardımcı olan danışmanın, geliştirilmekte olan ürünü, müşteriye ve etrafa nasıl anlattığını gösteriyor. 🙂

6. kare (How the project was documented – Proje nasıl belgelendi) her yerde aynı: No documentation at all J Okumayan bir millete yaz demek ne kadar zordur, bilir misiniz? Zaten yazsanız kim okur ki? Niye yazalım o zaman, değil mi? Projelerde yazılmayı hakeden tek şey koddur. Geri kalan ise sadece bürokrasidir, dostlar alış-verişte görsündür. 🙂

7. kare (What operations installed – Canlı ortama hangi yapılar kuruldu) canlı sistemin durumunu anlatıyor: İpe tırmanmak isteyenler için geliştirilmiş bir sistem. Sallanmak isteyen bununla sallansın canım. 🙂 Gerisi arkadan geliyor, şimdilik bununla idare etsin çocuklar, hem bu pazu yapar. 🙂

8. kare (How the customer was billed – Müşteriye nasıl bir fatura çıkarıldı) de bize pek uymuyor. ABD ve Avrupa için daha doğru aslında. Oradaki projeler bizimkilere göre çok daha büyük boyutlarda ve bizim sıklıkla ıskaladığımız iş bölümü kavramını güzel bir şekilde uyguladıkları için projeler çok daha fazla kişiyle yapılıyor. Bir de tabi yazılımcıların yüksek gelir standartları var. Bu yüzden maliyetler ülkemizle kıyaslanmayacak kadar yüksek boyutlarda. Resimde tabi ki abartı var ama anlatmaya çalıştığı şey çok da yanlış değil. Problem, bu durumun ülkemizde pek de geçerli olmamasında. Çünkü ülkemizde proje sahibi olan işletme, proje yapan karşısında genel olarak daha güçlü durumdadır, çünkü alternatifi vardır ve yine genel olarak yazılım kalitesi konusunda çok da bilgili olmadığından, alternatifler arasındaki seçimde maliyetten yola çıkarak karar verir. Bu da proje için teklif veren yazılım evlerinin maça zaten 1-0 yenik başlamaları demektir. Tabi projeyi yapan yazılım evi, maçın rövanşını bakımda alır, kilit (vendor lock-in) denen durum yani. 🙂

9. kare (How it was supported – Canlı sistem nasıl desteklendi) bakım ve destek üzerine. Tabi bakım konusunda da durum çok karmaşıktır: Bakım neyi kapsar örneğin? Hataların düzeltilmesi mi, yeni versiyonlar mı yoksa müşterinin kendine has istekleri mi? Tabi müşteri bunlar arasında pek ayırım yapmama taraftarıdır ve bu durumda da işler karışır. Baştan yanlış anlayış üzerine kurgulandığında projeler, ya zaten bakım  noktasına gelemezler, çünkü öncesinde iptal edilirler ya da geldiklerinde çok ciddi sıkıntılar vardır ve bakımın çerçevesi çoktan değişmiştir.

Son kare zaten olması gerekeni anlatıyor. Belki proje sahibi, projenin son halini görünce, “yok canım benim istediğim sadece şöyle bir şeydi” diyerek bu resmi çiziyor. Adamın kafası net artık, ama çok geç. Zamanında düşünseydi ihtiyacının ne olduğunu, belki problem daha ikinci, en çok üçüncü karede düzeltilirdi.

Bu resimler yazılım projelerinin en temel probleminden bahsediyor: İletişim. Yazılımın kavramsal olan tabiatı, onunla ilgili hemen herşeyin aktarımını zorlaştırır. Aynı masanın etrafında oturan insanlar saatlerce çok temel bir şeyden bahsederler, anlaştık diye masadan kalkarlar ve daha sonra tekrar bir araya geldiklerinde konuşulan ve anlaşıldı zannedilen konu üzerine bir o kadar daha konuşurlar. Sebebi, sadece biz Türklerin, dili yanlış ve etkin olmayan bir şekilde kullanıyor olmamız değildir. Evet biz zaten, “çok belirli bir saatte ve noktada buluşmak” kadar sade ve anlaşılır bir şeyi bile en az 10 dakikalık bir telefon konuşmasında hallederiz ve bu konuşma sırasında da en az 10 defa “oldu”, “tamam”, “ok” cinsinden kelimeler kullanırız. Ama yazılım görülebilen bir şey değil, dolayısıyla da tabiatı itibariyle üzerinde konuşulması zaten zor olan bir alan. Ya Wittgenstein’ın dediği gibi konuşulabilecekler üzerine konuşur, konuşulamayacakları sessizce geçeriz ya da “şeyleri”, konuşulabilecek düzeye çıkarırız.  Aynı masanın etrafında olanlar, iş süreçleri hakkında asgari ve standart bir bilgi birikimine sahip değillerse büyük bir ihtimalle konuşmaya en temel tanımlardan başlamaları gerekir. Ülkemizdeki iş süreçlerinin pek de standart olmaması, her kurumun, işini kendi yoğurt yiyişiyle halletmesi, iletişimi daha da zorlaştırır.

Herhangi bir yazılım projesinden bağımsız olarak, kurumlar, çalışma şekillerini süreç olarak belgelemediği, süreçlerini iyileştirip standartlaştırmadığı, hatta varsa süreç olmayan işlerini tesbit edip, süreç tabanlı hale getirmediği sürece, kendi ortamlarında zaten bir konuşulamaz alan ya da iletişim problemi yaratıyorlar demektir. Böyle bir yapı için yazılım üretmek, süreç tabanlı olmayan, büyük bir ihtimalle de verimli olmayan iş yapış şekillerini, büyük paralar dökerek yazılım ile iyice kemikleştirmekten başka hiçbir işe yaramaz. Yani eskiden kötü olan bir yapı artık kötü bir yazılım sistemine dönüşmüştür. Bu şekilde süreçlerini düzenleyip basit ve standart hale getirmeyen kurumlarda da yazılım projesi yapmak son derece zordur, proje sırasında süreçler mi kurgulanacak ya da iyileştirilecek yoksa yazılım mı gerçekleştirilecek, herşey birbirine girer. Bilgi yönetiminde “gizli” (tacit) denen ve insanların zihinlerinde var olan bilginin, açık ve nesnel (explicit) hale getirilmesidir aslında süreçlerin belirlenmesindeki ilk adım. Ve en zor taraf ta burasıdır zaten. Çünkü bunun önünde, çalışanların kendilerini koruma içgüdülerinden tutun da ifade zorluklarına kadar pek çok zorluk ve engel vardır. Sağlıklı yazılım projeleri, ancak, çalışanların zihinlerindeki bilgileri, asgari miktarda açık ve nesnel hale getirip, süreçlerini standartlaştırmış ortamlarda yapılabilir. Aksi taktirde bir koltukta iki karpuz taşınmaz.

Dolayısıyla, bu resimlerde ifade edilenleri yaşamamak için, projelerde iletişimi daha sağlıklı hale getiren her yol denenmelidir. Önce süreçler belirlenmeli ve sağlıklı bir şekilde uygulanabilir hale getirilmelidir. Sonra da yazılım projesine has, yeteri miktardaki belgeler, eskizler, diyagramlar, sözlükler, prototipler, testler vs. yardımıyla, iletişim sağlıklı olarak yürütülmelidir.

 

Toplam görüntülenme sayısı: 6564

Lost in Translation – Bir Konuşabilse

Diğer , , ,

Dün, sakin bir Pazar akşamında, Trabzonspor – Fenerbahçe maçı öncesini çok güzel bir film ile değerlendirdim: Lost in Translation ya da Türkçe ismiyle Bir Konuşabilse. Başrollerini Bill Murray ile Scarlett Johansson‘un oynadığı filmin yönetmeni Sofia Coppola. Lost in Translation, yönetmenin ikinci filmi olmasına rağmen kendisine 2004 yılında en iyi senaryo dalında Oscar ödülünü kazandırdı.

Kendisini boşlukta ve amaçsız hisseden, çok ünlü ve orta yaşlı bir Holywood aktörünün, bir içki reklamı için Japonya’da geçirdiği üç-beş günü anlatıyor film. Kaldığı otelde karşılaştığı, felsefe mezunu ve çok ünlü bir fotoğrafçıyla, henüz çok genç yaşta ve ne istediğini bilmeden  evlenmiş, 24-25 yaşındaki bir kadının yaşadığı duygusal ilişki konu ediliyor. Aktörle kadın, otelin barında karşılaşıyorlar ve gezerek ve sohbet ederek birlikte vakit geçiriyorlar. Kızın sık ve meraklı sorularına sakin ve o yoldan en az bir kere geçmişliğin getirdiği olgunlukla cevaplar veriyor adam. Ve birbirlerine en son sahne hariç hiç itiraf etmedikleri bir sıcaklık doğuyor aralarında.

Böyle bir filmde beni en fazla etkileyen ve sevindiren şey, Holywood’da, duygusal bir kadın-erkek ilişkisini cinselliğe başvurmadan, sadece sevgi ve paylaşma düzeyinde resmedebilme yeteneğinin henüz ölmemiş olmasını görmemdi. Hatta hayata dair önemli sorular, evlilik ve anlamı ile çocuklar üzerine konuşmanın geçtiği bir oda sahnesi var ki mükemmeldi. Adam ve kadın yatakta, tamamen giyinik haldeler. Ve hayat üzerine sahip oldukları ortak endişeleri, duygusal ve sıcak sözcüklerle paylaşma dışında hiç bir şey yok aralarında, sırt üstü yatan adamın elini kadının ayağının üstüne koyması dışında . Belki de senaryoya Oscar verenleri en çok etkileyen sahne de buydu.

Filmde konu, saf güzellikteki genç bir kadının hayatı sorgulaması ve aklına takılanları, orta yaş krizindeki adamla paylaşması ve adamın az ve öz konuşmasınıyla ilerlerken, hikayenin, komik ve bazen ironik kültür farklılıkları ve Japonca-İngilizce çeviri problemleriyle süslenmesi, filmin, birlikte seyretmeye başladığım kızım ve kız kardeşim tarafından seyre değer bulunmasını sağlamadı ama. Sanırım gençler bu filmde çok az şey bulacaklar ama orta yaştakiler ise tadına bayılacaklar.

İçerikten ziyade her şeyde kabuğa önem veren yüzeysel Türk sinema isimlendirme geleneği ise yine konuyu alakasız bir noktaya çekip, filme sloganik bir isim vermekten çekinmemiş: Bir Konuşabilse. Mesele konuşmak değil ki, paylaşmak.

Mutlaka seyredin…

Toplam görüntülenme sayısı: 1363

Java EE 6 Üzerine – I

Java EE , , , , , , ,

Giriş

Java’nın kurumsal uygulamalar için gerekli bileşenlerini içeren yapısının (Enterprise Edition EE) 6. sürümü piyasaya çıktı. Java EE’nin zaten 5. sürümünde başlattığı ciddi değişimini 6. sürümünde de, daha da geniş bir kapsamda devam ettirdiği görülüyor. Bu değişimin amacını “basitlik ve üretkenliği arttırmak” olarak özetlemek mümkün.

Java, eskiden bu yana basitlik/pratiklik ve üretkenlik ile yapısal ve tabiri caizse akademik olmak arasında, tercihini ikinciden yana kullanmakla eleştirilen bir dil olmuştu. Yani Java, daha karmaşık, daha yapısal ve kullanıcısına daha fazla insiyatif alanı veren ama buna karşın üretim hızının daha uzun vadede iyileştirebileceği bir geliştirme ortamı sağlamaktaydı. Evet nesne yapısı, mimari merkezli yaklaşımı ve mesela tasarım desenlerini yoğun bir şekilde kullanmayı teşvik eden pratikleri ile Java, kullanıcılarına devamlı olarak, çok büyük projelerin altından kalkabileceklerini fısıldamış ve onlara bu özgüveni vermeye çalışmıştı. Ama öte taraftan bu durum, dili ve onun etrafında gelişen bileşenleri, özellikle Java EE’yi bazen aşırı akademik yapmış ve zaman zaman kullananların üretim hızlarına fren de olmuştu. Buna, Java EE’nin en başından bu yana parçası olmuş EJB’leri ve Java nesnelerini ilişkisel veri tabanında kalıcı hale getiren (persistence) çözümlerini örnek olarak verebiliriz. Bu duruma, her ne kadar bu çapta bir kurumsal çerçeveyi (framework) kurma girişiminin ilk örneği olmanın getirdiği toyluk yol açmış olsa da, Sun’ın eskiden bu yana en iyi yaptığını düşündüğüm şey olan, Java toplumunun sesini dinleme ve ondan gelen eleştirilere değer verme tavrı, Java’nın çok daha iyi yerlere gelmesini sağlıyor. Bu durumu, Java’yı en başından bu yana uygulayarak takip eden birisi olarak, taa AWT’den Swing’e ya da Vector ve Hashtable döneminden nefis torba (collection) yapılarına geçişte ya da Javacılara en başlarda ciddi problemler çıkaran performans sorununun HotSpot gibi belki en ileri tekniklerle geliştirilmiş derleyici ile çözülmesinde bizzat yaşadım.

Benzer ilerlemeleri şimdi çok daha geniş bir düzlemde, kurumsal bileşenler düzeyinde yaşıyoruz. Ama kurumsal yapılarda üretkenliği sağlamak, performans problemini bir derleyici ile aşmak kadar yerel bir durum değil, çok daha geniş bir çerçevede ele alınması gerekiyor. Notlandırma (annotation), EJB’lerin 3.0 yapısı ve bu yapıda entity beanlerin artık hayatlarına son verilip, nesne-ilişkisel veri tabanı uyumsuzluğunun JPA (Java Persistence API) ile halledilmesi, bağımlılık zerketme (dependency injection, bu kavramın Türkçe’ye bağımlılık iletimi olarak çevrildiğini gördüm ama benim tercihim bu) gibi Java EE’yi çok daha tanım tabanlı (declarative) yapan desenlerin yoğun bir şekilde kullanılmaya başlanması gibi pek çok yenilik, Java EE’nin yeni sürümlerinin artık üretkenlik odaklı olacağının işaretlerini vermişti. Aslında bu durumu, biraz da 2000’li yılların başından itibaren varlıklarını yoğun bir şekilde hissettiğimiz, çoğu projelerde ürünlerini kullandığımız ve ciddi bir kısmı açık kaynak kodlu, üçüncü sahıs (third party)  girişimlere ve projelere borçluyuz. Örneğin Spring ve Struts gibi çerçeveler, Apache gibi pek çok açık kaynak kodlu projeyi barındıran topluluklar, Toplink, Hibernate ve Castor gibi Java’nın standartları içinde yeterince etkin çözülmeyen konuları halleden ürünler, hepsi Java EE 5’ten itibaren EE’ye ciddi derecede katkıda bulundular. Bu yapılar çoğunlukla geliştirici odaklı oldukları için, ürünlerinde basitlik ve üretkenlik ön plandaydı. Java’nın daha demokratik ve katılımcı tabanlı (Java Community Process, JCP) olarak geliştirilebiliyor olması da, Java toplumundan gelen isteklerin, basitlik, yüksek üretim hızı, rahat genişletilebilirlik gibi ihtiyaçların Java’nın standart bir parçası olmasını sağlıyor.

Java EE 5

Önce kısaca 2006 Mayıs’ında piyasaya çıkan Java EE 5’in neler getirdiğini hatırlayalım: JSR 244 ile gelişen Java 5 EE’nin en temel hedefi basitlikti. Kurumsal uygulamaların daha basit olarak gerçekleştirilebilmesine imkan vermek amacıyla, notlandırma (annotation) özelliğini EE için kullanmaya başladı. Java EE’yi daha tanım tabanlı yapmayı amaçlayan bu özellik, genel olarak bağımlılık zerketme deseni ile uygulanıyordu. Fakat bu özellik, yeni EJB 3.0 sürümü ile eski sürümlerdeki entity beanlerinin yerini alan ve Java nesnelerinin ilişkisel veri tabanında kalıcılığını sağlayan JPA ile Web servisleri tarafında kullanılırken, servlet, JSP ve JSF gibi diğer web bileşenlerinde kullanılmadı.
Web tarafında, 2004 yılı başında J2EE’den bağımsız olarak 1.0 sürümü çıkan JSF, yeni sürümü 1.2 ile Java EE 5’in bir parçası oldu. Ayrıca JSP 2.1 ve Servlet 2.5 sürümleri Java EE 5 içinde yer aldılar. Ayrıca Web Servislerinde ciddi yenilikler içeren sürümler de yer aldı.

Orta katmandaki EJB yapısı, 3.0 sürümü ile daha sadeleştirildi. Örneğin entity beanleri JPA’ye dönüştü ve gerek yönetilen (managed, yani uygulama sunucusu ortamı) gerek ise Java SE ortamlarında kullanılabilecek şekilde yapılandırıldı. JPA 1.0, Java dünyasında nesne-ilişkisel uyumsuzluğuna getirilen standart çözümlerin (JDBC, entity beanleri ve daha sonra da JDO) bir türlü istenileni verememesi ve Hibernate, Toplink vs. üçüncü şahıs çözümlerinin yaygın kullanım alanı bulması üzerine, entity beanlerden vazgeçilip, JDO’nun kenara itilmesiyle yepyeni bir API olarak karşımıza çıktı. JPA’in yapısı da bu konuda, Hibernate ve Toplink gibi revaçta olan pek çok üçüncü şahıs yazılımın katkılarıyla şekillendirildi. Ayrıca JPA’in gerek XML gerek ise notlar ile kullanılabilmesi, geliştiricilere esneklik sağladı.

EJB’ler, 3.0 sürümü ile ciddi bir şekilde basitleştirildi. Örneğin home arayüzlerini kullanma gerekliliği ortadan kaldırıldı. Ayrıca EJB’lerde notlandırmaların kullanılabilemesi pek çok basitliği beraberinde getirdi. Örneğin EJB’lerin içinde bulunduğu kaptan (container) aldığı hizmetler, araya giren sınıflar (interceptor), geri çağrılar (callbacks) ve EJB istemcilerinin (client) kodlanması, notlar sayesinde çok daha kolay hale geldi.

Şimdi Java EE 6’nın yeniliklerine biraz daha yakında göz atalım.

Java EE 6

Hayatına 316 nolu JSR olarak 2007’de başlayan Java EE’nin 6. sürümünün son oylaması Kasım sonunda yapıldı ve 10 Aralık’ta da en son hali, piyasaya sürüldü. Java EE 6’nın hedefleri en başta, genişletilebilirlik (extensibility), profiller, budama (prunning), SOA ve diğer ekler olarak belirlenmişti.

Java EE 6’nın son haline bakınca, yukarıda genişçe bir şekilde açıklanan basitlik ve üretkenliğe yönelik ciddi ilerlemeler ve yenilikler yanında, Java EE’nin üçüncü sahıs çerçeve ve bileşenlerle daha rahat genişletilebilmesi için gerekli yapılara da önem verildiğini görüyoruz. JSR 299 ile gelen ortam ve bağımlılık zerketme (Contexts and Dependency Injection for the Java EE platform) ve bu yapılar ve notlandırma ile kurgulanabilen takılabilir çerçeveler (pluggable frameworks), Java EE 6’nın daha rahat genişletilebilir olmasına hizmet ediyorlar.

Notlandırma

Piyasaya çıkan Java EE 6 basitliği daha da arttırmak için notlandırmaları daha fazla yapıya yaydığı görülüyor. Örneğin artık servletler ve JSF’de de notlama yapmak mümkün. Yani örneğin servletleri ve filtreleri notlarla tanımlayabilecek ve web.xml’e yazmak zorunda kalmayacaksınız. Hatta web.xml’in içeriğini web parçaları sayesinde (web fragment) birden fazla yerde ifade edip, birkaç bin satırlık, devasa web.xml dosyalarından kurtulmuş olacaksınız. JSF’de de managed beanler, notlar ile tanımlanabilecek, etkinlik alanları (scope) belirlenebilecek.


@WebServlet(name="SelamServlet", asyncSupported=true,
urlPatterns={"/selam", "/SelamServlet"})

Bağımlılık Zerketme

Artık bağımlılık zerketme Java’nın içine o kadar girdi ki Java için bununla alakalı olarak JSR 330 altında Dependency Injection for Java adıyla standart bir yapı tanımladı. Yani bağımlılık zerketme amacıyla kendi notlarınızı ve ilgili yapılarınızı tanımlayabileceksiniz. Bağımlılık zerketme desenini Java EE platformunda kullanmak amacıyla da ayrı bir yapıyı JSR 299 altında ve Contexts and Dependency Injection for the Java EE platform adıyla ayrıca tanımlandı. Dolayısıyla mesela nelerin zerkedilebileceğini, @Inject gibi bir not ile belirleyebileceksiniz. Böylece kend geliştirdiğiniz yapıların Java ile rahat ve hızlı bir şekilde kullanımını sağlamış olacaksınız. İlk başta karmaşık gelse de kısa sürede Javacıların bundan faydalanacaklarını düşünüyorum.

Profiller

Bu sürümle ile birlikte Java EE’ye profil kavramı girdi. (Aslında profiller kavramı daha önce web servislerinde de vardı ama bu Java dışında gelişen bir yapılandırmaydı.) Java EE’nin gittikçe büyüyen yapısı, farklı uygulama tiplerine göre farklı yapıları içinde barındıracak şekilde profillendirilecek. Bu amaçla ilk oluşturulan Web profili, web uygulamalarına uygun bir şekilde bir alt bileşen ve API kümesini temsil ediyor ve örneğin JMS, JavaMail, Web Servisleri ile Java Connector Architecture bileşenlerini içermiyor. Web profilinin hangi yapıları içerdiğini daha detaylı bir şekilde bu tablodan görebilirsiniz. Bu durum, zamanında Java’nın da farklı uygulamalar için SE, ME ve EE olarak üçe bölünmesinden başka birşey değil. Böyle bir profil yapısı sanırım, uygulama sunucusu üreticilerin de lisanslarında farklılıklara gitmesini sağlayabilir.

Web

Web tarafında Servlet 3.0, JSP 2.2 ve JSF 2.0 ile gelen diğer önemli yenilikleri şöyle sıralayabiliriz.
• Eş zamanlı olmayan (asynchronous) servletler
• Çalışma zamanında programatik olarak servlet ve filtre oluşturabilme yeteneği
• JSF’lerin daha etkin geliştirilebilmesi için facelet ve şablon (template) yapısı
• JSF bileşenlerinde gömülü (built-in) AJAX desteği

Yukarıdakiler arasında sanırım en önemlisi eş zamanlı olmayan servletler. Yukarıdaki örnekte olduğu gibi @WebServlet notunun bir özelliği olarak tanımlanabilecek olan eş zamanlı olmama özelliği, servletin, işlemekte olan bir metodunun yaptığı diğer metod çağrılarını beklemesine gerek bırakmadan yoluna devam etmesini sağlayacak.

EJB

EJB tarafında da ciddi yenilikler var. Yenilikler daha çok session beanlerini ilgilendiriyor ve amaç da onları, Java EE 5 içinde EJB 3.0 sürümüyle başlayan süreçte,  daha da basitleştirip kullanılabilir kılmak. Bu seferki sürüm 3.1 (JSR 318) ve şu yenilikleri içeriyor:

  • Artık yerel (local) session beanler için arayüz tanımlamaya gerek yok, sadece bean sınıfını tanımlamak yeterli.
  • Bir uygulama için bir tek nesnesinin olması (singleton) garanti edilen session beanleri oluşturmak mümkün.
  • Session beanlerini eş zamanlı olmayacak (asynchronous) şekilde çağırabilmek mümkün.
  • EJBlerinizi artık illa ejb-jar dosyasına koymak zorunda değilsiniz. Örneğin bir web uygulamasının war dosyasının içindeki lib klasörü EJB jar dosyalarını içerebilir.
  • Ve EJBlerin daha hafif bir şekli olan EJB Lite J. EJB Lite, her uygulamada ihtiyaç olmayan, örneğin remote arayüzü ya da timer hizmeti gibi belli EJB özellik ve hizmetlerini budayan ve EJB’lerin daha yalın bir şekilde kullanılmasına izin veren bir yapı. Web profilinde EJB Lite var mesela.

JPA

JPA 1.0 hayatımıza zaten java EE 5 ile girmiş ve biz de onu çok beğenmiştik. Tabi ki bir seferde dört başı mamur bir bileşen yapmak kolay değil. İşte java EE 6’daki JSR 317 ile gerçekleştirilen JPA 2.0 sürümü de irili-ufaklı pek çok eksikliği gideriyor:

  • Nesne-ilişkisel karşılık getirmede bazı yenilikler
  • Soruglama diline (Query Language) bazı ekler
  • Criteri API’si
  • Kilitleme (locking) mekanizmalarıyla alakalı bazı yeni yapılar

Bean Doğrulama

Beanlerinize özelliklerinin değerlerini geçerken çağırdığımız setXxx() şeklindeki metodların içine kodlayarak koyduğumuz doğrulama (validation) kurallarını artık tanım tabanlı yapabileceğiz. Bu amaçla JSR 303 ile oluşturulmuş  Bean Validation API’i doğrulama mantığını koddan çıkarmayı ve tanım tabanlı yapmayı amaçlıyor.

RESTful Web Servisleri

Ülkemizde çok kullanılmasa da gittikçe daha yaygınlaşacağını düşündüğüm RESTful Web Servisleri, JAX-RS adını aldı ve JSR 311 altında geliştirildi. Amaç RESTful web servislerini aynı JAX-WS’de olduğu gibi daha hızlı geliştirebilmek.

Sonuç

Java EE 6’daki özellikler heyecan verici. Bu yeni yapılar ile daha basit yapıda ve hızlı bir şekilde kurumsal geliştirmeler yapmak mümkün olacak. Bu yazıyla Java EE 6’deki yenilikleri özetlemeye çalıştım. İleride geliştirdiğim örnekleri de burada paylaşacağım.

Kaynaklar

Java EE 5

Java EE 6




Toplam görüntülenme sayısı: 1672

«< 70 71 72 73 74 >»