C:\>javap.exe -verbose tumbler.Story
Compiled from "Story.java"
public interface tumbler.Story extends java.lang.annotation.Annotation
  SourceFile: "Story.java"
  RuntimeVisibleAnnotations: length = 0x1B
   00 02 00 09 00 01 00 04 65 00 0A 00 0B 00 0C 00
   01 00 04 5B 00 01 65 00 0D 00 0E
  minor version: 0
  major version: 50
  Constant pool:
const #1 = class        #15;    //  tumbler/Story
const #2 = class        #16;    //  java/lang/Object
const #3 = class        #17;    //  java/lang/annotation/Annotation
const #4 = Asciz        value;
const #5 = Asciz        ()Ljava/lang/String;;
const #6 = Asciz        SourceFile;
const #7 = Asciz        Story.java;
const #8 = Asciz        RuntimeVisibleAnnotations;
const #9 = Asciz        Ljava/lang/annotation/Retention;;
const #10 = Asciz       Ljava/lang/annotation/RetentionPolicy;;
const #11 = Asciz       RUNTIME;
const #12 = Asciz       Ljava/lang/annotation/Target;;
const #13 = Asciz       Ljava/lang/annotation/ElementType;;
const #14 = Asciz       TYPE;
const #15 = Asciz       tumbler/Story;
const #16 = Asciz       java/lang/Object;
const #17 = Asciz       java/lang/annotation/Annotation;

{
public abstract java.lang.String value();

}

thumbler.Story sınıfı için major number 50, minor number 0 görünmektektedir. Aşağıdaki listeden bu sınıfın hangi Java compiler versiyonu ile derlendiğini anlamak mümkündür.

* Java 1.2 uses major version 46
* Java 1.3 uses major version 47
* Java 1.4 uses major version 48
* Java 5 uses major version 49
* Java 6 uses major version 50

EOF ( End Of Fun)
Özcan Acar

Java’da bulmaca sevenlere; Aşağıda ki kod parçası için çıktı ne olur,
“finalized” yazar mı? Constructor’ýnda exception fırlatmış bir nesnenin
finalize işleminden geçmesini bekler misiniz?

public class FinalizerTest {

<span id="more-1098"></span>

  public FinalizerTest() {
    System.out.println("constructed");
    throw new RuntimeException();
  }

  protected void finalize() throws Throwable {
    System.out.println("finalized");
  }

  public static void main(String[] args) {
    try {
      new FinalizerTest();
    } catch (Exception e) {
      System.out.println("exception");
    }
    System.gc();
  }
}

Benim verdiğim cevap şu şekildedir:

Java’da finalize() kullanılması doğru değildir, çünkü JVM’in finalize metodunu ne zaman koşturacağını kestirmek mümkün değildir. Buna güvenerek örneğin finalize() içinde kullanılan kaynakları serbest bırakmak yapılabilecek en büyük hatalardan birisidir. Pratikte finalize() metodu kesinlikle kullanmamalıdır. Finalizer kullanımı performansı düşürür. Finalizer ile nesnenin yok edilmesi daha uzun zaman alır. Finalize yerine bir terminasyon metodu kullanılmalıdır. gc() metodunun kullanımı da GC nin hemen devreye gireceği garantisini vermez.

Yukarıda yer alan programın konstruktöründe try catch ile hata yakalanarak, daha önce bahsettiğim terminasyon metodu (örneğin myExit()) koşturulmalıdır.

EOF ( End Of Fun)
Özcan Acar

• Final sınıf değişkenleri: Final olan bir sınıf değişkenine sadece bir kere değer ataması yapilabilir ve bu atama sadece sınıf konstrüktöründe gerçekleşebilir.
• Final metot parametreleri: Final olarak tanımlanmış bir metot parametresine sadece bir kere değer atanabilir. Metot parametrelerinin tamamen final olarak tanımlamış olmalarında büyük fayda vardır. Bu şekilde parametrenin metot bünyesinde değişikliğe ugrama tehlikesi ortadan kaldırılmış olur.
• Final metotlar: Final olan bir metot ne alt sınıflarca yeniden yüklenebilir (method overloading) ne de saklı (hidden) tutulabilir.
• Final sınıflar: Final olan bir sınıf genişletilerek bir alt sınıf oluşturulamaz.

