Malum “jar”, Java’nın arşiv formatıdır. Jar formatında arşiv oluşturmak için gerekli araç “jar” ve diğer Java araçları her JDK kurulumunda vardır ve yerleri de yine malumunuz olduğu üzere JDK’nın bin klasörüdür. Projemize üçüncü el bir bileşen (third party component) eklemek istediğimizde o bileşenin jar dosyalarını classpath’e koymamız yeterlidir. (JDK’le birlikte gelen Java SE’nin bileşenleri de zaten jar dosyası olarak, örneğin rt.jar, makinamıza kopyalanırlar.) Bu en sık yaptığımız işlerdendir. Hatta o kadar ki Java projelerinde kod yazmak değil ama uygun jar sürümlerini bulup bir araya getirmek çoğu zaman daha zor olabilir 🙂

Zaman zaman “jar dosyası nasıl oluşturulur” şeklinde sorularla karşılaşıyorum. Bu yazıda hızlıca hem çalıştırılabilir (executable) hem de çalıştırılabilir olmayan jar arşiv dosyaları nasıl oluşturuluru anlatacağım.

Jar dosyası oluşturmak için gerekli adımları şöyle listeleyebiliriz.

• Masaüstünüzde “Selam” isimli bir klasör açın. Benim makinamda bu “/Users/akin/Desktop/Selam” şekilde bir yola sahip olacaktır.
• Bu klasörde Selam.java and SelamTest.java isimli iki Java kaynak kodu dosyası yaratın. Bu sınıfları buradan alabilirsiniz. Bu iki sınıfın da “org.javaturk.oop.ch01” şeklinde bir pakete sahip olduğuna dikkat edin.
• Bulunduğunuz klasorde “bin” isimli bir başka klasör oluşturun. Derlenmiş class dosyalarımızı buraya koyacağız.
• Sonra bir terminal ya da command line (CMD) açıp Selam klasörüne gidin.
• Sonra bu iki kaynak kodu derlemek için ya şu iki satırı

javac -d ./bin SelamTest.java
javac -classpath ./bin -d ./bin SelamTest.java

ya da bu satırı yazıp çalıştırın:

javac -classpath ./bin -d ./bin *.java

Bu satırlar kaynak kodlarını derleyip, ilgili paket yapısını oluşturacak şekilde class dosyalarını karşı gelen klasörlere yerleştirecektir. Artık Selam’ın altında şöyle bir klasör yapımız var:

bin
|
|__org
    |
    |__javaturk
         |
         |__ oop
              |
              |__ch01
              |
              |__Selam.class
              |__SelamTest.class

• Sonra “/Users/akin/Desktop/Selam” klasöründe aşağıdaki satırı çalıştırın.

jar cvf Selam.jar -C bin/ .

Bu satır “Selam.jar” isminde bir jar dosyası yaratacaktır. Jar dosyasının içeriği ise “bin” dosyasının altındaki klasör ve dosyalardan oluşacaktır.Zaten terminalde “jar” dediğinizde size “c”nin yeni bir jar dosyası yaratmak için, “v”nin jar komutunun çalışması sırasında neler yaptığını çıktı olarak yazması için, f’nin de “Selam.jar” ismin kullanması içın verildiğini anlarsınız. Jar yaratırken en fazla yanlış yapılan nokta, jarın içine girecekleri belirttiğiniz yerdir. Unutmayın “-C”, jar aracından, kendinden sonra gelen “bin/” klasörüne gitmeyi istemektedir. En sondaki “.”yi kesinlikle unutmayın. Eğer o noktanin ilk etapta yanlış yazıldığını düşündüyseniz lütfen bu yazıyı okumayı bırakıp, en temel MS-DOS, Unix ya da Linux kitabı edinip, baştan 20-30 sayfa okuyun. Zira genel olarak “.” bulunduğunuz klasörü, “..” ise bulunduğunuz klasörün ebeveynini gösterir ki bu yazıyı okuyorsanız, bu bilgiyi şu ana kadar öğrenmiş olmanız gerekirdi. Artık elinizdeki Selam.jar dosyasını projelerinizde kullanabilirsiniz. Yapacağınız şey, Selam.jar’i projenizin classpath’ine koymak. Ant ya da Maven gibi yapılar kullanıyorsanız, yapmanız gereken, onların kendi ayarlarını kullanarak Selam.jar’ın olması gereken yere örneğin repositorye gitmesini sağlamaktır. Projenizde kod olarak artık “Selam selam;” gibi bir satır yazdığınızda “import” anahtar kelimesini kullanarak “org.javaturk.oop.ch01.Selam” sınıfı ulaşılır hale gelecektir.

