Klonlanabilirlik neden reddedilmiyor?

Genellikle CloneableJava'daki arayüzün bozulduğu anlaşılmaktadır . Bundan bahsetmeyeceğim birçok neden var; diğerleri zaten yaptı. Aynı zamanda Java mimarlarının kendilerinin de konumudur .

Benim sorum şu: neden henüz kullanımdan kaldırılmadı? Çekirdek Java ekibi kırıldığına karar verdiyse, kullanımdan kaldırmayı da düşünmeliler. Bunu yapmama nedenleri nelerdir (Java 8'de hala kullanımdan kaldırılmamıştır )?

1997'de Java Bug Veritabanına yöntem ekleme konusunda gönderilen bir hata var , bu yüzden artık işe yaramaz. "Düzeltilmez" çözünürlüğü ile kapatıldı ve gerekçe aşağıdaki gibidir:clone()Cloneable

Sun'ın Teknik İnceleme Komitesi (TRC) bu konuyu uzun süre değerlendirdi ve mevcut Klonlanabilir arayüzün belgelerini iyileştirmek dışında herhangi bir işlem yapmamanızı tavsiye etti . İşte tavsiyenin tam metni:

Varolan Java nesnesi klonlama API'leri sorunludur. Java.lang.Object üzerinde korumalı bir "klon" yöntemi vardır ve java.lang.Cloneable bir arabirim vardır. Amaç, bir sınıf başkalarının onu klonlamasına izin vermek istiyorsa, Klonlanabilir arayüzü desteklemeli ve varsayılan korumalı klon yöntemini bir genel klon yöntemiyle geçersiz kılmalıdır. Ne yazık ki, buğulanma zamanlarında uygun bir şekilde kaybedilen nedenlerden ötürü, Klonlanabilir arayüz bir klon yöntemi tanımlamaz.

Bu kombinasyon oldukça fazla karışıklığa neden olur. Bazı sınıflar Klonlanabilir'i desteklediğini iddia eder, ancak yanlışlıkla klon yöntemini desteklemeyi unutur. Geliştiriciler, Cloneable'un nasıl çalışması gerektiği ve klonun ne yapması gerektiği konusunda kafası karışık.

Maalesef, Cloneable'e bir "klon" yöntemi eklemek uyumsuz bir değişiklik olacaktır. İkili uyumluluğu bozmaz, ancak kaynak uyumluluğunu bozar. Anekdot kanıtları, pratikte sınıfların Klonlanabilir arayüzü desteklediği, ancak bir genel klon yöntemi sağlayamadığı birkaç vaka olduğunu göstermektedir. Tartışmadan sonra, TRC oybirliğiyle uyumluluk etkisi nedeniyle mevcut Klonlanabilir arayüzü DEĞİŞTİRMEMEMİZİ önerdi.

Alternatif bir teklif ise, Cloneable'nin amaçlanan amacını yansıtmak için java.lang.PubliclyCloneable yeni bir arayüz eklemekti. 5 ile 2 çoğunluk arasında TRC buna karşı çıktı. Ana endişe, bunun zaten karışık bir resme daha fazla karışıklık (yazım karışıklığı da dahil!) Ekleyeceğiydi.

TRC oybirliğiyle , nasıl kullanıldığını daha iyi tanımlamak ve uygulayıcılar için "en iyi uygulamaları" tanımlamak için mevcut Cloneable arayüzüne ek belgeler eklememizi önerdi .

Dolayısıyla, bu doğrudan kullanımdan kaldırılmayla ilgili olmasa da, Klonlanabilir "kullanımdan kaldırılmamış" olmamasının nedeni, Teknik İnceleme Komitesinin mevcut belgeleri değiştirmenin bu arayüzü kullanışlı hale getirmek için yeterli olacağına karar vermesidir . Ve öyle yaptılar. Java 1.4'e Cloneablekadar aşağıdaki gibi belgelenmiştir:

Bir sınıf, Object.clone () yöntemine, o yöntemin o sınıfın örneklerinin alandan alana kopyasını almanın yasal olduğunu belirtmek için Cloneable arabirimini uygular.

Klonlanabilir arabirimi uygulamayan örneklerin klonlanması girişimleri, CloneNotSupportedException özel durumunun atılmasına neden olur.

Cloneable arabirimi hiçbir yöntem bildirmez.

Java 1.4'den (Şubat 2002'de piyasaya sürüldü) mevcut sürüme (Java 8) kadar bu gibi görünüyor:

Sınıf, Object.clone () yöntemine, o yöntemin o sınıfın örneklerinin alandan alana kopyasını almanın yasal olduğunu belirtmek için Cloneable arabirimini uygular. Klonlanabilir arabirimi uygulamayan bir örnekte Object'in klon yöntemini çağırmak, CloneNotSupportedException özel durumunun atılmasına neden olur.

Kural olarak, bu arabirimi uygulayan sınıflar ortak bir yöntemle Object.clone'u (korunan) geçersiz kılmalıdır. Bu yöntemin geçersiz kılınmasıyla ilgili ayrıntılar için bkz. Object.clone ().

Bu arabirimin klon yöntemini içermediğini unutmayın. Bu nedenle, bir nesneyi yalnızca bu arabirimi uyguladığı gerçeği nedeniyle klonlamak mümkün değildir. Klon yöntemi yansıtıcı olarak çağrılsa bile, başarılı olacağının garantisi yoktur.

"Neden Cloneableitiraz edilmiyor ?" (ya da gerçekten, neden kimse için Xitiraz edilmiyor X), onları itiraz etmeye çok dikkat edilmediğidir.