Final anahtar kelimesi Java programcılığında en çok göz ardı edilenlerdendir. En son siz ne zaman final anahtar kelimesini kullandınız?
Final anahtar kelimesi programın daha doğru, hatalara dayanıklı ve performanslı çalışmasını sağlar.

Final anahtar kelimesinin kullanımında yapılan en büyük hatalardan birisi final static olarak tanımlanmış olan bir sınıf değişkenine değistirilebilir bir değerin atanmasıdır. Örneğin aşağıdaki tanımlama yanlıştır, çünkü static değişken final olmasına rağmen, bu değişkene atanan değer, kullanıcı tarafından değiştirilebilir.

public class App
{
    public static final String[] LIST = {"1","2","3"};

    public static void main(String[] args)
    {
	String[] list = App.LIST;
	list[0] = "2";
	System.out.println(App.LIST[0]);
    }
}

Yukarda yer alan main() metodunda final olan LIST degiskeninin ihtiva ettiği array değiştirilmektedir. Bu sorunu ortadan kaldırmak için LIST değişkeni private yapılabilir ve bu değişkeni baz alarak içeriğinin değiştirilemeyeceği bir array değerini geri döndüren metot oluşturulabilir. Bunun bir örneği aşağıda yer almaktadır:

import java.util.Arrays;
import java.util.Collections;
import java.util.List;

public class App
{
    private static final String[] LIST = {"1","2","3"};

    public static final List<String> getList()
    {
	return Collections.unmodifiableList(Arrays.asList(App.LIST));
    }

    public static void main(String[] args)
    {
	List<String> list = App.getList();
	list.remove(0);
	System.out.println(list);
    }
}

Bu program koşturulduğunda alınacak hata şu şekildedır:

Exception in thread “main” java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableList.remove(Collections.java:1162)
at test.App.main(App.java:22)

Bu şekilde final olarak tanımladığımız LIST değişkenin ihtiva ettiği değerleri üzerinde oynama yapmak mümkün değildir. getList() metodu bünyesinde Collections.unmodifiableList() ile içeriğinin değiştirilmesi mümkün olmayan bir liste oluşturulmaktadır.

EOF ( End Of Fun)
Özcan Acar

package test.controller;

import java.util.Map;

import test.criteria.Criteria;

public abstract class AbstractController implements Controller
{
    public void executeFilter()
    {
	Map<String, String> map = createCriteria().getCriteriaMap();

    }

    public abstract Criteria createCriteria();
}

Soyut (abstract) olan AbstractController sınıfı bünyesinde, alt sınıflarda implemente edilmek üzere createCriteria() isminde bir metot tanımlıyoruz. AccountTableController sınıfı bu metodu implemente etmektedir.

package test.controller;

import java.util.HashMap;
import java.util.Map;

import test.criteria.MyCriteria;
import test.model.Konto;

public class AccountTableController extends AbstractController
{
    private Account model = new Account();

    public Criteria createCriteria()
    {
	Map<String, String> map = new HashMap<String, String>();
	map.put("kontonr", model.getKontonr());
	map.put("blz", model.getBlz());
	return new Criteria(map);
    }
}

Görüldüğü gibi AccountTableController.createCriteria() metodu Criteria tipinde bir degeri geri döndürmektedir. Bu metodun geri döndürdüğü değerin Java 1.5 öncesi Criteria tipinde olması gerekmektedir, çünkü üst sınıfta tanımlanmış olan bu metodun, üst sınıf bünyesinde geri döndürdüğü değer Criteria tipindedir.

Java 1.5 ile bu durum değişmiştir. Üst sınıfta yer alan bir metot alt sınıfta tekrar reimplement edilirse (method overriding), reimplemente edilen metodun geri döndürdüğü değerin tipi, üst sınıftaki metodun geri döndürdüğü sınıfın bir alt sınıfı olabilir. Bunun bir örneği aşağıda yer almaktadır.