Peki oluşturduğumuz Selam.jar dosyasını nasıl çalıştırılabilir (executable) yaparız? Bir jar dosyasının çalıştırılabilir olması, içinde main metoda sahip olan sınıfın main metodunun çağrılması demektir. Bunun için Selam.jar oluşturulurken içine, main metoda sahip sınıfı ki bizde SelamTest, gösteren bilgi geçilmelidir. Bu bilgi jar aracına “e” ile geçilebilir. Yani şöyle bir satır gereklidir:

jar cvfe Selam.jar org.javaturk.oop.ch01.SelamTest -C bin/ .
 

Bu durumda oluşan Selam.jar dosyasının içine bakarsanız, META_INF klasörünün altında MANIFEST.MF isimli bir dosya olduğunu ve icinde de şu satırların olduğunu görürsünüz:

Manifest-Version: 1.0
Created-By: 1.8.0 (Oracle Corporation)
Main-Class: org.javaturk.oop.ch01.SelamTest

Artik teminalde

java -jar Selam.jar
 

yazarak “Selam Ali :)” çıktısını görebilirsiniz.

Bu jar dosyasını, classpath’e koyup, diğer projelerde kullanılmasını da sağlayabilirsiniz. Ya da işletim sisteminizde bu dosyaya çift tıklayarak java tarafından çalıştırılmasını sağlayabilirsiniz.

Benzer işler için Eclipse, Netbeans vb.geliştirme ortamlarını kullanabileceğiniz gibi Ant gibi araçları da kullanabilirsiniz.

Ayrıca konu ile ilgili Java Tutorial‘da da güzel ve geniş açıklamalar var.

Bol jar’lı günler dilerim 🙂

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

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve bu yazıda ve bu yazıda da ilk iki maddeyi ele almıştık. Şimdi de üçüncü maddeyi ele alalım:

Kodunuzda hiç alan nesnesinin olmaması ya da varsa bile yetersiz ve ince olmaları. (No or very thin domain objects in the code.)

Eğer kodunuzda iş alanınızı modelleyen Müşteri, Hesap, Ürün, Poliçe, Kredi, Olay, Belge, Araç, Başvuru Dosyası ve benzeri nesneleriniz yoksa, bir iş modeliniz de yok demektir. Daha doğrusu, gerçekte var olan işinizin nesnelerle ifade edilmiş bir modeli yok demektir. Nesne-merkezli programlamanın en temel üstünlüğü ya da nesnelerin en fazla görünür olduğu yer aslında dilimizde işin nesne modeli (domain model ya da business domain model) olarak da adlandırdığımız, işin kendi kavramlarının ve aralarındaki ilişkilerin nesne merkezli olarak ifade edildiği durumdur. Böyle bir model, en temel iş terimlerini, özelliklerini ve sorumluluklarını ifade ettiği için son derece değerlidir. Bu modelin öncelikle bir sözlük olarak ifade etmek analiz sürecinde olmazsa olmaz çalışmalardandır. Sonrasında bu sözlüğü, use caselerden yola çıkarak, dilden bağımsız olarak UML class diyagramları ve/veya XML scheması olarak ifade etmek, uygulama geliştiren bir kurumun en temel bilgi teknolojisi değerlerinden olacaktır. Böyle bir çalışma ile kurum, teknik dilindeki tüm kavramları, ozellikleri ve davranışları boyutunda yakalamış olacaktır. Hatta eğilim, farklı ülkelerde hatta tüm dünyada, bazı kuruluşlar öncülüğünde, iş kollarının jargonlarının bu şekilde, platform ya da dilden bağımsız olarak yakalanıp ifade edilmesidir. Bunun da amacı, hızlı ve rahat entegrasyondur tabi olarak. Kurum böyle bir çalışmayla böyle bir modele sahip olduğunda, örneğin bu kurumun yazılımları gerek veri tabanında gerek ise uygulama katmanında, her zaman aynı iş terimlerini aynı şekilde ifade edecektir.

