Search Results for: annotation

Java EE 8 Çıktı!

Java, Java EE ,

Java EE 8, SE 9’ın gölgesinde kaldı! Aslında 21 Eylül gecesi Java SE 9 yayımlanırken Java EE 8 de yayımlandı.

Java EE’nin referans implementasyonu (RI) Glassfish’tir. Java EE 8’in RInu da Glassfish 5 oldu. Oracle daha önce Glassfish’in ticari sürümlerini geliştirmeyeceğini açıklamıştı. Dolayısıyla Glassfish 5’in sadece açık kaynak kodlu sürümü var: https://javaee.github.io/glassfish/

Java EE 8 ve Glassfish 5 ile ilgili bazı önemli bağlantılar şunlardır:

Java EE 8’te aşağıdaki güncellemeler ya da yenilikler vardır:

  • JSR 366 – Java EE 8 Platform
  • JSR 365 – Contexts and Dependency Injection (CDI) 2.0
  • JSR 367 – The Java API for JSON Binding (JSON-B) 1.0
  • JSR 369 – Java Servlet 4.0
  • JSR 370 – Java API for RESTful Web Services (JAX-RS) 2.1
  • JSR 372 – JavaServer Faces (JSF) 2.3
  • JSR 374 – Java API for JSON Processing (JSON-P)1.1
  • JSR 375 – Java EE Security API 1.0
  • JSR 380 – Bean Validation 2.0
  • JSR 250 – Common Annotations 1.3
  • JSR 338 – Java Persistence 2.2
  • JSR 356 – Java API for WebSocket 1.1
  • JSR 919 – JavaMail 1.6

Ne diyelim, Java SE 9 gibi Java EE 8 de hayırlı olsun 🙂

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

Eşleştirme mi Haritalama mı? Not mu Dip Not mu? Bir “Chicken Translation” Hikayesi Daha

Java, Kültür, Bilgi ve Düşünce , , , , , , ,

Sağlıklı düşünmenin göstergesi dili sağlıklı kulanmaktır. Kafası karışık insanların dili kullanma şekilleri, kelimeleri olgulara karşı getirmeleri, bunlar üzerine argüman bina etmeleri problemlidir. Bu tür kafa karışıklıklarının bir kısmı da, teknolojiyi ve ilgili terimleri ve ifadeleri, yabancı dilden, özellikle de İngilizce’den devşirirken takındığımız tutumla ilgili. Bu günlükte olgunun ya da sürecin ruhuna uymayan ve bu yüzden iğreti duran çevirilerden daha önce de bahsetmiştim. (Örneğin “object-oriented” kavramının “nesne-yönelimli” ya da daha da yanlış olarak “nesne-tabanlı” olarak çevrilmesi ile ilgili bu yazıya bakılabilir.)

Bu yazıda bu tip çevirilerden ikisine dikkat çekmek istiyorum: İlki “annotation” kelimesinin “dip not” olarak çevrilmesi. “Annotation” Java’ya 5 versiyonuyla gelen özelliklerden birisi ve “annotation”ları, bazen kod üretme, bazen de konfigürasyon amaçlı olarak uzun süredir kullanmaktayız. Pek çok Javacı, popüler bir Java bileşeni olan JPA ayarlarını, genelde XML yerine annotation denen elemanlarla yapmayı tercih eder. Bu annotationlar başlarında “@” işaretiyle kullanılır ve değişkenler gibi, nitelenen diğer dil elemanlarının hemen öncesine, ya da geleneksel olarak bir üst satırına yerleştirilir. Yani

 

@Entity(name="Person")
@Table(name="Persons")
public class Person{

   @Id
   private String tckn;
   ...
}

örneğinde olduğu gibi. Çok sıklıkla, “annotation” kelimesinin dilimize, özellikle JPA ile ilgili yazılarda “dip not” diye çevrildiğini görüyorum. İki problem var burada: İlki “annotation”, bir yazıya yapılan herhangi bir nottur. Bir yazıda bazı yerleri sarı kalemle işaretlemek ya da çizmek bile “annotation”dur İngilizce’de, yani not alma, notlandırma, işaretleme vb. kelimelerle dilimize çevrilecek bir harekettir. Her not bu anlamda bir dipnot değildir, olması da gerekmez. İkincisi ve ironik olanı, JPA’da olup da “dip not” olarak çevrilen bu “annotation”lar, yukarıdaki örnekten de görüleceği üzere “dip”te değil, aksine nitelediği dil elemanının öncesinde/üstünde yazılır :). Bu Java’nın bir kuralıdır.