package test.controller;

import java.util.HashMap;
import java.util.Map;

import test.criteria.MyCriteria;
import test.model.Konto;

public class AccountTableController extends AbstractController
{
    private Account model = new Account();

    @Override
    public MyCriteria createCriteria()
    {
	Map<String, String> map = new HashMap<String, String>();
	map.put("kontonr", model.getKontonr());
	map.put("blz", model.getBlz());
	return new MyCriteria(map);
    }
}

MyCriteria, Criteria sınıfının bir alt sınıfıdır ve AccountTableController sınıfı implemente ettiği createCriteria() metodunun MyCriteria tipinde bir değeri geri döndürmesi sağlamıştır. Bu şekilde cast işlemi yapılmadan alt sınıfların daha zengin tipte verileri geri döndürebilmeleri amaçlanmaktadır.

EOF ( End Of Fun)
Özcan Acar

Öncelikle küçük bir örnek üzerinde singleton bir nesnesinin nasıl oluşturulacağına bir göz atalım:

package com.kurumsaljava.com.designpatterns.singleton;

public class MySingleton
{
    private static final MySingleton instance = new MySingleton();

    private MySingleton()
    {
    }

    public void myMethod()
    {

    }
}

MySingleton sınıfının sahip olduğu konstruktör private olduğu için bu sınıftan bir nesne oluşturmamız mümkün değildir. Bu sınıf bünyesinde ve MySingleton tipinde olan instance ismindeki sınıf değişkeni singleton nesnedir. Bu sınıf ilk kullanıldığında private olan konstruktör bir defaya mahsus olarak işlem göreceği için instance degişkeni bir singleton nesne haline gelecektir. Buradaki sorun, reflection yöntemleri kullanılarak private olan konstruktörün birden fazla singleton nesne oluşturmasını sağlayabilmektir. Bunun yanısıra eger MySingleton sınıfı Serializable interface sınıfını implemente ediyorsa, readResolve() metodunun da implemente edilmesi gerekmektedir, aksi taktirde deserializasyon esnasında yeni bir nesne oluşturulur ki, bu da singleton tasarım şablonunun mantığına ters düşer.

Java 1.5 den itibaren kullanıma sunulan Enum sınıfı ile singleton nesneler oluşturmak mümkündür. Bunun bir örneği aşağıda yer almaktadır.

package com.kurumsaljava.com.designpatterns.singleton;

public enum MySingletonEnum
{
    INSTANCE;

    public void myMethod()
    {

    }
}

MySingletionEnum.INSTANCE sadece ve sadece bir kere mevcut olan bir singleton değişkendir. Bunun yanısıra reflection metotları kullanılarak yeni bir singleton olmayan nesne oluşturulamaz. Ayrıca serializasyon işlemlerinde readResolve() kullanılmak zorunda kalmadan enum nesnesinin singletonluğu garanti edilmektedir. Tek elementli olan bir enum sınıfı singleton tasarım şablonunu implemente etmek i.in kullanılabilecek en iyi yöntemdir.

// JDBC Driver
    public static final String DRIVERCLASS      = "org.hsqldb.jdbcDriver";
    // standalone mode
    public static final String CONNECTIONURL    = "jdbc:hsqldb:hsql://localhost:9006/mydb";
    public static final String USERNAME         = "sa";
    public static final String PASSWORD         = "";

