Previous
Next

Yaz saati uygulaması ve tzupdater ile java güncellemesi yapılması

by Cem Kefeli 10. Ekim 2016 22:09

Yaz saati uygulaması Türkiye'de 1972 yılından 2016 yılına kadar doğrudan enerji tasarrufu amaçlı olarak gün ışığından daha fazla faydalanabilmek amacıyla uygulanmıştır. Bu uygulama ile birlikte ilkbahar aylarının başlangıcında saatler bir saat ileri alınır ve Türkiye saati UTC+3 olur. Sonbahar aylarının sonuna doğru ise saatler bir saat geri alınarak ülke zaman dilimi UTC+2'ye geri döner ve yaz saati uygulaması ise son bulmuş olur. Yani aslında Türkiye'nin gerçek zaman dilimi UTC+2 olarak belirlenmiştir. UTC+3 ise yaz saati uygulaması için geçici bir süreliğine geçilen bir zaman dilimidir.

2016 ekim ayı itibari ile ise Bakanlar Kurulu'nun 2013'de almış olduğu ama 2016'ya kadar uygulanmayan karar (Resmi gazete 2016/9154) doğrultusunda saatlerin geri alınması uygulamasına son verilmiştir. Yani artık tüm yıl boyunca yaz saati uygulanmasının kullanılması ya da kış saati uygulamasının ülke genelinde son bulması kararlaştırılmıştır.

Özellikle bankacılık ve iletişim sektörü için bu durumdan nasıl etkilenileceği, olumsuz etkilerinin neler olacağının tartışıldığı bir ortamda bilişim sistemleri de kendisini yeni karara adapte etmeye çalışıyor. Binlerce ve hatta çok büyük olasılıkla on binlerce sistem bu karar için elden geçiriliyor... İşletim sistemlerine yamalar yükleniyor, veritabanlarına yamalar yükleniyor, vb... Bu bağlamda kurumsal birçok yazılımın vazgeçilmezi olan Java için de yeni koşullara ayak uydurabilmenin bazı şartları bulunuyor.

iana.org üzerinden indirebileceğiniz bir time zone (tz) güncellemesi ile Java kurulumunuzu Türkiye için yeni time zone'a uygun hale getirebilirsiniz. Aşağıda yüklemenin nasıl yapılacağını göstermeye çalışacağım fakat bununla birlikte bu güncellemenin etkilerinin de neler olacağını görebilmek, analiz edebilmek için birkaç satırdan oluşan bir test kodu yazdım ve yaşadıklarımı aşağıdaki gibi aktarmaya çalışıyorum;

Java test kodumuz aşağıdaki gibi;

Time Zone test uygulaması  |  Gizle  |  Göster
package datetimeapp;

import java.text.SimpleDateFormat;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.util.Date;

/**
 *
 * @author cem.kefeli
 */
public class DatetimeApp {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("dd.MM.yyy HH:mm:ss.SSS");
        
        ZonedDateTime zonedDateTime_Local = ZonedDateTime.now();
        Date dateTime_ZonedLocal = Date.from(zonedDateTime_Local.toInstant());        
        System.out.println("dateTime_ZonedLocal: "+simpleDateFormat.format(dateTime_ZonedLocal));
        
        ZoneId zoneId_Turkey = ZoneId.of("Europe/Istanbul"); // Europe/Istanbul +02:00/+03:00
        ZonedDateTime zonedDateTime_Turkey = ZonedDateTime.of(LocalDateTime.now(), zoneId_Turkey);
        Date dateTime_ZonedTurkey = Date.from(zonedDateTime_Turkey.toInstant());        
        System.out.println("dateTime_ZonedTurkey: "+simpleDateFormat.format(dateTime_ZonedTurkey));
        
        ZoneId zoneId_Any = ZoneId.of("Asia/Baku"); // Asia/Baku +04:00
        ZonedDateTime zonedDateTime_Any = ZonedDateTime.of(LocalDateTime.now(), zoneId_Any);
        Date dateTime_ZonedAny = Date.from(zonedDateTime_Any.toInstant());        
        System.out.println("dateTime_ZonedAny: "+simpleDateFormat.format(dateTime_ZonedAny));
    }
}

