28 Haziran 2015 Pazar

AXIS ve CXF nedir?

Apachi AXIS(Apache eXtensible Interaction System- Apachi Genişletilebilir Etkileşim Sistemi); Apachi firması tarafından geliştirilmiş, open-source, XML tabanlı Web Servis framework tür. Java ve C++ implemantasyonları vardır. Web servis uygulamalarının deploy edilmesi ve oluşturulması için çeşitli araçlar ve API(Application Interface) ‘ler barındırmaktadır. Apache Axis, developer lara birlikte çalışabilir, dağıtık bilgisayar uygulamaları geliştirebilmeyi sağlar. SOAP ve XML RPC protokollerini destekler. Yani JAX-RPC ve JAX-WS Apileri kullanarak web servislerin yönetilmesini sağlar. Ancak AXIS 2 ile beraber JAX-RS API ile RESTful protokol desteği de gelmiş bulunmaktadır.
Apachi CXF(CeltixXFire); Apachi firması tarafından “Celtix” ve “XFire” projeleri biraraya getirilerek tek bir çatı altında toplanmıştır. CXF de open-source, çok özellikli bir Web Servis framework tür. CXF, SOAP ile beraber RESTful protokolünü de desteklemektedir. Developerın JAX-WS ve JAX-RS API'lerini kullanarak etkileşimli hizmetler geliştirmelerine yardımcı olur. Ayrıca CXF ‘de Spring entegrasyonu da mümkündür. XML dışında, JSON ve CORBA data taşımaya da izin verir.
            Bunların yanı sıra alternatif olarak; JAX-RPC ve JAX-WS destekli olan Metro, JAX-RS destekli olan Jersey, RESTEasy, RESTLET, Dropwizard Web Servis frameworkleri de tercih edilebilir. Daha detaylı karşılaştırma ve kullanım seçiminizi belirleyebilmek için aşağıdaki kaynaklar kısmındaki makaleleri inceleyebilirsiniz.

Kaynaklar

26 Haziran 2015 Cuma

REST nedir? SOAP ile arasındaki farklar nelerdir?

Web Servisler, temelde HTTP protokolünü kullanarak, platformdan bağımsız metodlar ile ortak veri formatında veri alış verişinin yapılmasını sağlayan yapılardır. REST ve SOAP;  Web Servis teknolojilerinde günümüzde çok tercih edilen veri iletişim protokolleri,yöntemleri arasında yer alır. SOAP (Simple Object Access Protocol – Basit Nesne Erişim Protokolü);  iletilen veri türünün XML olması gereken veri transfer yöntemidir. SOAP tabanlı bir web servis, WSDL(Web Services Description Language) standardında gönderilen XML verisini yorumlamak zorundadır.
REST(Representational State Transfer – Temsili Durum Transferi); iletilen verilerin türünün bilinmediği veri transfer yöntemidir. 2000 yılında HTTP spesifikasyonunun yazarlarından biri olan Roy Fielding tarafından doktora tezinin bir parçası olarak geliştirilmiştir. REST mimarisinde, işlemler resource kavramıyla yapılır. Resource URI ile tanımlanır ve bir metod tanımlaması veya bir değişken olabilir. Yani REST’te SOAP’ta olduğu gibi XML yardımıyla metodlar çağırılmaz bunun yerine o metodu çağıracak URI ‘ler ile web servise HTTP protokolüyle istek yapılır. Böylece REST için WSDL gibi bir tanımlama diline ihtiyaç kalmaz. İşlemler tamamen HTTP metodları üzerinden yapılır. Örneğin, bir web servisin metodunu SOAP ile “getUnitName” şeklinde çağırırken REST ile “/units/name/1″ URI’si ile çağırabiliriz. Ayrıca REST’in döndürdüğü veri tipinin de XML olması zorunlu değildir; JSON, XML, TXT, HTML gibi istenen veri türünde değer döndürülebilir.
REST ile HTTP metod çağrımı :
REST tabanlı web servislerde HTTP metodlarına özel anlamlar yüklenir ve böylece web servise bir HTTP isteği geldiği anda metod çalıştırılmış olur. Bu durumda HTTP metodlarının REST ile nasıl kullanılacağı önemlidir. REST’de iki tip URI vardır. Bunlardan biri Collection URI diğeri Element URI’dir.
Collection URI ; array, list gibi veri yapıları için kullanılır. Örnek kullanım şekli;
http://example.com/resources
GET: Belirtilen collection’ın URI’lerini veya detaylarını listelemede kullanılır.
PUT: Bütün bir collection’ı başka bir collection’la yer değiştirmek için kullanılır.
POST: Yeni bir collection oluşturmak için kullanılır ve yeni oluşturulan collection’ın URI’si döndürülür.
DELETE: Tüm collection’ı silmek için kullanılır.
Element URI ise değişkenler üzerinden işlem yapmak için kullanılır. Örnek kullanım şekli;
http://example.com/resources/item/17
GET: Adresi verilen nesneyi döndürmek için kullanılır.
PUT: Var olan bir nesneyi değiştirmek için veya eğer yoksa yeni bir tane oluşturmak için kullanılır.
POST: Yeni bir nesne oluşturmak için kullanılır. Her seferinde yeni bir nesne oluşturur.
DELETE: Adresi verilen nesneyi silmek için kullanılır.