public void setUp() throws Exception
	{
		PreparedStatement pstmt = null;

		 try
		 {
			IDatabaseConnection connection = getConnection();
			IDataSet dataSet = getDataSet();
			try
			{
				// REF INTEGRITY MUST BE DISABLED IN ORDER TO IMPORT THE DATA
				// THIS SOLUTION IS ONLY VALID FOR HSQLDB 1.8
				pstmt = connection.getConnection().prepareStatement("set referential_integrity FALSE");
				pstmt.executeUpdate();
				DatabaseOperation.CLEAN_INSERT.execute(connection, dataSet);
				pstmt = connection.getConnection().prepareStatement("set referential_integrity TRUE");
				pstmt.executeUpdate();
			}
			finally
			{
				connection.close();
			}
		}
		catch (Exception e)
		{
		    throw e;
		}
	}

	protected IDatabaseConnection getConnection() throws Exception
	{
		Class.forName(DRIVERCLASS);
		Connection jdbcConnection = DriverManager.getConnection(CONNECTIONURL, USERNAME, PASSWORD);
		IDatabaseConnection con =  new DatabaseConnection(jdbcConnection);
		DatabaseConfig config = con.getConfig();
		config.setProperty(DatabaseConfig.PROPERTY_DATATYPE_FACTORY, new HsqldbDataTypeFactory());
		return con;
	}

protected final IDataSet getDataSet() throws Exception
	{
		final URL url = DatabaseTestCase.class.getResource( "/dbunit-dataset.xml");
	    final File file = new File(url.getPath());
	    return new FlatXmlDataSet(file);
	}

    // JDBC Driver
    public static final String DRIVERCLASS      = "org.hsqldb.jdbcDriver";
    // standalone mode
    public static final String CONNECTIONURL    = "jdbc:hsqldb:hsql://localhost:9006/mydb";

    public static final String USERNAME         = "sa";
    public static final String PASSWORD         = "";

private void startHsqlDb()
    {        

	    if(!isHsqlDbStarted())
	    {
	        Server hsqlServer = new Server();
	        hsqlServer.setAddress("localhost");
	        hsqlServer.setPort(9006);
	        hsqlServer.setDatabasePath(0, "db/hsqldb-data/");
	        hsqlServer.setDatabaseName(0, "mydb");
	        hsqlServer.start();
	    }
    }

	private boolean isHsqlDbStarted()
    {
        boolean result = false;
        try
        {
            Class.forName(DRIVERCLASS);
            Connection con = DriverManager.getConnection(CONNECTIONURL, USERNAME, PASSWORD);
            con.close();
            result = true;
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
        return result;
    }

	private static void stopHsqlDb()
    {
        try
        {
            Class.forName(DRIVERCLASS);
            Connection con = DriverManager.getConnection(CONNECTIONURL, USERNAME, PASSWORD);
            Statement statement = con.createStatement();
            statement.execute("SHUTDOWN");
            statement.close();
            con.close();
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }

Komponent bünyelerinde Hibernate kullanarak, komponent verilerini bilgibankasında sakliyorum. Şu an geliştirdiğim JugTR.org projesinde JPA anotasyonlarını kullandım. Aşağıda blog kayıtlarını temsil eden Blog Entity sınıfı yer alıyor.

package bt.common.manager.blog.domain;

import java.io.Serializable;
import java.sql.Timestamp;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name="blog")
public class Blog implements Serializable
{
private static final long serialVersionUID = 1L;

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "id")
private Long id;

@Column(name = "subject", nullable = false)
private String subject;

@Column(name = "body", nullable = false)
private String body;

@Column(name = "userid", nullable = false)
private Long user;

@Column(name = "created", nullable = false)
private Timestamp created;

public Blog(long blogId)
{
this.id = blogId;
}

public Blog()
{

}

public Long getId()
{
return id;
}

public void setId(Long id)
{
this.id = id;
}

public String getSubject()
{
return subject;
}

public void setSubject(String subject)
{
this.subject = subject;
}

public String getBody()
{
return body;
}

public void setBody(String body)
{
this.body = body;
}

public Long getUser()
{
return user;
}

public void setUser(Long user)
{
this.user = user;
}

public Timestamp getCreated()
{
return created;
}

public void setCreated(Timestamp created)
{
this.created = created;
}
}

@Table anotasyonunu kullanarak bilgibankası tablosunu belirliyorum. Örnekte görüldüğü gibi Blog nesnesinin ihtiva ettiği veriler blog isimli tabloda saklanmakta.