Eğer bu kodu derleyerek çalıştıracak olursanız aşağıdaki gibi bir çıktı ile karşılaşıyor olacaksınız. Şu anda yaz saati modunda ve UTC+3 zaman diliminde olduğumuz için Bakü yerel zaman dilimi ile aramızdaki zaman farkı bir saat olarak görülecektir. Sistem zamanı ve java zamanı ise aynı görülüyor.Fazlası...

Java Server Faces (JSF) nedir?

by Cem Kefeli 17. Mayıs 2016 05:49

Tüm java makalelerime buradan ulaşabilirsiniz...Java

Java Server Faces (JSF) kavramını anlatabilmek için ilk önce Java'nın bu güne kadar sunmuş olduğu önyüz/arayüz dinamik yapılarını incelemek gerekir diye düşünüyorum.

En başa java servlet'ler yerleşir ki java servlet'ler 1990'lı yıllardan ve de JDK 1.0'dan bu yana hayatımızdadırlar. Güncel versiyonu 4.0'dır ve en son J2EE 8 ile birlikte duyurulmuştur. Temel olarak sunucuya gelen HTTP isteğini keser, ilgili kod parçacığını çalıştırarak yorumlar, ve de istemciye bir cevap dönerler. Servlet'ler içerisinde java kodları bulunur ve istemciye gönderilecek HTML çıktılar bu kodların içerisinde barındırılırlar. Yani servlet teknolojisinde Java kodu içerisine HTML kodları gömülebilir.

İkinci sırada Java Server Pages (JSP) teknolojisi gelmektedir ki aslında JSP'ler de çalışma mantığı olarak yine servlet'ler üzerine kuruludurlar. Arka planda çalışan aslında bir servlet'tir. Fakat uygulamayı yazan kişi bu arka plandaki durumu görmez. Farkı ise JSP'lerin kodlama mantığının HTML üzerine kurulu olmasıdır. Nasıl ki yukarıda bahsettiğim gibi servlet'lerde java kodları arasında HTML kullanılıyorsa, JSP'lerde de HTML içerisine java kod parçacıkları gömülebilmektedir. HTML öğeleri örneğin formlar, tablolar, imajlar doğrudan JSP içerisindeyer alırlar. JSP'ler, servletlere göre görselliği daha ön plana çıkaran yapılar sunar.

Java Servlet, JSP, JSF Historyt

Şimdi asıl konu olan JSF'lere dönelim. Servler'ler ilk ortaya çıktığı gün, günün ihtiyaçlarını karşılıyorlardı. Bir süre sonra görselliği ön plana alan JSP teknolojisi ortaya çıkıverdi. JSP bir nebze olsun görsellik konusunu ileriye taşıdı ama aranan kan halen bulunamamıştı aslında. JSF'nin duyurulması ile birlikte hem kod katmanına hem de görsel katmana hitap eden bir yapı ortaya çıktı. C#, C++ ya da java gibi dillerle masaüstü uygulaması geliştirenler bilirler, form üzerine yerleştirdiğiniz nesnelere aksiyonlar atayabilirsiniz. Örneğin forma bir buton yeteştirdiniz üzerine çift tıklarsanız butona tıklandığında çalışacak olan listener'a ulaşmış olursunuz. Bu listener, kod bloğu, içerisine buton tıklandığında yapılması istenen işlere ait dilediğiniz gibi kod yazabilirsiniz. İşte JSF ile birlikte masaüstü programlamanın bu güzel görsel yapısı bir nebze olsun WEB ile de buluşmuş oldu. JSF ile birlikte artık hem HTML kod tarafında bir kaynak kodumuz, hem de pure java tarafında bir kaynak kodumuz bulunuyor, ve de framework sayesinde bu ikisi arasında bir etkileşim de mevcut.
Fazlası...

Java Memory Yönetimi

by Cem Kefeli 3. Şubat 2016 02:39