Çeviri konusunda esas “chicken translation” örneği bu değil. Esas bomba, yine JPA ile ilgili olarak, uygulamadaki nesnelerin ilişkisel veri tabanındaki tablolar, nesnelerin değişkenlerinin ise tablolardaki kolonlar ile “eşleştirilmesi”nin dilimize “haritalama” olarak çevrilmesi. Sebebi, bu kavramın İngilizcesi olan “object-relational mapping” tamlamasında “map” kelimesinin geçiyor olması. Eeee, tabi taa İngilizce öğrendiğimiz ilk yıldan bu yana biliyoruz, “map” “harita” demek. Dolayısıyla bu tamlama da “nesne-ilişkisel haritalama” olarak çevrilmelidir. Halbuki işin ruhu, yapılan işin mahiyeti ele alındığında ki bunu ayrıntılı olarak bu yazıda açıkladım, olan biten şey, iki farklı ortamdaki yazılım elemanının birbiriyle eşleştirimesi ya da birbirlerine karşı getirilmesidir. Bu durum bir maçta, savunan takımın oyuncularının, hücum eden takımın oyuncularını, savunma amacıyla “alması” ya da onlarla “eşleşmesi”nden başka birşey değildir. JPA’daki bu “eşleştirme” işlemi o kadar da işin merkezindedir ki, anlamak için öyle çok da uzman olmaya gerek yoktur. Örneğin, 5 günlük bir JPA ya da Hibernate eğitiminin ilk bir ya da iki saatinde bu eşleştirmeyi katılımcılara anlatmış ve basit de olsa bir örneğini vermiş oluyorum ben. Ondan sonra eğitim yoğun olarak bu eşleştirmeyle geçiyor. Yani buradaki durum, zamanında, kendilerine saygım sonsuz olmakla birlikte, “object-oriented” terimini dilimize, bu kavramın neyi ifade ettiğini, pratikte dillerde nasıl kullanıldığını tamamen bilmeden, iyi niyetle bir sözlük çevirisi yapanların halinden daha berbat. JPA ya da bunun en yaygın ürünü olan Hibernate’i, üniversitede bir Bilgisayar Mühendisliği 2. yıl öğrencisi biliyor, eşleştirme işini pratik olarak da bizzat yapıyor. Dolayısıyla aklım, yapılanın tabiatının “bir karşı getirme” ya da “eşleştirme” olduğunu bilmemize rağmen, neden sözlükte “map” kelimesinin ilk anlamını alıp, “haritalama” diyerek yeni bir “chicken translation” komedisi yaratıyoruza takılmadan edemiyor. Halbuki, biraz İngilizce bilen, “map” kelimesinin farklı bağlamlarda kullanıldığını ve bilmem kaç yüzyıl önce etimolojik olarak harita kavramından çıksa bile artık genel olarak İngilizce’de bir karşı getirme, bir eşleştirme anlamına geldiğini bilir. Örneğin, matematik’teki fonksiyonlar bir “mapping” yani karşı getirme ya da eşleştirmedir.

Gün geçmiyor ki yenilerde Facebook vb. yerlerde, eskilerde forum vb. paylaşım ortamlarında, “eğitimsiz” olduğunu düşündüğümüz özellikle esnaf kesiminden olan insanların yanlış ya da komik İngilizce tercümeleri yayınlanmasın. Peki biz “eğitimli”ler niye aynı şeyi yapıyoruz? “Batı’dan kopyalamak” acaba eğitimle falan ilgisi olmayan, tamamen kültürel bir öğe olarak taa zihnimizin derinliklerine işlemiş bir hastalık mı yoksa?

Merak ediyorum, “map” kelimesini “harita” diye çevirenler Windows’daki “Map Network Drive”ı nasıl çeviriyorlar? Ya da “Director or his/her proxy must be present in the meeting” kelimesindeki “proxy”i de bir ağ (network) elemanı olarak mı düşünüyorlar?

Her çeviri bir yorumdur. Her yorum da kaçınılmaz olarak %100 nesnel olamaz, bunun farkındayım. Ama yukarıdaki örneklerin bununla yakından uzaktan alakası yok malesef.

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

Java Persistence API (JPA) ile Programlama – I

Java, Java Dersleri, Java EE , , , ,

Aşağıdaki yazı Java Dergisi’nin 2. sayısında yayınlanmıştır. Küçük değişikliklerle burada tekrar yayınlıyorum.

Giriş

Üç yazıdan oluşacak “JPA Programlama” isimli yazı dizisinin bu ilk kısmında, önce nesne-ilişkisel uymsuzluğunu ele alıp hızlıca tarihi olarak bu uyumsuzluğu gidermek için ortaya çıkan çözümlerden bahsedeceğiz Sonrasında Java’nın bu konudaki en son bileşeni olan JPA’ya (Java Persistence API) giriş yapacağız. Bu yazıda, JPA’in en temel özelliklerini, basit nesne-ilişkisel eşleştirmesini, EntityManager API’sini ve EntityTransaction nesnesiyle işlem (transcation) yönetimini ele alacağız. Sonraki iki yazıda daha karmaşık, MxN gibi, nesne-ilişkisel eşleştirmelerini ve diğer eşleştirme özelliklerini, nesne sorgulama (Object Query) yeteneklerini ve bir uygulama sunucusunun bulunduğu ortamda (managed) JPA davranışı ile JPA 2.0’ın getirdiklerini ele alacağız.
okumaya devam …

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

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ı: 1657