Blog komponentini (Blog.java ve diger komponent sınıfları) daha önce başka projelerde de kullandım. Komponenti tekrar kullanmak (reuse) benim için kod üzerinde değişiklik yapmamak anlamına gelmektedir. Eğer blog verilerini jugtr_blog isimli tabloda tutmak istersem, Blog.java sınıfında yer alan @Table anotasyonunu değiştirmem gerekiyor. Bu durumda komponentin kodunu değiştirmiş olacağım. Bu da bir nevi tekrar kullanım, lakin bu durumda komponentin birden fazla versiyonu oluşmakta ve bunların bakımı zamanla güçleşmektedir. Benim hayalimde kod üzerinde değişiklik yapmadan Blog komponenentini istediğim projede kullanabilmek ve bilgibankası tablo ismini projeye göre değiştirebilmek var. Bu ne yazik ki JPA anotasyonlarını kullanarak mümkün değil. Eğer @Table anotasyonu ile tablo ismini belirlediyseniz, o zaman tablo ismini değiştirmek için sınıfı değiştirmeniz gerekiyor.

Bu çoktan beri üzerinde çalıştığım bir sorun. Sorunu Hibernate bünyesinde bir interceptor sınıf oluşturarak çözebildim. Interceptor sınıfı aşağıdaki yapıya sahip:

package bt.jugtr.application.common.hibernate;

import org.hibernate.EmptyInterceptor;

public class JugTRHibernateInterceptor extends EmptyInterceptor
{

	private static final long serialVersionUID = 1L;

	@Override
	 public String onPrepareStatement(String sql)
	 {
	 		 String prepedStatement = super.onPrepareStatement(sql);

	 		 prepedStatement = prepedStatement.replaceAll("public.", "jugtr.");

	 		 return prepedStatement;
	 }
}

Bu interceptor sınıfını aktive etmek için SessionFactory konfigürasyonunu (Spring applicationContext.xml bünyesinde) aşağıdaki şekilde değiştiriyorum:

<bean id="sessionFactory"
		class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
		 <property name="entityInterceptor">
		 		 <bean class="bt.jugtr.application.common.hibernate.JugTRHibernateInterceptor" />
		 </property>
		<property name="configurationClass">
			<value>org.hibernate.cfg.AnnotationConfiguration</value>
		</property>
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.dialect"> ${hibernate.dialect} </prop>
				<prop key="hibernate.show_sql">true</prop>
				<prop key="hibernate.format_sql">true</prop>
				<prop key="hibernate.use_sql_comments">true</prop>
				<prop key="hibernate.connection.release_mode">after_transaction</prop>
				<prop key="hibernate.current_session_context_class">thread</prop>
			</props>
		</property>
		<property name="dataSource">
			<ref bean="dataSource" />
		</property>
		<property name="annotatedClasses">
			<list>
				<value>bt.common.manager.user.domain.BTUser</value>
				<value>bt.common.manager.user.domain.Authorities</value>
				<value>bt.common.manager.blog.domain.Blog</value>
				<value>bt.common.manager.blog.domain.BlogComment</value>

			</list>
		</property>
	</bean>

Hibernate, oluşturduğu SQL komutunu bilgibankasına göndermeden önce JugTRHibernateInterceptor sınıfının onPrepareStatement() metodunu koşturur. Bu metot bünyesinde public. ile başlayan tablo isimlerini jugtr. olarak değiştiriyorum. public. ve jugtr. bilgibankasında kullandığım şemalar (schema). Hibernate tarafından oluşturulan SQL komutlarında public. isminin kullanımını @Table anotasyonuna schema değişkenini ekleyerek sağlayabilirim:

@Entity
@Table(name="blog", schema="public")
public class Blog implements Serializable
{
}

Bu değişikliğin ardından Hibernate tarafından oluşturulan bir SQL aşağıdaki şekilde olacaktır:

/* from Blog order by id desc */
select top ? blog0_.id as id2_, blog0_.body as body2_, blog0_.created as created2_, blog0_.subject
as subject2_, blog0_.userid as userid2_ from public.blog blog0_ order by blog0_.id desc

