Java'nın yeni gelişimi Scala ve Clojure gibi dillerle birlikte çalışabilirliğini nasıl etkileyecek?


11

Anladığım kadarıyla, hem Scala hem de Clojure yeni diller olarak tasarlandı

  1. JVM'ye bağlıdır ve
  2. Scala ve Clojure kodunda Java sınıflarının kullanılmasına izin vermeleri açısından Java koduyla kolayca entegre edilebilir.

Java 8 ile başlayarak (ve belki de Java'nın sonraki sürümlerinde daha da güçlü bir şekilde), Java dilinin anlamında değişiklikler olacaktır.

Bu değişikliklerin Java ile Scala / Clojure arasındaki birlikte çalışabilirliği nasıl etkileyeceğini ve sonuçlarının ne olacağını sormak istedim. Örneğin, Java 8'deki lambdaslar nesne olmadığından (örneğin buraya bakın ), Scala ve Clojure'un nesne olmayan Java değerleriyle uğraşması gerekebilir. Bu bir sorun olur mu?

Aşağıdaki senaryoları düşünebilirim:

  1. Scala veya Clojure dili, yeni Java semantiğine uyum sağlamak (yeni nesne dışı değerleri işlemek için) ve Java ile birlikte çalışabilirliği desteklemek için genişletilecektir.
  2. Scala veya Clojure dil olacak değil uzatılabilir. Bu, ancak işlev değerleri gibi yeni Java özellikleri mevcut kavramlarla eşlenebilirse mümkün olabilir. Örneğin, Scala'da bir fonksiyon bile bir nesnedir, bu yüzden Java fonksiyonlarının Scala için görünür hale geldiklerinde yine bir tür nesneye sarılacağını düşünüyorum.
  3. Scala veya Clojure dili, Java'nın en son geliştirmelerini takip etmeden Java 6 veya 7'ye kadar birlikte çalışabilirliği desteklemeye devam edecektir. Bu, Java'nın eski sürümlerinin hala desteklenmesini gerektirir (en azından OpenJDK veya başka bir proje tarafından), böylece bu diller Java'nın daha muhafazakar / kararlı bir dalına dayanabilir.

Özetleme: Java'nın gelecekteki gelişiminin, Java ile birlikte çalışabilirliği sağlamak için Scala ve Clojure gibi diller üzerinde bir etkisi olmasını bekleyebilir miyiz? Bu konuyla ilgili devam eden bir tartışma var mı?

Not

Scala, Clojure ve diğer JVM tabanlı dillerin uygulamalarını JVM'nin daha yeni sürümlerine güncellemede büyük sorunlar yaşamayacağını hayal edebilirim (ve yeni JVM özelliklerinin bu uygulamayı daha da kolaylaştıracağını). Sorum, Java'nın bir dil olarak özellikleri ve diğer JVM dilinin, JVM tabanlı dillerin en son JVM'lerde çalışıp çalışmayacağını değil, bu yeni özellikleri "görüp göremeyeceği / kullanıp kullanamayacağı / nasıl kullanacağına / odaklanmasına odaklanıyor.


6
Scala vs.'nin Java'ya bağlı olduğunu söylemek kesin değildir. JVM bayt koduna bağlıdır. Tüm birlikte çalışabilirlik özellikleri Java dili kaynak kodu ile değil, bayt kodu ile ilgilidir, bu nedenle Java'nın kendisinde yapılan değişiklikler tehdit değildir. Sadece JVM'de yapılan değişiklikler bu dilleri etkileyebilir ve JVM son derece muhafazakardır - temelde hiçbir şey için desteği kaldırmaz. Aslında, günümüzde JVM'deki çoğu değişiklik özellikle daha yeni dinamik diller için tasarlanmıştır .
Kilian Foth

@Kilian Foth: Bildiğim kadarıyla Scala Stringbir Java String. Bu yüzden Scala belirli Java kitaplığı sınıflarını kullanır. Ama çok güçlü olduğunu düşünüyorsanız formülasyonu değiştirebilirim.
Giorgio

@Kilian FOTH: Ben terim kaldırdık bağlı Soruma odağı Scala ve Java arasında sırasıyla uyumluluğun sağlanması ile ilgili oldukça çünkü. Clojure ve Java.
Giorgio

@KilianFoth Bu sorunun bir cevabı olmalı çünkü sorunun en büyük endişesini gideriyor. Herhangi bir yeni Java sürümünün bir numaralı hedefi geriye dönük uyumluluktur.
maple_shaft

3
@maple_shaft: Sorumu düzelttim ve "bağımlı" kelimesini kaldırdım. Başka bir yorumda belirttiğim gibi, benim sorunum Scala veya Clojure'un Java veya JVM özelliklerine nasıl bağlı olduğu değil, Scala / Clojure'un Java özelliklerini nasıl "görebildiği". Bildiğim kadarıyla Java 6 sınıfları, arayüzleri, nesneleri, yöntemleri, ilkel veri türleri gibi özelliklerini görebiliyorlar. Bu, Scala / Clojure'un Java 6 kodunu kullanmasını (çağırmasını) sağlar. Benim sorum şu, bu diller aynı zamanda gelecekteki Java dili yapılarını "görecek" (ve bu nedenle kullanabilecektir) mi yoksa Scala / Clojure dillerine uzantılar gerektirecek mi?
Giorgio

Yanıtlar:


15

Aslında Java 8, Java ile birlikte çalışan diğer JVM dillerine zararlı olacak pek bir şey tanımaz. Lambdas üzerinde yapılan çalışma, invüinamik, MethodHandles, MethodReferences vb. Bununla birlikte, diğer JVM dillerinin potansiyel olarak arayabileceği yepyeni bir API grubu var. Hangilerini varsayılan olarak kullanacaklar veya kullanmayacaklar.

Birlikte çalışmayı etkileyen en büyük değişiklik aslında Java 7 ile geldi - JVM içindeki dinamik / geç bağlama çağrılarına izin veren invokeinamik bytecode ile - başlangıçta JVM'deki diğer diller için tasarlanmış bir şey. O zamandan beri Lamdbas için çok kullanışlı bir şekilde uyarlandı, bu yüzden Java 8'den itibaren Java aslında bu bayt kodları yaymaya başlayacak.

Bazı diller (örneğin JRuby) zaten invüinamik kullanıyor, diğerleri (Scala, Groovy ve diğerleri) hala kullanımını araştırıyor veya yamalamanın ilk aşamalarında. Teorik olarak, dinamik çağrılarını neredeyse mümkün olduğunca performans gösteriyor Java, geçmişte kullanmak zorunda kaldıkları sayısız yavaş geçici çözümün aksine, çağrışımsız çağrılar yapar.

Java 9, geleneksel sınıf yüklemesi ve JVM için sınıf yolları için sonun başlangıcı olacak olan Jigsaw projesi ile platforma gelen JVM dilleri için daha fazla zorluk getirecek. JVM dil halkı bunun oldukça farkında ve bazı makul işbirliklerinin olmasını bekliyorum.


1
Ama bildiğim kadarıyla Scala'nın kapanması bir nesnedir.
Giorgio

1
Evet. Scala sadece yakın zamanda Java 1.5 desteğini düşürdü, 1.6 düşene kadar uzun zaman alacak .
Jörg W Mittag

1
@Giorgio Java'nın dil özellikleri, yine de derlendiğinde bayt kod numaralarına eşit olduğu için önemsizdir. JVM'nin her zaman geriye doğru uyumlu olacağını kabul edersek, yeni bayt kodları kullanılsa bile, Scala bundan etkilenmeyecek ve bu yeni JVM özelliklerinden yararlanmayı seçebilir.
maple_shaft

1
"Java'nın dil özellikleri, yine de derlendiğinde bayt kodu numaralarına eşit olduğu için önemsizdir.": Başka bir dil bir Java yapısı kullanmak istiyorsa, o yapı için oluşturulan bayt kodunu tanıyabilmelidir. Java, yeni bayt koduyla eşleşen yeni bir yapı tanıtırsa, ana bilgisayar dili, en azından yeni bayt kodunu tanımak ve kullanmak için yeni bir sarıcı / arabirim uygulamalıdır. Örneğin, bir Java 8 lambda bir nesne oluşturmadıysa, ancak bunun için yeni, belirli bayt kodlu yeni bir yapı oluşturduysa, ana bilgisayar dili onu tanıyacak şekilde uyarlanmalıdır.
Giorgio

2
@Giorgio: Elbette, ancak Java 8 platformu için böyle bir değişiklik planlanmıyor. Aslında, JVM'lerle sadece uzatıldı iki kez 2003 ve 2010 yıllarında, Java Platform tüm tarihinin ve ikinci kez (giriş invokedynamicbayt) desteği dillerine özellikle idi diğer Java fazla; aslında, Java 7 dil değil desteklemek ya da bu bayt kodu kullanın.
Jörg W Mittag

2

Scala, Java lambdas eklediğinde geride bırakılmak üzeredir, çünkü Java lambdaslara kullanıldıkları içeriğe göre bir tür atandığı halde, Scala lambdas'lara, değişkenlerine, parametre türlerine ve dönüş türlerine göre bir tür atanır;

executor.execute(() -> { System.out.println("hello world"); });

Java 8'den Scala'da şu şekilde yazılabilir:

executor execute new Runnable {
    override def run() { println("hello world") }
}

Scala's () => Unit'i Runnable'a dönüştüren bazı sarmalayıcılar kullanmazsanız / yazmazsanız.


Cevabınız için ve ayrıca soruma cevap verdiğiniz için teşekkürler (+1). Doğru anlarsam, Scala, Java 8'in lambdas kullanacağı bir bağlamda arayüzleri başlatmak için anonim sınıfları kullanmaya devam etmelidir (çünkü Java 8 lambdasları Scala lambdas'dan farklı bir semantiğe sahiptir). Benim için açık olmayan bir başka nokta, bir Java yöntemi bir Java lambda döndürürse ne olacağıdır. Bir Scala sınıfı bu yöntemi çağırırsa ne olur? Scala'da dönüş türü ne olacak?
Giorgio

1
@Giorgio Java 8'de lambda ifadesi, tek bir yöntemi bildiren ve bağlama göre ertelenen bir arabirim örneği oluşturmak için dil düzeyinde bir kısayoldur. Java 8 yöntemi lambda döndürdüğünde, aslında yöntemin dönüş türü olarak bildirilen bir arabirim örneği döndürür. Scala 2.9.1 itibariyle dönüş türü bazı arayüz söz hakkından basitçe bir örnek (Runnable veya karşılaştırıcı) olacak değil Scala siz veya gelecekteki bültenleri o bir örtük dönüştürme tanıtmak Libary sürece, bir Scala lambda olarak tedavi Scala lambda tipine arayüz.
hellodanylo

@SkyDan: Tamam, Scala Java lambdaslarını bir arayüz uygulayan nesneler olarak görecek. Bu nokta benim için net değildi: Java'nın bir nesneninkinden farklı bir bayt kodu üreteceğini düşündüm. Ancak başlık altında bir nesne olmalıdır, aksi takdirde bir arayüzün uygulanması olarak kabul edilmez. Sanırım şimdi anladım.
Giorgio

@Giorgio, ayrıca Java 8'deki lambda ile ilgili değişiklikler ve bu değişiklikleri yönlendiren güçler hakkında daha fazla bilgi edinmek istiyorsanız , Lambda projesinin bu büyüleyici ve ayrıntılı genel görünümünü okumanızı tavsiye ederim .
hellodanylo

@SkyDan: Şimdi okuyorum. Lambda'lar geliyor bana do (tip / arayüz tanımlandıkları içerikten çıkarılır olsa bile) nesneleri temsil eder. Bu nedenle mail.openjdk.java.net/pipermail/lambda-dev/2011-August/… ("lambdalar nesne değildir") adresinde verilen bilgiler yanlış veya en azından yanıltıcıdır.
Giorgio
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.