REST Requesti Sonucu, Çoğunlukla Dönen HTTP Status Kodları:
200 OK: Genelde veri listeleme sonuçları 200 ile dönüş yapılır.
201 CREATED: Veri eklendiği zaman verinin kendisi ile 201 dönülür.
204 NO CONTENT: Veri silindiği zaman 204 dönülür.
400 BAD REQUEST: Genel olarak kayıt ekleme ya da güncelleme isteklerinde gönderilen veri validasyondan geçemediyse neden geçemediği hakkında bilgiyle beraber 400 HTTP Statusuyla dönülür.
403 Forbidden: Yetkiye dayalı bir işlem yapılıyorsa bu API uç noktasında işlem yapmaya çalışan kişinin bu işlemi yapmaya yetkisi yoksa 403 status kodu döner.
401 Unauthorized: Api ucunuzda bu işlemi yapmak için login olmak zorunlu ise ve API’ye istek yapan kullanıcı login değilse bu HTTP Status ile cevap verilir.
404 Not Found: Bu HTTP Status,  kullanıcının istek yaptığı URL yok ise ya da URL deki veri geçersiz ise bu hatayı alırız.
405 Method Not Allowed: Bu HTTP Statusu istek yapılan API uç noktası gönderilen metodu implemente etmemiş ise bu HTTP Statusunu alırız. Örneğin login olması için token verdiğimiz bir API ucumuz var ve bu uçta sadece POST isteğini kabul ediyor. Kullanıcı bu API URL’ine GET isteği yaparsa 405 statusu döner.
429 Too Many Requests: Bu HTTP Statusunu, saatlik ya da dakikalık kısıtlanan sınırdan fazla istek yapıldığında alırız. 

Gruplanmış Bakış Açısıyla HTTP Statusları;
Bilgilendirme
 – 1xx
Başarılı İşlem – 2xx
Yönlendirmek – 3xx
Kullanıcı Taraflı hata – 4xx
Server Taraflı hata – 5xx      
Şeklinde ifade edebiliriz.

Örnek REST Requestleri;
GET /tickets – Ticket Listesi
GET /tickets/12 – Ticket Detayı
POST /tickets – Yeni Ticket Ekleme
PUT /tickets/12 – Ticket Güncelleme
PATCH /tickets/12 – Ticketin bir kısmını güncelleme
DELETE /tickets/12 – Ticket Silme
GET /tickets/12/messages  12 id li ticket e bağlı mesajlar listesi
GET /tickets/12/messages/5  5 id li mesajın detayı
POST /tickets/12/messages  12 id li ticket e mesaj ekleme
PUT /tickets/12/messages/5  Mesaj güncelleme
PATCH /tickets/12/messages/5  Mesajın belli bir kısmını güncelleme
DELETE /tickets/12/messages/5 –5 id li mesajı silme
GET /tickets?sort=-created_at&page=1 – Ticketları Eklenme tarihini büyükten küçüge sıralama işlemi ve birinci sayfa verisini getir
GET /tickets?type=1&sort=-created_at – Ticketları Eklenme tarihini büyükten küçüğe sıralama işlemi ve tipi 1 olan ticketlar
GET /tickets?fields=id,subject,customer_name,updated_at&type=1&sort=-updated_at – Sadece belli fiedleri ve tipi 1 olan son güncelleme tarihine göre büyükten küçüğe sıralama