Görüldüğü gibi Hibernate blog tablosunu public.blog seklinde adreslemeye başladı. Tekrar JugTRHibernateInterceptor sınıfına geri dönelim. onPrepareStatement() metodu bünyesinde SQL komutunda yer alan public. kelimesinin jugtr. olarak değiştirilmesini sağlıyorum. Bu şekilde dinamik olarak başka bir şemayı ve bu şemada bulunan blog tablosunu adreslemiş oluyorum. JugTRHibernateInterceptor devreye girdikten sonra SQL komutu aşağıdaki şekilde değişikliğe uğruyor. Bu şekilde başka bir şema içinde bulunan blog isimli tablo kullanımı mümkün oluyor. Görüldüğü gibi Blog.java kodunu değiştirmek zorunda kalmadan başka bir tabloyu kullanabildik.

/* from Blog order by id desc */
select top ? blog0_.id as id2_, blog0_.body as body2_, blog0_.created as created2_, blog0_.subject
as subject2_, blog0_.userid as userid2_ from jugtr.blog blog0_ order by blog0_.id desc

EOF ( End Of Fun)
Özcan Acar

Apache ile Tomcat arasında Reverse Proxy oluşturarak JugTR.org aplikasyonuna 80 numaralı port üzerinden ulaşabiliriz. Reverse Proxy kullanıldığında http://www.jugtr.org adresine gelen kullanıcı istekleri Apache tarafından http://127.0.0.1:8181 adresine yönlendirilir ve bu şekilde 8181 portu üzerinde faaliyet gösteren Tomcat’e 80 numaralı port üzerinden erişim sağlanmış olur. Apache,  kullanıcı ile Tomcat içinde deploy edilmiş ve 8181 numaralı portta çalışan JugTR.org aplikasyonu arasında aracılık etmiş olur.

Apache ile Tomcat arasında Reverse Proxy oluşturmak için öncelikle mod_proxy modülünü Apache httpd.conf dosyasina eklememiz gerekiyor. Ben Apache 2 versiyonunu kullanıyorum. Aşağıda httpd.conf dosyasında yer alması gereken konfigürasyon bulunmakta.

LoadModule proxy_module modules/mod_proxy.so

[Proxy *]
   Order deny,allow
   Allow from all
[/Proxy]

NameVirtualHost 192.168.1.76

[VirtualHost 192.168.1.76]
ServerName www.jugtr.org
ServerAlias www.jugtr.org jugtr.org
ServerAdmin info@jugtr.org
DocumentRoot /database/usr/local/apache/htdocs/
ProxyPass / http://127.0.0.1:8181/
[Location /]
      ProxyPassReverse /
   [/Location]
[/VirtualHost]

Yukarda görüldügü gibi VirtualHost direktifini kullanarak, jugtr.org icin yeni bir virtual domain oluşturuyorum. Bu sayede aynı Apache kurulumu üzerinde birden fazla domain ismini kullanmam mümkün.

VirtualHost direktifini yakından incelediğimizde ProxyPass direktifi ile http://www.jugtr.org/ adresine gelen tüm kullanıcı isteklerinin (request) http://127.0.0.1:8181 adresine yönlendirildiğini görmekteyiz. ProxyPass direktifini kullanarak Apache ve Tomcat arasında Reverse Proxy oluşturmus oluyoruz.

Tomcat kullanıcı isteklerine konfigüre edildigi IP ve port adresi ile cevap verir. Yukardaki örnekte kullanıcı http://127.0.0.1:8181 adresine yönlendirilecektir. Bu durumda Apache ile Tomcat arasındaki proxy çalışmamaktadır. Tomcat’in gönderdigi cevapların reverse proxy adresinde olmasını sağlamak için Tomcat’in server.xml konfigürasyon dosyası üzerinde değişiklik yapmamız gerekmektedir. Yapılması gereken değişiklik Connector elementi bünyesindedir.

Connector port="1224" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443"

debug="0" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8" proxyName="www.jugtr.org" proxyPort="80"

Connector elementinde kullandığımız proxyName ve proxyPort atributlarıyla Tomcat’in gönderdiği cevapların http://www.jugtr.org şeklinde olmasını sagladık.

EOF (End Of Fun)
Özcan Acar