İşin nesne modeli kurgulanmadığında uygulamalar, işin nesne modeli ile ilgili en iyi ihtimalle, aynı nesneleri farklı şekilde ifade ederek ilerleyecektir. Bu durumda da örneğin Müşteri nesnesi, her uygulamada farklı yapılarda olacak ve uygulamalar arası bir entegrasyon söz konusu olduğunda ciddi miktarda “dönüştürme” yükü ortaya çıkacaktır. Özellikle başarılı SOA projelerinin önündeki en temel engellerden birisi, iş kavramlarını farklı şekillerde ifade eden veri tabanı ve uygulamaların birbirleriyle konuşabilmeleri için gerekli “dönüştürme” ya da “yeknesaklaştırma” çalışmalarının, özellikle büyük kurumlar için devasa boyutlara ulaşmasıdır.

Bir kurumda üç aşağı – beş yukarı aynı anlama gelen iş kavramlarının farklı uygulmalarda içerik olarak farklı şekillerde ifade edilmesi, yani bir uygulamanın Müşteri ya da Poliçe dediği kavramı, başka bir uygulamanın çok farklı nesnelerle ve yapılarla ifade etmesi, kurumsal mimari (enterprise architecture) açısından sıkıntılı bir durumdur. Ama hiç olmazsa bu organizasyonel bir problemdir. Bu durumun daha kötüsü şu iki halden birisi olur muhtemelen: İlkinde nesne merkezli bir iş modeli vardır ama bu modeldeki nesneler, sadece veri taşıyıp, diğer nesnelerle get/set metotlarıyla haberleşen dolayısıyla bir önceki maddede açıkladığım gibi, yüksek bir içerik bağımlılığına sahip olan nesnelerdir. Bu durumla sıklıkla karşılaşıyorum ve sebep olarak da nesne merkezli bir iş ve ihtiyaç analizi yapılmaması yanında, nesne kavramını yeterince içselleştirememiş, nesne-merkezli programlama konusunda tecrübe sahibi olmayan programcıları gorüyorum. Bu tür programcılar için nesne, yine bu serideki bir önceki yazımda açıkladığım gibi, bir kaç private alanı bir araya getirip, set/get metotlarını hızlıca oluşturmaya, nesne diyen, ama aslında nesne yerine veriyi modelleyen bir anlayışa sahip programcı arkadaşlarımızdır.

Bu türden nesnelere Martin Fowler “anemic domain model” ya da “kansız iş modeli” diyor. Yani bir model var ama model, iş alanındaki verileri temsil ederken malesef o modelin bir parçası olan davranışları, sorumlulukları temsil etmiyor. Yani model nesne ile kurgulanmış ama ifade ettiği şey, veri, davranışlar değil. Halbuki nesneler veri taşıyandan çok bir davranışa ya da sorumluluğa sahip olan elemanlardır. Verinin davranışlarıyla birlikte bir yerde ifade edilmesi, nesnenin ya da daha temelde sarmalama/encapsulation kavramın tanımıdır. Aksi taktirde tam da bir önceki maddede örneğini verdiğim Date nesneleriniz olur ve tarih ile ilgili davranışlar bir ya da daha çok kereler, “copy-paste reuse” tekniğini iyi bilen ya da birbirinden tamamen habersiz, her şeyi sıfırdan kendisi yapmaya çalışan yazılımcılar tarafından çoğaltılır. Bu da karman-çorman olmuş, anlaşılması zor, değişmesi daha zor olan yazılımlar demektir.

Gerek eğitimlerde gerek ise danışmanlık verdiğim yerlerde çok sıklıkla karşılaşıyorum bu türden durumlara. Account nesnesi var ama withdraw(), deposit() ya da calculateInterest() gibi metotlar Account nesnesi üzerinde değil. Bu gibi metotlar service ya da controller tipinde nesnelerde birikmiş durumda. Bu durumlarda son derece yetersiz, ince ya da zayıf iş nesneleri olurken, devasa boyutlarda, onlarca metota sahip servis nesnelerimiz oluyor. Daha da kötüsü, bu durumda bu türden iş nesneleri ile servis nesneleri arasında içerik bağımlılığı oluşuyor ki karmaşıklık çok ciddi bir engel haline geliyor. Bir nesneye değişiklik yapmak servis nesneleri ve onlar üzerinden diğer nesnelere kadar değişiklik yapmaya sebep oluyor. (Yeri değil ama bu ayırımı, yani veriyi nesneler üzerinde, davranışı ise servisler üzerinde tutmayı, katmanlı mimarinin gereği olarak uyguladığını söyleyenlere kafalarındaki katmanlı mimari ve nesne kavramını gözden geçirmelerini tavsiye ederim. Bu konuda benim şu ve devamı olan şu yazılarıma bakabilirsiniz.)

/**
 * This class represents a banck account anemically. It carries data but no responsibility regarding that data.
 * @author akin
 *
 */