REST ile SOAP Arasındaki Farklar;
  • SOAP XML veri tipini desteklerken REST istenen veri türüyle işlem yapabilir. JSON veri tipi ile XML’den çok daha düşük boyutlarla veri tutulabildiği için REST ile daha hızlı işlem yapılabilir. Yani REST’de gelen, giden data boyutu SOAP ile karşılaştırıldığında çok ufaktır diyebiliriz.
  • Ayrıca SOAP için WSDL ile tanımlama yapmak gerekirken REST için böyle bir zorunluluk yoktur. (WADL<Web Application Description Language> REST için kullanılan, WSDL’e benzer bir yapıdır fakat kullanma zorunluluğu yoktur.) Bir dile ihtiyaç duymadan HTTP metodlarıyla tasarlanabildiği için REST’i kullanması ve tasarlaması daha kolaydır.
  • SOAP için birçok geliştirme aracı mevcuttur, REST için geliştirme araçlarına ihtiyaç duyulmaz, tasarlaması kolaydır.
  • SOAP; XML-Scheme kullanırken REST; URI-Scheme kullanır yani metotlar için URI’ler tanımlanır.
  • Her ikisi de HTTP protokolünü kullanırlar. Fakat REST için HTTP zorunluluğu varken SOAP; TCP, SMTP gibi başka protokollerle de çalışabilir.
  • Test ve hata ayıklama aşaması REST için daha kolaydır. Çünkü HTTP hatalarını döndürür ve bunlar bir Tool‘a ihtiyaç duyulmadan görülebilir. SOAP için hata ayıklama araçları gerekebilir.
  • REST basit HTTP GET metodunu kullandığı için Cache leme işlemi daha kolaydır. SOAP ile Cache leme yapabilmek için karmaşık XML requestleri yapılmalıdır.
  • İkisi de HTTPS destekler, SOAP için WS-SECURITY adlı bir eklenti mevcuttur.
  • Güvenlik açısından SOAP daha gelişmiştir çünkü hazır yapılar bulunmaktadır.
  • Dokümantasyon bakımından SOAP daha gelişmiştir ve daha fazla kaynak bulunmaktadır.
  • Verimlilik, ölçeklenebilirlik ve kullanıcı tarafından algılanan performans açılarından bakıldığında REST , SOAP ‘tan daha iyidir ve tercih edilir.
Kaynaklar :

22 Haziran 2015 Pazartesi

JSON nedir?