Son zamanlarda kullanımdan kaldırılan çoğu şey, kaldırılacak belirli bir plan olduğu için kullanımdan kaldırılmıştır. Örneğin, addPropertyChangeListenerve removePropertyChangeListeneryöntemleri LogManager edildi Java SE 8 kullanımdan kaldırılmış Java SE 9. bunları kaldırarak niyetiyle (nedeni gereksiz yere modül bağımlılığını karmaşık olmasıdır.) Nitekim bu API'ler zaten edilmiştir erken JDK 9 kaldırıldı gelişme oluşturur. (Benzer özellik değişikliği dinleyici çağrılarının da kaldırıldığını unutmayın Pack200; bkz. JDK-8029806 .)

Böyle benzer planı için için vardır Cloneableve Object.clone().

Daha uzun bir yanıt, bu API'lara ne olacağını umabileceğiniz, kullanımdan kaldırıldıklarında platforma hangi maliyetlerin veya avantajların tahakkuk edeceği ve bir API kullanımdan kaldırıldığında geliştiricilere ne iletileceği gibi başka soruların tartışılmasını içerecektir. Bu konuyu son JavaOne konuşmam, Borç ve Kullanım Dışı Bırakma'da araştırdım . (Slaytlar bu bağlantıda mevcut; video burada .) JDK'nın kullanımdan kaldırılmasında çok tutarlı olmadığı ortaya çıkıyor. Örneğin,

• Bu tehlikelidir ve bunu kullanmanın risklerinin farkında olmalı (: örnek Thread.stop(), Thread.resume()ve Thread.suspend()).

• Bu, gelecekteki bir sürümde kaldırılacak

• Bu kullanılmıyor ve farklı bir şey kullanmanız iyi bir fikir (örnek: içindeki yöntemlerin çoğu java.util.Date)

Bunların hepsi farklı anlamlardır ve bunların farklı alt kümeleri, kullanımdan kaldırılan farklı şeyler için geçerlidir. Ve bunların bazı alt kümeleri, kullanımdan kaldırılmayan şeyler için geçerlidir (ancak bu, kullanımdan kaldırılmalıdır).

Cloneableve Object.clone()tasarım kusurları olduğu ve doğru kullanılması zor olduğu için "kırılır". Bununla birlikte, clone()hala dizileri kopyalamanın en iyi yoludur ve klonlamanın, dikkatlice uygulanan sınıf örneklerinin kopyalarını oluşturmak için bazı sınırlı faydaları vardır. Klonlamayı kaldırmak, birçok şeyi bozacak uyumsuz bir değişiklik olacaktır. Bir klonlama işlemi farklı bir şekilde yeniden uygulanabilir, ancak muhtemelen daha yavaş olacaktır Object.clone().

Bununla birlikte, çoğu şey için bir kopya oluşturucu klonlamaya tercih edilir. Bu nedenle, belki Cloneablede "eski" veya "geçersiz" olarak işaretlemek veya benzer bir şey uygun olabilir. Bu, geliştiricilere muhtemelen başka bir yere bakmak istediklerini söyleyecektir, ancak klonlama mekanizmasının gelecekteki bir sürümde kaldırılabileceğini göstermez. Ne yazık ki, böyle bir işaretleyici yoktur.

Bazı şeyler durdukça, "kullanımdan kaldırılma", ortadan kaybolan az sayıdaki kullanımdan kaldırılmış özelliğin kaldırılmış olmasına rağmen, nihai olarak kaldırılması anlamına geliyor gibi görünüyor ve bu nedenle, klonlama mekanizması için kullanımdan kaldırılması gerekli görünmüyor. Belki de gelecekte geliştiricileri alternatif mekanizmalar kullanmaya yönlendiren alternatif bir işaret uygulanabilir.

GÜNCELLEME

Hata raporuna biraz ek geçmiş ekledim . JVM spesifikasyonunun erken JVM uygulayıcısı ve ortak yazarı Frank Yellin, diğer cevapta alıntılanan TRC önerisindeki "zaman sislerinde kayıp" yorumuna yanıt olarak bazı yorumlar yaptı . Burada ilgili bölümlerden alıntı yaptım; mesajın tamamı hata raporundadır.

Cloneable, Serializable ile aynı nedenden ötürü yöntem içermez. Cloneable, sınıfın desteklediği yöntemler hakkında özel bir şey söylemek yerine sınıfın bir özelliğini belirtir.

Yansımadan önce, bir Nesnenin sığ bir kopyasını oluşturmak için yerel bir yönteme ihtiyacımız vardı. Böylece Object.clone () doğdu. Ayrıca, birçok sınıfın bu yöntemi geçersiz kılmak isteyeceği ve her sınıfın klonlanmasını istemeyeceği açıktı. Bu nedenle Cloneable, programcının niyetini göstermek için doğdu.

Kısacası. Cloneable'un amacı, genel bir clone () yönteminiz olduğunu göstermek değildi. Object.clone () kullanarak klonlanmaya istekli olduğunuzu belirtmek içindi ve klon () 'u herkese açık hale getirip getirmeyeceğinize karar vermek uygulamaya bağlıydı.

neden henüz onaylanmadı?

Çünkü JCP buna uygun görmedi ve bunu asla yapamayabilir. Onlara sor. Yanlış yerde soruyorsun.

Bu şeyi Java API'sında tutmanın nedenleri nelerdir?

Geriye dönük uyumluluk gereksinimi nedeniyle hiç kimse Java API'sından hiçbir şeyi kaldırmayacaktır. Son kez 1996/7 yıllarında AWT olay modelinde 1.0 ile 1.1 arasında değişiklik yapıldı.