public class Account {

	private String iban;
	private double balance;

	public Account(String iban, double balance) {
		super();
		this.iban = iban;
		this.balance = balance;
	}

	public String getIban() {
		return iban;
	}

	public void setIban(String iban) {
		this.iban = iban;
	}

	public double getBalance() {
		return balance;
	}

	public void setBalance(double balance) {
		this.balance = balance;
	}

	@Override
	public String toString() {
		return "Account [iban=" + iban + ", balance=" + balance + "]";
	}
}

Yukarıdaki gibi bir kansız nesnemiz olduğunda bakın para çekme işlemini nasıl yapıyoruz:

/**
 * This class implements business logic on Account object.
 * @author akin
 *
 */
public class AccountManager {
...
	public void withdraw(Account account, double amount) throws InsufficentBalanceException{
		
		double balance = account.getBalance();
		if(balance >= amount)
			balance -= amount;
		else
			throw new InsufficientBalanceException(account);
	}
...
}

Yukarıdaki AccountManager nesnesi ile Account arasında sadece bilgi akışı olduğuna ve bu durumun aslında en istenmeyen türden bağımlılık yarattığına dikkatinizi çekmek istiyorum. Biz tasarım sırasında temelde iş nesneleri arasındaki ilişkileri nasıl halledelim diye kafa patlatırken bir de böyle bir ilişki yumağı, sistemi berbat etmektedir.

İkinci durum ise, benim eskiden daha sık karşılaştığım, hiç bir nesne modelinin olmadığı, dolayısıyla sadece Java’daki ilkel tipler ile String tipindeki alanların List ve benzeri torbalarla taşındığı yaklaşımdır.

Bu durumda uygulama, ilgili iş kavramının, çoğunlukla veri tabanındaki anahtar alana karşılık gelen bilgisine sahiptir ve diğer bilgileri, bu anahtar bilgi sayesinde ya veri tabanından sorguluyordur ya da uygulamanın diğer parçalarından alıyordur. Ama nihai olarak alınan ve verilen şey nesne değildir, gerçekte nesne olabilecek bilgilerin bölük börçük ifade edilmesidir. Bu durumda aslında nesnelerde ifade edilmesi gereken nesneler arası ilişkiler (associations) de, genel olarak sadece veri tabanında tablolar arasında ifade edilir. Yani kod, tek başına anlaşılabilir bir yapı olmaktan çıkar.  Dolayısıyla örneğin aşağıdaki gibi metotlar çok sık görülür:

...
public ArrayList getVehicle(int id, String [] properties, boolean b){

   List vehicle = new ArrayLIst();
   vehicle.add(id);
   vehilce.add(properties[0]);
   ...
   return vehicle;
}
...

Bu metodun arayüzü, gerçekte Vehicle nesnesinin parçası olan farklı bilgileri, array vb. bölük börçük bilgiler olarak almakta ve yine bölük börçük pek çok bilgiyi bir ArrayList’e koyup geri döndürmektedir. Dolayısıyla iş alanının nesnelerle modellenmesi söz konusu değildir. Bu kodun bir programcı tarafından, ciddi miktarda bilgi desteği olmadan anlaşılması imkansızdır. Örneğin, “vehicle” ismindeki List’in hangi odasında ne var, bunların özellikleri nelerdir vb. bilgiler muhtemelen başka dokümanlarda tutulmalıdır ki bu kod programcılara anlam ifede etsin.

Her uygulama bir iş için yapılır ve ister çok teknik olsun ister olmasın ister çok karmaşık olsun isterse de sadece bir kaç süreç ve kural içerecek kadar basit olsun muhakkak bir iş süreci ve mantığı barındırır. Dolayısıyla bu süreçler ve ilgili mantığın, nesneler ve aralarındaki ilişkilerle ifade edilmesi gereklidir. Aksi taktirde hangi dili kullandığınızın ya da kaç katmanlı yapı kurguladığınızın çok fazla önemi olmayacaktır. Çok sıklıkla EJB, Spring, JSF gibi teknolojileri kullanacak öngörüde bulunan yazılımcıların bu konularda çuvalladığını görüyorum. Aslolan iş süreçlerinizi doğru düzgün ve değişıme el verecek şekilde modelleyip kodlamak. Teknoloji, hangi frameworku ya da hangi dili kullandığınız ancak bu sorunu çözdükten sonra problem olarak ele alınmalıdır.

Bol ve eğlenceli nesneli projeler diliyorum…

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