JSON(Java Script Object Notation – Java Script Nesne Gösterimi), birbirinden bağımsız yazılım platformlarında bilgi alışverişi yaparken, geliştiricilerin daha kolay okuyup, anlayabildikleri düşünülen veri değişim formatı yada veri gösterim dili dir.
JavaScript Programlama Dili, Standard ECMA-262 3.Yayın - Aralık 1999, versiyonunun alt kümesi üzerine kurulmuştur. JSON, tamamen programlama dillerinden bağımsız, ancak C türevi dillere (C, C++, C#, Java, JavaScript, Perl, Python ve daha pek çoğu) yazılış bakımından çok benzeyen bir veri tanımlama formatıdır. Bu özellikleri, JSON'u veri değiş tokuşu için ideal hale getirmektedir.JSON; Number, String, Boolean, Array, Object, null veri tiplerini destekler.
JSON, iki yapı üzerine kurulmuştur:
  • İsim/değer(name/value) çifti koleksiyonu. Çeşitli programlama dillerinde bu, "object, record, struct, dictionary, hash table, keyed list veya associative array" olarak da tanımlanmıştır.
  • Sıralı değer listesi. Çoğu programlama dilinde bu, "array, vector, list veya sequence" olarak tanımlanır.
Bu yapılar, evrensel veri yapılarıdır. Bütün modern programlama dilleri, bu yapıları, bir şekilde içlerinde barındırmaktadırlar.
Bu yapılar JSON'da, aşağıdaki şekillerde gösterilirler:
Object: Bir nesne (object), isim/değer çiftlerinin sırasız birleşiminden oluşur. Nesne tanımlaması, { (kıvırcık parantez aç) ile başlar ve } (kıvırcık parantez kapa) ile biter. Her "isim"den sonra : (iki nokta üstüste) gelir ve isim/değer çiftleri , (virgül) ile ayrılır.
Şekil-1 : Object türündeki yapının gösterimi
Array: Diziler, sıralı değer listesidir. Bir dizi [ (köşeli parantez aç) ile başlar ve ] (köşeli parantez kapa) ile biter. Değerler , (virgül) ile ayrılır.
Şekil-2 : Array türündeki yapının gösterimi
Bir değer(value); çift tırnak içinde bir string (yazı)sayı, true (doğru)false (yanlış)null (boş değer)object (nesne) veya array (dizi) olabilir. Bu yapılar bir birlerinin içinde tekrar edebilirler.
Şekil-3 : Array içerisinde kullanılabilen veri türleri gösterimi
Bir string (yazı); çift tırnak içinde, ters-bölü kodlarına da izin veren, sıfır veya daha fazla "Unicode" karakterin birleşiminden oluşur. Bir karakter, string (yazı) tipindeki tek karakter olarak gösterilebilir. String (yazı) tipi, C veya Java dilindeki "string" tipine çok benzemektedir.
Şekil-4 : String olarak yazılabilecek ifadelerin gösterimi
Bir number(sayı); C veya Java dilindeki sayılara çok benzer, ancak sekizli (octal) ve onaltılı (hexadecimal) rakamlar kullanılmamaktadır.
Şekil-5 : Number olarak yazılabilecek ifadelerin gösterimi
Tanımlamaların arasına, istendiği gibi beyaz boşluk (Whitespace) konulabilir. Verinin diline (Encoding) bağlı olarak, notasyonda bazı farklılıklar olabilir.
Örnek:
{
   "tip": "araba",
   "tur": "otomobil",
   "urunler": [
       {"marka": "Hyundai", "model": "1.3 LS", "yil": 1997},
       {"marka": "Toyota", "model": "Corolla", "yil": 2007},
       {"marka": "Ford", "model": "Focus", "yil": 2015}
       ]
}

Kaynaklar:





19 Haziran 2015 Cuma

Takım iletişiminde, Adaptif ve Plan odaklı yaklaşım

Takım dinamikleri ve iletişim yönetimi açısından, Şirket/Kuruluş içerisinde yazılım geliştirme ekipleri arasındaki, Plan odaklı(geleneksel) ve Adaptif(çevik) yaklaşımların farkları aşağıdaki gibi özetlenebilir.







Kaynaklar :
  • https://www.linkedin.com/pulse/tak%C4%B1m-dinamikleri-ve-ileti%C5%9Fim-adaptif-plan-odakl%C4%B1-dilek
  • http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

17 Haziran 2015 Çarşamba

MVC, MVP, MVVM Design Patterns nedir?

MVC (Model-View-Controller); Yazılım geliştirme teknolojilerinde kullanılan, Seperation Of Concern(Yazılımda işlev ve özelliklerin soyutlanarak birbirinden ayırılması) prensibini vurgulayan yazılım tasarım desenidir. İlk kez 1979 yılında “Trygve Reenskaug” tarafından tanımlanmıştır.

Kullanıcı View i görür, Controller ı kullanırlar. Controller Modeli manipule eder veya View i update eder. View, kullanıcı arayüzünü kullanıcıların görmesini ve Controller ı tetiklemesini sağlar.

Modelin Sorumlulukları: Property lerinde veri depolar, uygulama yöntemlerini implemente eder(data and logic), View 'ın register ve unregister methodlarını sağlar,View 'deki durum değişikliklerini uyarır, uygulamanın iş mantığının uygulanmasını sağlar.
View in Sorumlulukları: Arayüzü oluşturur, Model deki değişikliklerde arayüzü günceller, kullanıcı girişlerini Controller'a iletir.
Controller ın Sorumlulukları: Kullanıcı girişlerindeki değişiklikleri Modele iletir, eğer değişiklik yüzeysel ise View'i update eder.

MVP (Model-View-Presenter) ise; MVC de mimarisinde eksiklik olarak görülen sorunlara çözüm olarak 90’lı yıllarda ortaya çıkmıştır. İlk olarak Mike POTEL tarafından bir makalede popüler olmuştur. Daha sonra Martin Fowler ve Derek Greer tarafından da makalelerde ele alınmıştır. Daha sonrasında MVVM(Model View ViewModel) gibi mimari tasarım desenlerine de ihtiyaç duyulmuştur. İhtiyaca göre halen yeni pattern lar geliştirilmeye devam edilmektedir.
                              Şekil : Model View ViewModel
            MVC ‘deki Controller ın View ile daha az etkileşimde olduğu farkedilerek, Controller ın yerine Presenter katmanı tasarlanmıştır. Controller dan farklı olarak Presenter katmanı View ile direkt olarak etkileşim halinde dir.
Şekil : Genel MVP Design Pattern gösterimi.
MVP tasarımı deseni, view’in sorumluluğunu biraz daha arttırarak Controller sınıfını ortadan kaldırmıştır. View’deki veri durum yönetimini ve kullanıcıdan gelen komutları işlemek için presenter sınıfı bulunmaktadır. Presenter ve view arasında one-to-one bir ilişki bulunmaktadır. Bu sayede UI için test kodu yazmamız gerektiğinde ilgili Presenter’a test kodu yazabiliriz. Kullanıcı View’den isteği yaptığında bu istek önce ilgili Presenter sınıfına düşer. Presenter bu isteği modele göndererek dönen cevaba göreView’i update eder.
Passive View (PV) Yaklaşımı :
MVP’nin uygulanmasıyla alakalı iki farklı yaklaşım vardır. Bunlardan biri Supervising Controller olarak adlandırılmıştır. İki yaklaşımda da durum yönetimi View üzerinde yapılır, Presenter sınıfı View’den haberdardır.


Passive view yaklaşımında Presenter sınıfı View ile Modelin arasındaki senkronizasyondan tamamen sorumludur. View sınıfının model ile en ufak bir ilişkisi yoktur. Bütün iş mantığı Presenter sınıfı üzerinde yapılır. Bütün senkronizasyonu Presenter sınıfı sağlar. Bu yaklaşımında View’in çok fazla bir sorumluluğu yoktur. Yaklaşımın adından da anlaşılabileceği gibi pasif kalmıştır. View kendisinin değiştiğini bir event fırlatarak Presenter sınıfına haber verir. Presenter da ilgili model sınıfını günceller.
Supervising Controller (SC) Yaklaşımı :
Supervising Controller yaklaşımında ise, Presenter kompleks UI iş mantığını barındırır. View, modele binding mekanizması olan bir teknolojiyle bağlanarak veriyi çeker. Presenter sınıfı, view tarafından çağırılabilecek olan metotlara sahiptir. Controller sınıfındaki gibi hangi View’in gösterileceğine Presenter sınıfı karar vermez. Presenter sınıfının çağırılması için View’den kod yazılması gerekir. Bir View metodu, Presenter sınıfı tarafından çağırılabilir.
UI için test yazılması gereken projelerde MVP tasarım kalıbı kullanmamız MVC’ye göre daha uygun olur. Çünkü, bütün UI iş mantığı, Presenter sınıfı içerisindedir. Yani Presenter, bir nevi UI’ın kendisi durumundadır. Birden fazla UI teknolojisiyle çalışmamız gereken zaman MVP kullanmak daha mantıklıdır. Çünkü, Presenter sınıflarımız yeniden kullanılabilirliği arttıracaktır. Son derece kompleks UI iş mantığınız varsa veya kullanıcıyla etkileşimi yoğun olan sayfalarınız projenizin büyük bir çoğunluğunda yaygınsa; burada MVP tasarım kalıbı kullanmanın avantajı olacaktır. Bütün iş mantığı sayfanın Presenter sınıfında olacağı için işlem yapmak daha kolay olur. Test edilebilirlik uygulamanız için önemliyse o zaman Passive View yaklaşımı tercih edilmelidir. Çünkü bütün işleyiş onun üzerinde gerçekleşecektir. Ancak, kodun okunabilirliği, daha az karmaşık olması, test edilebilirlikten daha önemliyse, o zaman Supervising Controller yaklaşımı tercih edilmelidir. Çünkü, burada sorumluluğun bir kısmı Presenter sınıfının üzerinden alınmıştır. View ile model arasında bir binding mekanizması kurularak senkronizasyon sağlanmıştır. View sınıfındaki her değişiklikte Presenter sınıfının güncellenmesi gerekmeyecektir.

Çok Katmanlı Design Pattern Mimarilerinin Faydaları:
  1. Kod karmaşasının önüne geçer,
  2. Her katmanda ayrıca kod geliştirmeye izin verir(Front-end, back-end development),
  3. Daha rahat test edilebilir uygulamalar geliştirebilmeyi sağlar,
  4. Yazılım Mimarisi olarak, sorumlulukların birbirinden bağımsız olarak paylaştırılması, geliştirilecek olan yazılımın yönetimini, ölçeklenebilirliğini, geliştirme hızını artırır, bakımını kolaylaştırır.


Kaynaklar:

14 Haziran 2015 Pazar

Java da ClassLoader nedir? Nasıl Çalışır?

JVM(Java Virtual Machine) ilk çalışırken sınıfların yüklenmesinden sorumlu Class tır diyebiliriz. Java da Interpretation(yorumlama) işleminden önce Class Loading işlemleri gerçekleşir. Her Class uniq olarak ClassLoader tarafından JVM Memory e yüklenir. JVM Class Loading işlemlerini yaparken, yani bir java uygulamasını ilk olarak ayağa kaldırırken, daha uygulamamız hiç çalışmaya başlamadan önce, ClassLoader sınıfından extend ederek sınıf yükleme işlemlerini özelleştirmemize olanak sağlar. Örneğin aynı isimli sınıfı iki kez özel olarak load edebiliriz, yada uygulama açılmadan önce güvenlik amaçlı kontroller yada şifrelemeler yapabiliriz.
Class Loading işlemi: JVM de önce Bootstrap Class Loader ile, java.lang, java.util vb gibi paketler içindeki çekirdek classlar yüklenir. Sonra kullanıcı tanımlı Class Loader lar çalışır. Sonra Array Classları create edilir, Constraint ler load edilir, türetilmiş classlara geçilir.
JVM, Class loading işleminden sonra; Classların doğrulanarak hazırlanıp, çözümlenmesi - Linking(Verification,Preparation,Resolution) sonra da yüklenen ve bağlanan Classların başlatılması - Initialization işlemlerini gerçekleştirir. Buraya kadar sorun yoksa normal şartlarda uygulama ayağa kalkmış demektir.
Hiyerarşik olarak Java Class Loader lar;
1)Bootstrap Class Loader : Bu java runtime ortamının parçası olan sınıflardır, “JAVA_HOME/jre/lib/rt.jar” içinde bulunan java.util, java.lang vb. gibi java çekirdek sınıflarını yükler. Bootstrap sınıf yükleyicisi native implementation dur ve bu yüzden farklı JVM'lerde farklılık gösterebilir.
2) Extensions Class Loader : “JAVA_HOME/jre/lib/ext”  altındaki sınıfları yükler.
3) System Class Loader : Java classpath de belirtilmiş olan sınıfları yükler.

