Java, kararlılık, geriye dönük uyumluluk, olgun araçlar, güvenlik seçenekleri ve ölçek için kurulmuş geniş bir ekosistem sayesinde hâlâ kurumsal ortamların tercihleri arasında yer alıyor.
Java, çoğu teknolojinin güncellenme sıklığından daha fazla kez "öldü" ilan edildi. Yine de bankalarda, sigorta şirketlerinde, perakendecilerde, havayollarında, telekom operatörlerinde ve devlet kurumlarında Java hâlâ her yerde—çekirdek işlem sistemlerini, entegrasyon katmanlarını, iç platformları ve yüksek trafikli müşteri servislerini çalıştırıyor. Trend olan ile ölçekte dağıtılmış olan arasındaki bu fark, sorunun sürekli yeniden gündeme gelmesinin nedeni: Java 25+ yıl sonra neden hâlâ büyük kuruluşlarda bu kadar yoğun kullanılıyor?
Bu sadece "büyük bir şirket" demek değil. Yazılım açısından büyük bir kuruluş genellikle şunları ifade eder:
Böyle bir ortamda dil seçimi yalnızca bu çeyrek için geliştirici verimliliğiyle ilgili değildir. Önemli olan, on yıl boyunca desteklenebilir, test edilebilir ve yönetilebilir olanı seçmektir.
Bu soruyu soranlar genellikle birkaç pratik gücün etrafında dolaşıyor: kararlılık ve geriye dönük uyumluluk, JVM ekosisteminin derinliği, olgun araçlar ve test uygulamaları, geniş işe alım havuzu ve kanıtlanmış yollara yönelik risk yönetimi.
Bu yazı Java'nın her şey için "en iyi" olduğunu iddia etmiyor. Bunun yerine, Java'nın belirli kurumsal işler için neden varsayılan bir tercih olmaya devam ettiğini ve hangi durumlarda diğer dillerin daha uygun olabileceğini açıklıyor.
Büyük kuruluşlar yazılıma yılda bir yenileme gibi yaklaşmaz. Birçok çekirdek sistemin 10–20 yıl çalışması ve evrilmesi beklenir. Bu zaman ufku "ilgili"nin anlamını değiştirir: en yeni sözdizimi değil, iş değişirken, düzenlemeler ve altyapı etrafında güvenle özellik sunmaya devam etme yeteneği önemlidir.
Kurumsal uygulamalar genellikle faturalama, lojistik, kimlik, risk veya müşteri verilerinin merkezinde durur. Bunları değiştirmek nadiren temiz bir başlangıç projesidir; paralel çalıştırmalar, veri mutabakatı ve sözleşmesel yükümlülüklerle çok yıllı bir geçiştir. Yeniden yazmak sadece mühendislik emeği değil—operasyonel bir kesinti yaratır.
Bir platformun net yükseltme yolları, kararlı semantik ve uzun dönem destek seçenekleri varsa, ekipler değişiklikleri “büyük patlama” yerine yönetilebilir adımlar serisi olarak planlayabilirler. Bu öngörülebilirlik şunları azaltır:
Satın alma, denetimler ve iç yönetişim önemlidir. Kuruluşlar genellikle belgelenmiş destek yaşam döngüleri, güvenlik yama süreçleri, satıcı sorumluluğu ve tekrarlanabilir dağıtım kontrolleri ister. Standartları, olgun destek seçenekleri ve bilinen işletme uygulamaları olan bir dil/runtime, her çeyrekte değişen hızlı bir araç zincirinden daha doğal bir şekilde bu gereksinimlere uyar.
Kurumsal ortamda ilgi şu ölçülebilir çıktılarda görünür:
Java yaygın diye değil, şirketler yeni dilleri görmezden geldiği için değil; değişimin maliyeti yüksek olduğu için ve öngörülebilir, yönetilebilir ilerlemenin genellikle kazanan strateji olduğu için hâlâ tercih ediliyor.
Kuruluşlar Java'yı trend olduğu için seçmez. Yazılım yıllarca, birçok ekip arasında ve sıkı değişiklik kontrolleri altında çalıştırılacaksa öngörülebilir olduğu için seçerler.
Geriye dönük uyumluluk şunu ifade eder: Java'yı veya bir kütüphaneyi yükselttiğinizde, mevcut kodunuz büyük olasılıkla aynı şekilde çalışmaya devam eder. Platform ilerledi diye uygulamanın büyük bölümlerini yeniden yazmanız gerekmez.
Bu basit gibi görünse de büyük işletme etkisi vardır. Bir çekirdek faturalama, lojistik veya risk sistemi yükseltmeden sonra bozulursa maliyet sadece geliştirici zamanı değildir—kesinti, ertelenmiş sürümler ve uyumluluk sorunları doğurabilir.
Java'nın runtime'ı (JVM) ve standart API'leri dikkatle değişir. Özellikler eklenir, eskiler kademeli olarak kullanımdan kaldırılır ve geçiş için net yollar vardır. Bu kararlılık, kuruluşların yükseltmeleri acil projeler yerine rutin bakım olarak planlamasına imkân verir.
Ayrıca uzun ömürlü yatırımları korur: iç çerçeveler, entegrasyonlar ve operasyona yönelik araçlar bir gecede değersiz hale gelmez.
Kararlı bir platform kademeli modernizasyona olanak tanır:
Bu, birçok değişikliğin aynı anda geldiği ve neyin bozulduğunu izole etmenin zor olduğu “büyük patlama” yeniden yazımlarına kıyasla riski azaltır.
Yaygın bir desen, güvenilir bir Java çekirdeğini (kayıt sistemleri) korurken kenarları modernize etmektir: yeni API'ler, UI katmanları, event streaming veya mikroservisler. Önemli olan yeniliği risk almadan uygulamak; temeli değiştirmeye kumar oynamak değil.
Java'nın kalıcılığı sadece dil sözdizimiyle alakalı değil. JVM ve onlarca yıldır sektörlerde test edilmiş bir ekosistem söz konusu.
JVM, işletim sistemleri ve donanımlar arasında aynı bytecode'un tutarlı davranışla çalışacağına dair güvenilir bir çalışma zamanı sözleşmesi sağlar. Bu taşınabilirlik, on‑prem sunucular, farklı Linux dağıtımları ve çoklu bulut ortamlarına sahip olduğunuzda önemlidir. Ayrıca "benim makinada çalışıyor" sürprizlerini azaltır çünkü runtime iyi tanımlanmış ve yoğun şekilde kullanılıyor.
Aynı zamanda JVM bir platformdur, tek bir dil değil. Ekipler ihtiyaç duyduklarında Java ile Kotlin, Scala veya Groovy karışımı kullanabilir; paketleme, izleme ve işletme için tek bir runtime modeli korunur.
Büyük kuruluşlar defalarca benzer problemleri çözer: API oluşturma, veritabanı ve mesajlaşma ile entegrasyon, servis güvenliği, iş zamanlama, belge üretimi ve gözlemlenebilirlik. JVM ekosisteminde bu ihtiyaçların neredeyse tamamı için olgun seçenekler vardır; bu da değerlendirme döngülerini kısaltır ve özel altyapı inşa etme ihtiyacını azaltır.
Bu araçlar uzun zamandır üretimde kullanıldığı için uç durumlar bilinir, belgelenmiştir ve genellikle kararlı sürümlerde zaten düzeltilmiştir.
Bir şey gece 2'de bozulduğunda olgunluk dakikalar kazandırır. Önceden yapılmış rehberler, runbook'lar, postmortem'ler ve hata giderme kaynakları derin bir birikim sunar; mühendisler kanıtlanmış çözümleri hızla bulabilir.
Bu bilgi birikimi olay anındaki çözme süresini kısaltır: daha az bilinmezlik, daha net tanılama ve daha öngörülebilir yükseltme yolları—her saatin bir fiyatı olduğunda kuruluşların istediği budur.
Kuruluşlar sadece bir dil seçmez—bir işletme modeli seçer. Java'nın uzun süreli avantajı, büyük, uzun ömürlü kod tabanlarını güvenli şekilde değiştirmeyi kolaylaştıran olgun araçlar ve alışkanlıklarla çevrili olmasıdır.
Çoğu Java ekibi kodu derin şekilde anlayan zengin IDE'lerde çalışır: binlerce dosyada anında gezinme, güvenli refaktör önerileri ve erken sorun tespiti sağlarlar. Bir şey bozulduğunda debugger'lar ve profiler'lar, gerçek iş yüklerinde ortaya çıkan performans sorunlarını nerede yaşandığını belirlemede yardımcı olur—kritik bir ihtiyaç.
Büyük şirketler tekrarlanabilir derlemelere güvenir: aynı proje bir dizüstü bilgisayarda, CI'da ve üretimde aynı şekilde derlenmelidir. Java'nın yaygın build araçları ve bağımlılık uygulamaları, birçok servis ve ekip arasında sürümlerin tutarlı tutulmasını kolaylaştırır. Bu da "benim makinada çalışıyor" sürprizlerini ve bir kütüphanenin yamalanması gerektiğinde yaşanacak kesintileri azaltır.
Java ekosistemleri katmanlı testi teşvik eder: günlük iş için hızlı birim testleri, servis sınırları için entegrasyon testleri ve kritik akışlar için uçtan uca kontroller. Zamanla bu kurumsal bir emniyet ağına dönüşür—ekipler refaktör ve modernizasyon yaparken testler koruyucu bariyer görevi görür.
Üretimde olup biteni anlamak, özellikler kadar önemlidir. Java ekipleri genellikle loglama, metrik ve tanılama standardizasyonu yapar; böylece olaylar hızlı ve tutarlı şekilde incelenebilir. Yüzlerce servis içindeyken bu paylaşılan uygulamalar kısa kesinti ile uzun kesinti arasındaki farkı yaratabilir.
Kurumsal sistemler genellikle teorik pik hız peşinde koşmaz. Kazanan, karışık ve dalgalı iş yükleri altında öngörülebilir şekilde hızlı olandır—ay sonu yükleri, gürültülü komşular, çeşitli veri şekilleri ve uzun çalışma süreleri gibi. Java'nın en büyük performans avantajı tutarlılıktır: ekipler kapasite planlayabilir, SLO belirleyebilir ve trafik değiştiğinde sürpriz regresyonlardan kaçınabilir.
Ara sıra çok hızlı ama sık sık düzensiz bir runtime operasyonel yük getirir: daha fazla aşırı kaynak ayırma, daha fazla olay süresi ve değişiklik konusunda daha az güven. Java'nın JIT derlemesi ve adaptif profilleme gibi optimizasyonları, servisler ısındıktan sonra tutarlı sonuçlar verme eğilimindedir; bu da çoğu kurumsal sistemin sürekli çalıştırılma biçimiyle örtüşür.
Java uzun süredir çeşitli ölçekleme stillerinde kullanıldı:
Kuruluşlar nadiren tek bir kalıp işletir; hepsini aynı anda çalıştırırlar.
Günümüz JVM'leri "hot" kod yollarını agresifçe optimize eder ve farklı ihtiyaçlar için çöp toplayıcılar sunar—etkileşimli servisler için düşük gecikme veya batch için yüksek verim gibi. Genellikle uygulamayı yeniden yazmak yerine GC ve tuning profili seçilir.
Performans tartışmaları çıktılara bağlandığında eyleme dönüştürülebilir:
Bu ölçüm-öncelikli yaklaşım Java'nın güçlü olduğu alandır: performans gözlemlenebilir, ayarlanabilir ve iyi anlaşılmıştır.
Büyük kuruluşların ihtiyacı sadece "güvenli yazılım" değil—yıllar boyunca öngörülebilir güvenliktir. İşte bu noktada Java'nın LTS seçenekleri ve düzenli güvenlik güncellemeleri önem kazanır. LTS sürümleriyle organizasyonlar bir sürüm üzerinde standartlaşabilir, yamaları düzenli uygulayabilir ve denetim döngüleriyle uyumlu bir yükseltme takvimi planlayabilir.
Güvenlik genelde tek bir özellik değil; projelerin çoğunda ortaya çıkan gereksinimler kümesidir:
Java ekosistemi bu ihtiyaçları geniş kabul görmüş kütüphaneler ve standart tabanlı entegrasyonlarla destekler. Bu, uyumluluk beklentilerini karşılamayı kolaylaştırır çünkü yerleşik kontrollere, tekrarlanabilir yapılandırma kalıplarına ve iyi anlaşılmış işletme uygulamalarına işaret edebilirsiniz.
Zafiyetler bulunduğunda, olgun ekosistemler daha net yanıt yollarına sahiptir: advisory'ler, yamalanmış sürümler, bağımlılık güncellemeleri ve etkilenen bileşenleri bulup düzeltmeye yardımcı araçlar. Pek çok kuruluş için bu “iş akışı hazır olması” düzeltmeden en az onun kadar önemlidir—özellikle güvenlik ekiplerine, denetçilere ve düzenleyicilere yapılan dokümantasyon gerektiğinde.
Java güvenliği yönetişimi kolaylaştırabilir, ama güvenli sonuçları garanti etmez. Yama disiplini, bağımlılık yönetimi, sır yönetimi, güvenli yapılandırma ve iyi izleme uygulamaları uygulamanın gerçekten güvenli olup olmadığını belirler. Java'nın avantajı, bu uygulamaların büyük organizasyonlarda iyi desteklenmiş ve tanıdık olmasıdır.
Kuruluşlar sadece bir dil seçmez—bir işgücü pazarı seçer. Java'nın üniversitelerde, bootcamp'lerde ve kurumsal eğitimlerde uzun süredir var olması, projeleri bölge bölge personele tekrar eden bir risk olmadan doldurabilmenizi sağlar.
Java geliştiricileri her kıdem seviyesinde ve çoğu büyük şehirde bulunur; bu da ekip büyüdükçe işe alımı daha az oynak hale getirir. Piyasa sıkışsa bile Java rolleri genellikle yeni yığına göre daha istikrarlı bir arz sunar. Bu, bir yıl içinde 10–50 mühendis eklemeniz gerektiğinde önemlidir, yalnızca tek bir uzman değil.
Çünkü Java yaygın olarak öğretilir ve iyi belgelenmiştir, yetkin bir mühendisin (C#, Kotlin, hatta Python geçmişi gibi) rampa süreci de genellikle niş bir ekosisteme göre daha öngörülebilirdir.
Büyük organizasyonlar insanlar arasında rotasyon yapar, birleşmeler sonrası ekipleri birleştirir ve işleri lokasyonlar arasında taşır. Java ile yeni katılanlar genellikle zaten "temel konuşmayı" bilir; böylece işe alım alanı daha çok alan ve sistemlere odaklanır—sözdizimi ve araçları sıfırdan öğrenmek yerine.
Bu ayrıca kritik kişi riskini azaltır. Birçok kişi kodu okuyup sürdürebiliyorsa, izinler, ayrılmalar ve reorganizasyonlar teslimatı aksatmadan yönetilebilir.
Büyük bir yetenek havuzu dış kaynak kullanımı, denetimler ve kısa süreli danışmanlık desteği seçeneklerinizi genişletir—özellikle düzenlemeye tabi projelerde dış incelemeler gerekebilir.
Java ayrıca çoklu ekip yapılarıyla iyi uyar: konvansiyonlar olgun, frameworkler standartlaşmış ve paylaşılan kütüphaneler/platform ekipleri birçok ürün ekibini sürekli yeniden keşfetmeye gerek bırakmadan destekleyebilir.
Konteynerler ortaya çıktığında Java “eski” olmadı—sadece birkaç pratik ayar gerektirdi. Bugün birçok kuruluş Java iş yüklerini Kubernetes ve yönetilen konteyner platformlarında çalıştırıyor çünkü paketlenmiş servisler, tekrarlanabilir dağıtımlar ve net kaynak sınırları Java sistemlerinin kurumsal olarak inşa ve yönetildiği modeli iyi tamamlıyor.
Tipik bir desen, kendi içinde çalışabilen bir servis (genellikle Spring Boot, Quarkus veya Micronaut) küçük bir konteyner imajı içinde paketlenir ve sağlık kontrolleri, otomatik ölçekleme ile blue/green veya canary dağıtımları ile konuşlandırılır. JVM konteyner-dostudur, bu yüzden öngörülebilir bellek davranışı ayarlayıp orkestrasyon altında hizmetleri stabil tutabilirsiniz.
Java yaygındır:
JVM ekosistemi ölçüm, tracing ve yapılandırılmış loglama için güçlü destek sunduğundan Java servisleri genellikle mevcut platform araçlarına az sürtünmeyle entegre olur.
Kuruluşlar nadiren kritik sistemleri tek seferde "swap" eder. Daha sık görülen, kanıtlanmış Java çekirdeklerini korumak (faturalama, kimlik, fulfillment) ve etraflarını modernize etmektir: servisleri kademeli olarak çıkarmak, API katmanları eklemek ve dağıtımı konteynerlere taşımak.
-XX:MaxRAMPercentage) ve heap'i doğru boyutlandırın.Büyük kuruluşlar nadiren tek bir dil çalıştırır. Bir iş süreci mobil uygulama, .NET servis, Python veri hattı, bir satıcı SaaS aracı ve onlarca yıllık mainframe'i aynı anda içerebilir. Bu gerçeklikte en değerli sistemler güvenilir şekilde bağlanan sistemlerdir—her ekibi aynı teknolojiye zorlamadan.
Çoğu çapraz‑ekip entegrasyonu birkaç tekrarlanabilir temas noktasına iner:
JVM ekosistemi bu birleşme kalıplarının neredeyse hepsi için olgun sürücüler, istemciler ve kütüphaneler sunduğu için Java bu kesişimlere iyi uyar.
Kuruluşlar sıkça API gateway'ler, entegrasyon servisleri, iç SDK'lar, iş akışı motorları gibi paylaşılan platformlar için Java'yı seçer—çünkü ortamlar arasında öngörülebilir davranır ve standartlara güçlü destek sunar. Bir Java "yapıştırıcı" servisi modern ekiplere temiz bir API sunarken arka uç sistemin gerektirdiği protokolleri konuşabilir.
Bu sebeple ödemeler, telekom ve lojistik gibi entegrasyon ağırlıklı alanlarda Java sıkça kullanılır: zorlu kısım tek bir algoritma değil, birçok sistemi güvenli şekilde koordine etmektir.
Birlikte çalışabilirlik açık kontratlar etrafında tasarlandığında kolaylaşır:
Java burada iyi çalışır çünkü bu standartların üzerine oturabilir ve mimarinizi tek bir satıcıya veya runtime'a bağlamaz.
Kuruluşlar bir dili startup gibi seçmez. Yazılım faturalama, ticaret, lojistik veya kimlik sistemlerini çalıştırdığında gerçek hedef öngörülebilir çıktılardır: daha az sürpriz, daha az olay ve daha kolay bütçeleme. Bu bağlamda “sıkıcı” genellikle “iyi anlaşılmış” demektir.
Gözle görülen maliyet mühendislik zamanıdır, ama daha büyük kalemler sonradan çıkar:
Java seçmek bilinmeyenleri azaltmaya yardımcı olur; bu nicelendirilemeyen ama 7/24 çalışması gereken sistemlerde hissedilebilen bir avantajdır.
Risk çerçevesi önemlidir. Karar verici sadece bir dil almıyor; öngörülebilir sürüm takvimleri, güvenlik yama süreçleri ve operasyonel playbook'ları olan bir ekosistem satın alıyor. Java'nın uzun ömrü sayesinde birçok uç durum keşfedilmiş, belgelenmiş ve hafifletilmiştir—özellikle denetimin tekrarlanabilir kontroller istediği düzenlenmiş sektörlerde.
Yeni stack'ler şu durumlarda daha iyi olabilir:
Bu kazanımları destek, işe alım, olay müdahalesi ve uzun vadeli bakım gibi tam işletme modeli ile karşılaştırın.
Sorun: Dil değişikliği iş sonuçlarını ölçülebilir şekilde iyileştirir mi (piyasa çıkış süresi, güvenilirlik, uyumluluk maliyeti, müşteri deneyimi) yoksa sadece trende uyum mu? Yükseliş belirsizse, "sıkıcı" kalmak genellikle en rasyonel seçenektir.
Yeniden yazımlar temiz bir sayfa vadeder ama kuruluşlarda genelde uzun süreli eşzamanlı sistemler, ertelenmiş değer ve beklenmedik davranış boşlukları yaratır. Java varlıklarını modernize etmek, zaten iş değeri üreteni tutup nasıl inşa edildiğini, test edildiğini ve dağıtıldığını kademeli olarak iyileştirmekle en iyi sonuç verir.
Pratik bir sıra, önce riski azaltmak sonra teslimat hızını artırmaktır.
Amaç sadece "daha yeni Java" değil—daha hızlı, daha güvenli teslimat. Build'leri standartlaştırın, tutarlı bir test stratejisi benimseyin, statik analiz ekleyin ve CI/CD iyileştirmeleriyle geri bildirim döngülerini kısaltın. Birçok ekip sadece tekrarlanabilirliği (aynı derleme her yerde) ve görünürlüğü (daha iyi log, metrik, uyarı) iyileştirerek büyük kazançlar görür.
Bir pratik taktik, Java çekirdeğinin etrafında daha hızlı teslimat araçlarıyla modernize etmektir. Örneğin ekipler çoğunlukla yeni dahili portallar veya yardımcı servisler prototiplerken çekirdeği sabit tutar. Koder.ai gibi bir platform ekiplerin yapılandırılmış sohbetten bir React web uygulaması veya küçük bir Go + PostgreSQL servisi üretmesine yardımcı olabilir; bu, kavram kanıtları, back-office araçları veya yeni UI katmanları için değerli olabilir—hız önemli ama Java çekirdeği düşük riskle kalmalıysa ideal.
Java ile devam edin when:
Bölümleri taşımayı düşünün when:
Bir ürün alanı seçin, 90 günlük bir modernizasyon hedefi belirleyin (tabanı yükselt + yüksek değerli bir refaktör), başarı metriklerini tanımlayın (lead time, change failure rate, incident hacmi) ve yineleyin.
Bir yol haritasına ihtiyacınız varsa, sistemlerinizi risk ve değişim sıklığına göre envanterleyin ve değere göre modernize edin—önce değer, sonra drama.
Çünkü kuruluşlar uzun yaşam döngülerinde öngörülebilir değişimi optimize eder. Java, kararlı yükseltme yolları, LTS (uzun dönem destek), olgun operasyon pratikleri ve geniş bir ekosistem sunar—bu da kritik sistemleri 10–20 yıl çalışır tutmanın riskini ve maliyetini azaltır.
Bu bağlamda genellikle şunlar kastedilir:
Bu kısıtlar, ölçekli olarak yönetilebilir ve kararlı teknolojileri tercih etmeyi destekler.
Yeniden yazımlar riski çoğaltır:
Bunun yerine kademeli modernizasyon (runtime yükseltmesi, modül refaktörü, sınırlandırılmış servis çıkarımı) genellikle daha az kesintiyle ve daha kısa sürede değer sunar.
Uygulamanız ve bağımlılıklarınız JDK veya ortak kütüphaneler yükseltildiğinde muhtemelen aynı şekilde çalışmaya devam eder.
Pratikte bu şunlara imkan verir:
JVM, farklı işletim sistemleri ve ortamlarda tutarlı bir çalışma zamanı sözleşmesi sağlar.
Bu, on‑prem + cloud karışımı, çeşitli Linux dağıtımları ve farklı donanımlar çalıştırıldığında tutarlılık sağlar; paketleme, izleme ve işletme tanımları aynı kalır. Ayrıca JVM, Kotlin gibi farklı dillerin aynı çalışma zamanını kullanmasına izin verir.
Kuruluşlar genelde “önemsiz ama kritik” yapı taşları için Java’ya başvurur:
Avantaj, üretimde denenmiş varsayılan çözümler ve özel altyapı inşa etme ihtiyacının azalmasıdır.
Yaygın yaklaşımlar şunlardır:
Java yardımcı olur çünkü destek modeli ve uygulamalar yaygın olarak anlaşılmıştır—ancak güvenliğin sağlanması hâlâ disipline dayanır.
Büyük ekipler için tekrarlanabilir, sorunsuz derlemeler ve güvenli refaktörler gerekir:
Bu uygulamalar, “tribal knowledge” riskini azaltır ve ekipler arası değişiklikleri daha güvenli hale getirir.
Evet—çoğu kuruluş Java iş yüklerini konteynerlerde ve Kubernetes üzerinde başarılı şekilde çalıştırır. Pratik tavsiyeler:
-XX:MaxRAMPercentage) ve heap boyutunu doğru belirleyinAmaç, orkestrasyon altında öngörülebilir davranıştır—sadece “Docker’da çalışıyor” değil.
Java'yı seçin when:
Başka bir şey seçin when:
Yararlı bir test: dil değiştirmenin iş metriklerini (lead time, incident sayısı, işlem başına maliyet) gerçekten iyileştirip iyileştirmediğini sorgulayın—trend peşinde olmak yeterli değildir.