En sıkıntılı konulardan birisidir bir uygulamayı geliştirirken ve de canlıya alınması sonrasında karışılaşılan memory problemleri. Eğer geliştirme aşamasında tecrübelerinizden de faydalanarak olası memory problemlerini öngörebilirseniz canlıya çıkış sonrası oluşabilecek problemleri azaltabilirsiniz. Ya da daha geliştime ve test aşamasında bir memory problemi ile karşılaşırsanız, ki genelde uygulama gerçek yük altında çalışmaya başladığında açığa çıkarlar, fix etme imkanınız olur ve şanlısınız demektir.

C/C++ ile uygulama geliştirdiyseniz bilirsiniz ki bellek yönetimini tamamen geliştiriciye bırakır. Geliştirici istediği adresteki istediği bellek gözüne kadar herşeye hakimdir. Örneğin işaretçiler yardımıyla bellek gözlerini dilediği gibi yönetebilirler. Bu durum iyi kodlanmış yazılımlar için daha optimal memory kullanımlarını birlikte getirir. Düşünsenize tasarladığınız yazılımın her bir byte seviyesinde her bir bellek gözüne hakimsiniz ve nerede ne var tamamen biliyorsunuz, işlerinizi ona göre planlıyorsunuz. Ama ya iyi kodlanmamış bir yazılım varsa elinizde? Belki de iyi bir uygulama geliştirici değilsinizdir... Bellek yönetiminin esnekliği yerini bir anda bir kaos ortamına bırakıverir. Belki erişmemeniz gereken, sizin olmayan bir bellek gözlerine erişirmişsiniz ve hata alırsınız. Belki de ayırdığınız bellek alanlarının dışına çıkarsınız çalışma anında ve de yine hata alırsınız...

Bununla birlikte eğer nesle yönelimli (Object Oriented Programming - OOP) bir yazılım dili kullanarak uygulama geliştiriyorsanız sevindirici haberler de vardır. OOP konsepti herşeyi birer nesne olarak ele almak istediği için, nesnelerin varlığından ve de yokluğundan haberdar olmak isterler. Nesneleri doğduğu andan öleceği ana kadar takip ederler. Nesne doğduğu anda ona bir yuvacık sunarlar. Biraz ergenleştiği zaman onu yuvacıktan alıp yeni bir yuvaya nakleder ki yeni doğanlara yer açılsın. Nihayetinde zaman gelip de nesnenin ömrü dolduğunda kalıcı olarak yuvayı bozarlar ve nesne de artık yok olur. Bu yuva ve yuvacıkları bellek bölümleri olarak düşünebilirsiniz. Yuvaların tahsisi konusunu yöneten bir birim de vardır tabiki ve örneğin java için bu işi üstenen Garbage Collector (GC)'dür. GC, neslerin ömrü boyunca bellek işlerinden sorumlu müdürlüktür. Yeri geldiğinde kullanılmayan nesneleri de temizleyerek ilgili belleğin tekrar kullanılabilmesi amacıyla geliştiricinin hizmetine sunar. Geliştirici bu konseptte bellek işleri ile ilgilenmez.

Java Memory Management
Fazlası...

JAVA - Thread kavramı ve Thread Dump

by Cem Kefeli 15. Mayıs 2015 05:50

Tüm java makalelerime buradan ulaşabilirsiniz...Java

Daha önce çok kanallı programlama nedir ve ne işe yarar türünden soruların cevabını bulabilmek amacıyla buradaki (Çok kanallı/Multi-Threaded programlama) yazımda daha çok konsept olarak ele almıştık thread kavramını. Bu yazıda ise bir java uygulaması ayakta ve çalışır durumdayken thread'ler ile ilgili başımıza gelebilecekler problemli senaryoları nasıl yorumlamamız gerektiği karşımıza çıkıyor olacak.

Uygulamada oluşturulan her bir thread'in tabiki uygulama sunucuda da bir karşılığı olmak durumunda. Yani bir yazılım içerisinde oluşturulan thread'lerden her birisi uygulama sunucusu tarafından da yönetilebilir ve takip edilebilir olmalı. Kurumsal uygulamaların çok çok büyük bir kısmı aynı anda birden çok iş yapabilecek şekilde dizayn ediliyorlar. Hal böyle olunca da birçok thread aynı anda çalışmak durumunda kalıyor. Aynı anda çalışan bu iş parçacıkları ise yaptıkları işlerin niteliğine göre farklı sürelerde işlerini tamamlayabiliyorlar. İşlerini tamamlayan thread'ler üzerine düşeni yapmış olmanın sevinciyle köşelerine çekiliyorlar ve başka thread'lere yer bırakıyorlar.

İşte tam bu aşamada gerçek hayatımıza geri dönecek olursak, thread'ler ile ilgili belki de en problematik durumun köşelerine çekilemeyen, bir nedenle işlerini tamamlayamayan kod parçacıkları olduğunu göreceğiz. Kod parçacığı diyorum çünkü problematik durumlar için bir kusur aramak gerekirse bunun kusurlusu thread mantığı ya da thread'in ta kendisi değildir. Thread nihayetinde içerisinde bulunan kod parçacıklarının işlevini yerine getiriyor. Asıl önemli olan, iş yapan kod parçacığının ne kadar kaliteli dizayn edildiğidir.

Gerçek hayattan bir sorun anını ele alalım. Örneğin bir iş parçacığı yaptığı işin bir bölümünde bir WEB servise istek yapıyor ve cevap bekliyor olsun. Burada biz cevap beklediğimiz için kendimize müşeri diyebiliriz. Herşey yolundayken, cevap beklenilen servis tıkır tıkır cevap veriyorken uygulamacının yani müşterinin hayatını kaotik olarak etkileyen pek birşey yoktur. Ama işler ters gitmeye başladığı ve cevap beklenilen servis cevap veremez hale geldiği zaman, siz de bir anda cevap veremez hale gelebilirsiniz, sizin de müşterilerininiz artık beklemeye başlar. Bir anda bakmışsınız servis alınan hat boyunca herkes birbirini bekliyor...

Java Thread Life CycleTam da "Biz acaba neyi bekliyoruz?" sorusuna cevaptır "Neden thread dump'a ihtiyacım var?" konusu. Uygulama thread'lerinin anlık bir görüntüsüdür, thread dump. O an hangi thread'ler aktif, hangi class'lar iş yapıyor, nerede bekleniyor sorularının yüzelsel olarak cevaplarını verebilir. Oluşan dump dosyasının içeriği ve formatı kullanılan JVM'in versiyonuna, sağlayıcısına göre değişecektir. Unix/Linux temelli sistemlerde basit bir şekilde "kill -3 <Process ID>" komutu yardımıyla oluşturulabilir. Oluşan dump içeriği genellikler 'out' loga yazılıyor olur ama yine uygulama sunucusuna ve JVM'e göre değişiklik gösterecektir. Örneğin Websphere için farklı bir dosya olarak profil altına atılacaktır.

Aldığınız dump dosyasını bir 'Thread Dump Editor' ile inceleyecek olursanız thread'lerin statülerinin yandaki şekilde gösterilenlerden birisi olduğunu görürsünüz. İsimleri yine JVM'den JVM'e değişebilir ama anlamları aynı olacaktır. Dump incelenirken asıl odaklanılması gereken 'Blocked' ya da 'Stuck' olarak bahsedilen bir süredir işini yapmaya çalışana ama bir türlü bitiremeyen thread'ler olmalıdır. 

Hakkımda...

Cem KEFELİ

Electronics and
Telecommunication Eng.
devamı...


Son yapılan yorumlar...

Comment RSS

Yasal bir uyarı...

Disclaimer"Bu web sitesinde görmüş olduğunuz bilgilerin, dokümanların ve diğer materyallerin kullanılmasından doğabilecek hiç bir sorumluluktan site sahibi sorumlu tutulamaz. Web sitesi içerisinde yer alan yazılar, yorumlar, resimler ve diğer tüm içerikler yalnızca sahibinin görüşünü yansıtmakta olup içeriğin sahibi kişilerin çalıştığı kurumları bağlayıcı hiç bir nitelik taşımamaktadır. Yapılan tüm alıntılar mutlaka kaynak gösterilerek verilmeye çalışılmaktadır. Web sitesi içerisinde bulunan ilgili materyaller, ilgili yasal kurumlar tarafından uygun görülmemesi durumda kaldırılacaktır."
General