Şekil : Java SE 7 JVM mimarisinde, JVM spesifikasyonu.

Örnek Özelleştirilmiş ClassLoader:
package classloaders.ocp7;
import java.io.BufferedInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Map;

/**
 * Simple custom class loader implementation
 */
public class CustomClassLoader extends ClassLoader {

    /**
     * The HashMap where the classes will be cached
     */
    private Map<String, Class<?>> classes = new HashMap<String, Class<?>>();

    @Override
    public String toString() {
        return CustomClassLoader.class.getName();
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {

        if (classes.containsKey(name)) {
            return classes.get(name);
        }

        byte[] classData;

        try {
            classData = loadClassData(name);
        } catch (IOException e) {
            throw new ClassNotFoundException("Class [" + name
                    + "] could not be found", e);
        }

        Class<?> c = defineClass(name, classData, 0, classData.length);
        resolveClass(c);
        classes.put(name, c);

        return c;
    }

    /**
     * Load the class file into byte array
     */
    private byte[] loadClassData(String name) throws IOException {
        BufferedInputStream in = new BufferedInputStream(
                ClassLoader.getSystemResourceAsStream(name.replace(".", "/")
                        + ".class"));
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        int i;

        while ((i = in.read()) != -1) {
            out.write(i);
        }

        in.close();
        byte[] classData = out.toByteArray();
        out.close();

        return classData;
    }

    /**
     * Simple usage of the CustomClassLoader implementation
     */
    public static void main(String[] args) throws ClassNotFoundException,
            InstantiationException, IllegalAccessException,
            NoSuchMethodException, SecurityException, IllegalArgumentException,
            InvocationTargetException
    {
        CustomClassLoader loader = new CustomClassLoader();
        // This class should be in your application class path
        Class<?> c = loader.findClass("classloaders.ocp7.TestClass");
        Object o = c.newInstance();
        Method m = c.getMethod("toString");
        System.out.println(m.invoke(o));
    }

}

Test sınıfı:
package classloaders.ocp7;

public class TestClass {
       public String toString() {
             String aciklama = "Bu bir test sınıfıdır.";
             return aciklama;
       }
}



Kaynaklar: