Scala i Java w jednym stały domu, a JVM pod spodem nie wadząc nikomu.

Scala i Java razem, a jednak osobno

Jedną z dużych zalet Scali jest fakt, iż skompilowany kod może być uruchamiany w maszynie wirtualnej Javy.

Co to w zasadzie znaczy i dlaczego jest to zaleta? 

To znaczy, że kompilator Scali kompiluje kod dokładnie tak samo, jak kompilator Javy. No dobra, to DUŻE uproszczenie 😉 Najważniejsze jest, że w obu przypadkach jest generowany bytecod rozpoznawalny przez JVM.

Jeśli interesuje Cię, jak dokładnie działa kompilator Scali, to znalazłem dla Ciebie świetny artykuł na ten temat -> Scala Compiler Phases with Pictures.

Warto też wiedzieć, że kompilator Scali niestety jest WOLNY. SBT robi co może, żeby kompilację przyspieszyć, analizując zmiany w kodzie i kompilując wyłącznie to, co zostało zmienione, ale wykonanie pełnego buildu dużej aplikacji może trwać i trwać.

More...

Znam dwa rozwiązania tego problemu.

Pierwszy to użycie narzędzia scalac-profiling, który pokaże, które miejsca w kodzie są szczególnie długo kompilowane, dzięki czemu (jeśli mocno Ci na tym zależy), można spróbować te fragmenty kodu przerobić.

Opis użycia tego narzędzia (dla zaawansowanych) znajdziesz w kolejnym artykule -> Speeding Up Compilation Time With Scalac-profiling

Drugie rozwiązanie (dla bogatych) to użycie kompilatora Hydra. Standardowy kompilator Scali, bez względu na moc komputera zawsze używa do kompilacji tylko jeden rdzeń. Hydra w inteligentny sposób dzieli kod na paczki i kompiluje go w sposób równoległy, używając wielu rdzeni. Niestety jak wspomniałem wcześniej, nie jest to rozwiązanie tanie. Jeśli jednak czas kompilacji jest kluczowy w przypadku Twojego projektu, może warto rozważyć to narzędzie -> Hydra - pricing

Wróćmy teraz jednak do drugiego członu pytania. 

Dlaczego fakt kompilacji Scali do bytecode to zaleta?

To akurat proste. Świat Javy jest OLBRZYMI i rozpościera się na niemal na wszystkie gałęzie biznesu. Natomiast sam język programowania cóż. Pozostawia wiele do życzenia. Oczywiście jest nieustannie rozwijany. Niestety (a może stety), jeśli chodzi o wygodę kodowania i elastyczność składni wciąż pozostaje daleko za Scalą. 

Właśnie dlatego namawiam wszystkich, którzy chcą wejść w świat JVM, żeby zamiast Javy wybrali Scalę, a tych, którzy od lat tworzą w Javie i są nią zmęczeni podsuwam Scalę jako rozwiązanie ich problemów.

Scala da Ci możliwość wyboru w jaki sposób chcesz pisać kod. Świat programowania funkcyjnego staje przed Tobą otworem, ale tylko jeśli chcesz, nikt Cię nie zmusza.

Jaki jest poziom współpracy na poziomie języków pomiędzy Scalą i Javą?

Jest to doskonale opisane w rozdziale 11 książki -> Scala in Action. W uproszczeniu można napisać, że współpraca jest niemal 100%. W Scali można używać wszystkich rozwiązań znanych z Javy (choć nie zawsze jest to zalecane). Chcesz Hibernate? Proszę bardzo, Tomcata? Kto Ci zabroni. 

Masz część bibliotek w projekcie napisanych w Javie? Możesz używać ich do woli w kodzie Scali. Klasy, typy danych, kolekcje. Wszystko to jest do Twojej dyspozycji.

Napisałem wcześniej, że możesz tego wszystkiego używać, ale nie zawsze jest to zalecane, pozwól że napiszę Ci dlaczego. Używając rozwiązań javowych w swoim kodzie należy się liczyć z koniecznością obsługi zmienności danych (mutability), wyjątków i nulli.

Dlatego zawsze warto najpierw sprawdzić, czy nie ma już gotowej Scalowej biblioteki rozwiązującej problem, który masz na tapecie, zamiast ślepo sięgać po biblioteki i frameworki Javowe.

Chcesz Nauczyć Się Scali?

Jestem tutaj, by Ci pomóc.