har Java som sprog problemer? & Alternative jvm sprog.
Jeg have lyst til at svarer på http://www.linuxin.dk/node/19821#comment-75080 men da det ikke har så forfærdeligt meget med emnet at gøre, ville jeg gøre det her i stedet.
Kritikken af Java i tråden er efter min mening noget uretfærdig. Ingen tvivl om at Java har nogle problemer. Jeg kommer undervejs til at nævne Scala nogle gange, da det efter min mening er et fantastik sprog, som også kører på jvm, og løser mange af de problemer som Java har, samt tilføjer en hel del andre gode ting.
Jeg havde tænkt mig denne tråd kunne være en diskution om Java og de potientielle problemer det har, samt hvad nogle af de andre JVM sprog gør for at løse nogle af disse problemer. Jeg kommer undervejs til at nævne Scala nogle gange, da det efter min mening er et fantastik sprog, som også kører på jvm, og løser mange af de problemer som Java har, samt tilføjer en hel del andre gode ting.
Men lad mig da gennemgå listen:
* ingen pointers
Dette er et helt bevist design valg, taget ud fra observationen at pointere forudsager rigtig mange bugs. I mine øjne en rigtig god ide.
* ingen måde at indikere hvad et argument skal bruges til (C++: const/pointer/reference, C#: ref,in,out)
Jeg har ikke arbejdet med meget C# kode, så skal ikke kunne sige hvordan ref,in,out fungere det, men jeg har set rigtig meget C++ kode, hvor const ser ud til at have være til konstant forviring for udviklerne. Uden at vide det med sikkerhed, vil jeg tro at dette også er et bevidst desigvalg, for at ikke at skabe den samme forvirring. I forhold til performence, er langt det meste man parser rundt jo kun referencer til objekter, som ikke er så dyre at kopiere.
* tåbelige ideer (strings == versus .equals ? WTF !)
Kan kun være enig i at denne ikke er helt optimal. Men kan ikke rigtig ændres, da det ville bryde bagud kompabiliteten, hvilket Java stadigvæk har ungået. Scala har ikke dette problem.
* autoboxing -- hvorfor skal *JEG* besværes med problematikker der kun burde vedrøre JVM'en?
Mener absolut ikke det bør være JVM opgave, da JVM jo gerne vil være en virtuel maskine for andre sprog end Java. Gjorde man det til JVM opgave, ville man fjerne mulighederne for at gøre det anderledes i andre sprog.
Scala løser efter min mening dette rigtig elegant. Scala er modsat Java et rent object orienteret sprog, hvilket vil sige, at der ingen primitive datatyper er, eller i hvert fald ikke på overfladen. Når man for eksempel laver en instance af Int, så analysere compilere, om den kan blive representeret som en primær datatype, eller om man på et tidspunkt kalder en metode på den, der ikke gør det muligt, hvorved det i stedet bliver et object. På denne måde har man det rene object orienterede sprog, som dog i langt de fleste tilfælde, performer som brugte man primære datatyper.
* Tåbeligt generics system -- Type erasure, really ?
Enig dette kan være irreterende, men så stort er problemet heller ikke. Det afhænger selvfølgelig af stil og opgaver, men for mit vedkommende (er fuldtid udvikler, hovedsageligt java og scala) vil jeg anslå det til at være 1-2 gange om måneden, at jeg havner i en situation, hvor jeg bliver ramt af dette problem. I langt de fleste tilfælde, ser jeg det selv, og hvis jeg endlig for skrevet noget kode, som er ugyldigt på grund af Type erasure, så brokker copileren sig over det. Under alle omstændigheder er det sjældent vanskeligt at arbejde sig uden om det.
Så helt enig, det er irreterende, men ikke noget kæmpe problem.
En anden problematik omkring dette, er også, om det ville være muligt for andre sprog at lave anderledes type systemer hvis ikke der var type erasure. Jeg har ikke sat mig nok ind i detaljerne, så jeg vil ikke selv udtale mig om hvorvidt det er tilfældet eller ej, men har hørt nogen der påstår at et sprog som scala, for eksempel ikke ville kunne have dets noget mere avancerede type system, hvis ikke Java havde haft type erasure. Begrundelse skulle være, at man uden, ville flytte type systemet fra sproget til JVM, og derved fjerne mugligheden for at ændre på det.
* Checked Exceptions (hvor mange eclipse CTRL-[1] => surround with try-catch clauses som IKKE håndteres giver det ikke?)
Jeg er lidt blandet her. Jeg synes enlig checked exception grundlæggende er en god ide, men er blevet totalt misbrugt, både af rigtig mange 3. parts libraries, men også af ganske mange java lib klasser. Jeg er dog helt enig i at i den form det har nu, er det bare en irretation moment. Scala har også fjernet understøttelsen for checked exception, selv hvis man benytter exceptions fra java, som er checked.
* Endnu flere sjove ting så som arrays er covariante mens generics er contravariante.
Enig i at dette er forvirrende. Jeg vil dog sige, at i forhold til at minimere antallet af bugs, er det en generel god ide, at unlade at bruge arrays, og benytte Collections klasserne i stedet. I så tilfælde slipper man også for denne forvirring.
Scala type system giver i øvrigt muglighed for at vælge hvorvidt en type skal være covariant eller contravariant.
Mangel på stort set alle moderne features:
* funktioner som parametre (eller i det MINDSTE delegates)
Helt enig, det er utroligt Java ikke har dette endnu. Scala har som en funktionelt sprog selfølglig.
* pass by ref (java er pass-by-value only)
Denne påstand er nu ikke helt sand, arrays er faktisk pass by reference. Årsagen til dette er performance, et array kan representere meget store data mængder, som kan være tunge at kopiere.
Ellers vil jeg tro at grunden til det hænger meget med det jeg skrev tidligere i forbindelse med const
* duck typing ?
Det er et statisk typet sprog. Dette er virkelig noget der er forskellige meninger om. Du fremstiller det dog som om at statisk typede sprog er gammeldags, mens dynamisk typede er moderne og smarte. Sådan mener jeg absolut ikke det forholder sig. Jeg mener dog at statisk typede sprog, er langt lettere at vedligeholde og udvikle i. Men det er nok et diskution der bør tages i en 3. tråd, da det i sig selv er et stort emne.
* meta-programming ? (så som memoization der "cacher" resultater for forskellige funktioner givet parametre som er set før)
Annotations er da meta-programming. Der er måske ikke lige en anden memoization funktion, men har da masser af mugligheder for meta-programmering eller misforstår jeg kritik punktet?
* funktionelle ideer: generators, co-routines, map/fold/reduce, predicates, list comprehensions
Helt enig, den funktionelle stil er vejen frem. Igen må jeg henvise til scala, som er et funktionelt sprog.
* Mere fleksibelt mht arv og sammensætning af funktionalitet (C++ & Ruby: Mixins)
Ved ikke lige hvad du mener med sammensætning af funktionalitet.
I forhold til arv, så er multipel arv i c++ kilde til rigtig mange fejl, så tror det er et helt bevist design valg at denne feature ikke findes i Java.
Igen må jeg lige nævne scala, som har en rigtig fornuftig løsning, i form af traits, som giver mange af de samme fordele som multipel arv, men undgår problemerne.
- Log in to post comments
Kommentarer4
Det er en anelse off-topic,
Det er en anelse off-topic, men:
Har du nogen gode guides til at lære Scala, og hvad er det "bedste" IDE/editor til at programmere det i :)
At argumentere på
At argumentere på internettet er noget jeg stort set ikke gider gøre mere.
Hvis du bød mig på en øl kunne vi tage en snak om det. Men ellers er det sgu for meget arbejde at følge ORDENTLIGT op på.
Men ja, java har problemer - det er designet over længere tid hvilket betyder at et forholdsvist simpelt udgangspunkt er blevet bastardiseret og resultatet er at sproget hverken kan udtrykke så meget som andre (med samme elegance/simpelthed - java er nok turing-komplet men at henvise til dette er noget akademisk lort :P)
Java er Pass-By-Value
Er arrays rent faktisk pass-by-ref ? Nope - det virker som ved objekter.
Du kan overbevise dig selv med dette stykke kode skrevet til formålet:
http://pastebin.com/Wv2PuzJ4
Hvad sker der ? Well, java kopierer værdien af et object-id og giver dette som argument (dette virker på samme måde for arrays og objekter). Dvs. referencen peger videre på et objekt og dette objekt kan du ændre. Hvis jeg skriver en metode til at fjerne elementer i mit array eller ændre felter i mit objekt, så vil det virke helt fint.
MEN! Var det pass-by-reference så ville min swap metode rent faktisk swappe de to arrays, dvs. jeg ville modificere mine referencer der peger direkte til mine arrays således at når swap metoden er kørt så ville names1 og names2 pege på andre arrays. Men som sagt KOPIERER java blot objekt-id'erne hvilket betyder at jeg blot ændrer disse "reference" kopier. Det har ikke nogen virkning andetsteds.
Rigtig pass by reference vil være fx denne simple C-funktion:
void swap(int *a, int *b){
int *tmp = a;
a = b;
b = tmp;
}
Der er MANGE der misser denne hage ved java -men det er altså en fejl at kalde det pass-by-ref.
Autoboxing
Du siger du er uenig og jeg gjorde det nok ikke tydeligt nok hvad jeg mente - fordi jeg interesserer mig ikke for hvordan det implementeres så længe det ikke kræver noget specialviden af mig - det skal være "transparent".
Det du beskriver med Scala er netop transparent, jeg skal ikke bryde hovedet med at tilføje integers til min List() med 'l.add( Integer.valueOf(2) );' for at undgå at lave 5000 unikke Integer-objekter alle indeholdende værdien 2.
Men det skal jeg i Java, endnu et komplet design-fail.
Generics, Type Erasure, Really?
>> Enig dette kan være irreterende, men så stort er problemet heller ikke.
<< Jo det er det så - læs fx Bruce Eckel's "Thinking in Java" 4th edition der fra 650-692 gennemgår de oftest-forekomne work-arounds samt det syntaksmæssige hekseri i forbindelse med get-put, bounds, wildcards og type captures.
Hvis du mener en pointer kan forvirre en programmør så ved jeg virkeligt ikke hvad dette helvede kan gøre ved de selv samme. Generics-delen er så kompleks at selv implementørerne bag collections-librariet havde flere fejl der gjorde deres typer unødigt restriktive, se selv IBM's "Going Wild With Generics" (i øvrigt en fandens god artikel) --
The "mistake" in the early version of Box is an easy one to fall into. Even the experts make this mistake — you can find numerous places in the platform class libraries where a Collection is used instead of a Collection<? extends T>. For example, in AbstractExecutorService in the java.util.concurrent package, the argument to invokeAll() was originally a Collection>. This made using invokeAll() fairly cumbersome, though, as this required that the set of tasks be held by a collection parameterized exactly by Callable, and not by a collection parameterized by some class that implements Callable. In Java 6, this signature was changed to Collection<? extends Callable>
("Going Wild With Generics - Part 2" -- http://www.ibm.com/developerworks/java/library/j-jtp07018/index.html )
Humlen er: generics i java er fint nok så længe du *BRUGER* andre folks libraries, men rent at rent faktisk selv skulle implementere klasser der tager imod eller returnerer generiske typer bliver hurtigt noget rod. Det er først når vi snakker bounds mv. at det bliver rigtigt rodet, tag igen et eksempel fra "Going Wild With Generics - Part 2":
public static > void sort(Listlist) { ... }
Hvad gør dette ? Hvilke typer tillades ? Hvorfor bruges super og extend som de gør ? Fortæl mig ikke dette er simpelt eller at Java, som påståes at være begyndervenligt og at fjerne features der tillader fejl, her har en implementation som er forholdsvist let for folk at undgå at lave fejl i ;)
Annotations
Hvis mig venligst hvor annotations rent faktisk gør noget som helst - de er lavet så du selv kan skrive mere smart kode, som (evt. via reflection - a whole different can of worms - ) kan query hvor vidt dine felter, metoder eller klasser har nogle annotationer.
De eneste annotationer der reelt set gør noget er noget nær '@SuppressWarnings' og '@Override' - hvis DU skal gøre noget med dem skal du skrive reflection-kode eller gå i lag med AspectJ/Plastic eller lignende frameworks - hvilket fx Spring gør. Det er muligt at lave frameworks der tillader dig at skrive koncist, men det er forbeholdt dem som skriver større frameworks (igen, så som Swing, Hibernate etc)
Arv fra flere klasser VS Mixins
>>Ved ikke lige hvad du mener med sammensætning af funktionalitet.
>>I forhold til arv, så er multipel arv i c++ kilde til rigtig mange fejl, så tror det er et helt bevist design valg at denne feature ikke findes i Java.
<< Mht. multipel arv, det *er* et design-valg og multipel arv bliver også let noget rod. Du kan evt. slå "the diamond problem" up som er det klassiske eksempel på et problem som arv fra flere klasser medfører.
Mixins er well.. I det korte en måde at skrive 1 klasse med et par felter og nogle metoder hvorefter man så kan annotere en anden klasse som så "in essence" arver denne funktionalitet uden at vi snakker om "Typer" og indfører problemet om typebestemmelse fra diamantproblemet.
(Se evt: http://rubylearning.com/satishtalim/modules_mixins.html for et hurtigt eksempel på mixins)
Anyway, jeg burde virkeligt ikke sidde her og skrive dette, der er sgu nok af eksamenslæsning der venter. Kværulanten i mig vandt dog i denne omgang. Anyway. Jeg vil prøve at holde mig væk men håber du (og andre) fik mere ud af mit rant om hvorfor Java har nogle seriøse skavanker.
Go Scala or go Home!
Sidst men ikke mindst:
Scala er fint som hobby-projekt, men uden reel støtte, uden at Oracle simpelthen adopterede det og sagde "Scala's the way forward" så vil firmaerne fortsat satse på Java. Jeg kender løst til et Java konsulenthus og så vidt jeg kan forstå er deres bread-and-butter fortsat Java, de vil gerne hjælpe folk med Scala men efterspørgslen er der ikke. Hvis alle omkring dig sidder fast på Java og alle libraries skrives på Java (så du i allen faldt skal snakke flydende Java) så forsvinder charmen ved Scala ligesom.
Det bliver ikke bedre at du selv skal hente og installere Scala separat (og antageligvis distribuere dette sammen med dine programmer?) etc etc.
Når det er sagt ville jeg blive *LYKKELIG* såfremt man aflivede Java og gjorde enten Scala eller Groovy til det nye sprog på platformen, men det kommer bare ikke til at ske.
Jeg er desværre ikke
#1:
Jeg er desværre ikke bekendt med nogle gode guides på nettet, men jeg kan varmt anbefale bogen "Programming in Scala" af Martin Odersky, Lex Spoon og Bill Venners. Den giver en meget grundig gennemgang af sproget. En del af det er selvfølgelig lidt banalt hvis man har programmerings erfaring i forvejen, men generelt er den på et ganske højt teknisk niveau. Martin Odersky er i øvrigt hoved designeren af Scala.
Som IDE vil jeg anbefale IntelliJ IDEA. Det er selvfølgelig ved at være noget tid siden, men jeg prøvede både Netbeans (som var den jeg hovedsageligt brugte i forvejen),, eclipse og IDEA.
Eclipse var på det tidspunkt helt håbløs i forhold til Scala support, og da jeg i forvejen ikke er så begejstret for Eclipse blev den hurtigt dropper.
Netbeans var i forvejen min favorit IDE, og den havde da også en Scala modul som fungerede rimeligt, dog uden at være særligt imponerende.
IDEA havde, og har stadig rigtig god scala support, code completion, fejl visninger refactorering mv, virker ganske godt. Der er stadig ikke stykke vej op til hvor godt det virker i Java, men det er godt på vej, og bliver løbende bedre. Dette har faktisk fået mig til at skifte til IDEA som min primærer IDE, selvom jeg stadig bedre kan lidt netbeans på mange områder.
Siden jeg prøvede det af, er det vist sket meget, specielt med Eclipse, men jeg har ikke prøvet det af, da jeg synes IDEA fungere rigtig godt.
Det er godt nok et langt
#3:
Det er godt nok et langt indlæg i forhold til at du ikke gider argumentere på nettet :D
Men ja, java har problemer - det er designet over længere tid hvilket betyder at et forholdsvist simpelt udgangspunkt er blevet bastardiseret og resultatet er at sproget hverken kan udtrykke så meget som andre (med samme elegance/simpelthed - java er nok turing-komplet men at henvise til dette er noget akademisk lort :P)
Jeg henviste på ingen måde til at Java er turing-komplet, er fuldstændigt enig i at det ikke har noget at sige i praksis. Statisk typede sprog har dog andre fordele, som er mindre akademiske. For at tage et af de lidt mere lavpraktiske: uviklings miljøerne bliver stillet overfor en langt nemmere opgave, når de skal implementere support for et sprog hvis det er statisk typet. En IDE der hjælper meget, kan sparer rigtigt meget tid under udviklingen.
Java er Pass-By-Value
Er arrays rent faktisk pass-by-ref ? Nope - det virker som ved objekter.
Du kan overbevise dig selv med dette stykke kode skrevet til formålet:
http://pastebin.com/Wv2PuzJ4
I forhold til pass by ref/value må jeg give dig ret, dit eksempel er meget tydeligt. Jeg var faktisk indtil for nyligt af samme opfattelse, men fik fortalt af en anden at der var en undtagelse med Arrays. Da jeg så skulle svarer på dit indlæg havde jeg det liggende i baghovedet, lavede en hurtigt google søgning, hvor det første link bekræftede det, og så var jeg vist lidt for hurtigt til at antage at det var korrekt. Det var for sjusket af mig, beklager. Men dejligt at se kode arguementation :D
Når det så er sagt, så er passer det jo ganske godt til argumentationen med at det nok er et helt bevist design valg, en feature der totalt er fjernet, da de formentligt har vurderet at den forudsager mange fejl, i forhold til hvor lidt nytte den giver. Umiddelbart vil jeg nok være tilbøjelig til at være enig i dette.
Jeg er ikke nogen stor C ekspert, men har dog kode lidt i C, så med farer for at udtale mig forkert vil jeg alligevel kommentere dit C eksempel. Er C ikke også, i modsætning til C++, rent "Pass by value". Som jeg ser dit eksempel, så udnytter du bare at du kan give pointers som parametre. Pointeren a i din swap funktion peget rigtigt nok på den samme int som du parser ind, men selve pointeren bliver kopieret. Altså meget lig at give en reference til et Object (eller Array :D) med som parameter til en java funktion.
Autoboxing
Du siger du er uenig og jeg gjorde det nok ikke tydeligt nok hvad jeg mente - fordi jeg interesserer mig ikke for hvordan det implementeres så længe det ikke kræver noget specialviden af mig - det skal være "transparent".
Det du beskriver med Scala er netop transparent, jeg skal ikke bryde hovedet med at tilføje integers til min List() med 'l.add( Integer.valueOf(2) );' for at undgå at lave 5000 unikke Integer-objekter alle indeholdende værdien 2.
Men det skal jeg i Java, endnu et komplet design-fail.
Her er vi vist meget enige. Problemstilling du kommer med der, viser også tydeligt at Java nok havde været bedre tjent uden autoboxing i det hele taget. Man kommer let til at skrive noget koder der opretter adskillige tusinde objecter, uden man er klar over det.
Generics, Type Erasure, Really?
Den svarer jeg lige på senere, vil lige læste artiklerne du henviser til før jeg svarer.
Annotations
Hvis mig venligst hvor annotations rent faktisk gør noget som helst - de er lavet så du selv kan skrive mere smart kode, som (evt. via reflection - a whole different can of worms - ) kan query hvor vidt dine felter, metoder eller klasser har nogle annotationer.
De eneste annotationer der reelt set gør noget er noget nær '@SuppressWarnings' og '@Override' - hvis DU skal gøre noget med dem skal du skrive reflection-kode eller gå i lag med AspectJ/Plastic eller lignende frameworks - hvilket fx Spring gør. Det er muligt at lave frameworks der tillader dig at skrive koncist, men det er forbeholdt dem som skriver større frameworks (igen, så som Swing, Hibernate etc)
Enig der er ikke imlementeret mange funktioner af disse i standard java. Men funktionaliteten er der trods alt, og bliver brugt i stor omfang af libraries og framworks. JavaEE, Spring, JPA, Weld.
Jeg erkender at jeg ikke kender meget til, hvad der skal til for at få noget til at ske compile time, eller pre-compile time, ved hjælp af annotaions, men jeg føler heller ikke rigtigt at jeg har haft behov for det, så problemet er i hvert fald for mig, ikke særlig stort, specielt ikke når der så er værktøjer til at gøre det, såfremt det skulle blive nødvendigt. APT er vel i øvrigt det officielle java værktøj til formålet.
Arv fra flere klasser VS Mixins
>>Ved ikke lige hvad du mener med sammensætning af funktionalitet.
>>I forhold til arv, så er multipel arv i c++ kilde til rigtig mange fejl, så tror det er et helt bevist design valg at denne feature ikke findes i Java.
<< Mht. multipel arv, det *er* et design-valg og multipel arv bliver også let noget rod. Du kan evt. slå "the diamond problem" up som er det klassiske eksempel på et problem som arv fra flere klasser medfører.
Mixins er well.. I det korte en måde at skrive 1 klasse med et par felter og nogle metoder hvorefter man så kan annotere en anden klasse som så "in essence" arver denne funktionalitet uden at vi snakker om "Typer" og indfører problemet om typebestemmelse fra diamantproblemet.
(Se evt: http://rubylearning.com/satishtalim/modules_mixins... for et hurtigt eksempel på mixins)
Du giver vel enlig selv svaret på hvorfor der ikke er multipel arv, bevist designvalg for at undgå problemer.
Kender godt til Mixins, vidste bare ikke at det var det du referede til. Scala traits som jeg nævnte er jo også et eksempel på dette, og jeg giver dig helt ret i at det er funktionalitet jeg savner i Java.
Anyway, jeg burde virkeligt ikke sidde her og skrive dette, der er sgu nok af eksamenslæsning der venter. Kværulanten i mig vandt dog i denne omgang. Anyway. Jeg vil prøve at holde mig væk men håber du (og andre) fik mere ud af mit rant om hvorfor Java har nogle seriøse skavanker.
Jeg takker for at du tog dig tiden.
Til en anden gang, kan du overveje at tilføje en forfærdig Serialization mekanisme, til din list. Den tilføjer i praksis lige pludselig en ekstra konstruktor, der specielt giver problemer for immutable klasser. Et pattern som serialization Proxy pattern burde ikke være nødvendigt, men ofte den den nemmeste måde at lave ordentlige Serializable klasser.
Go Scala or go Home!
Sidst men ikke mindst:
Scala er fint som hobby-projekt, men uden reel støtte, uden at Oracle simpelthen adopterede det og sagde "Scala's the way forward" så vil firmaerne fortsat satse på Java. Jeg kender løst til et Java konsulenthus og så vidt jeg kan forstå er deres bread-and-butter fortsat Java, de vil gerne hjælpe folk med Scala men efterspørgslen er der ikke. Hvis alle omkring dig sidder fast på Java og alle libraries skrives på Java (så du i allen faldt skal snakke flydende Java) så forsvinder charmen ved Scala ligesom.
2 ting her.
For det første, det jeg har prøvet at gøre til min pointe hele vejen igennem, er at Java jo trods problemer, ikke er noget dårligt sprog. Det kan efter min mening sagtens bruges fornuftig til specielt backend systemer.
Jeg er dog ikke enig i at Scala ikke vil vinde frem, fordi Oracle ikke står bag det. For det første er det jo ikke en enkelts mands hobby projekt, der bliver virkelig sat nogle ressourcer i det. Der ud over er det mit indtryk at det vinder indpas i flere og flere virksomheder. Har en kolega som har været til nogle scala arrengementer, og han har da berettet om representater fra flere store virksomheder.
Jeg synes heller ikke det er en ulempe at man helst skal kunne Java, for at kunne benytte Scala. Tvært i mod ser jeg det som en stor fordel for Scala, at det er kompatibelt med java, så man kan trække på rigtig mange af de gode framwork og libraries som der eksistere til Java, og som efter min mening er Javas allerstørste styrke. Jeg tror det gør det langt lettere for virksomheder der i forvejen benytter Java, at starte projekter i Scala, det kan ske via mange små skridt, i stedet for et stort. Det har i hvert fald været en fin glidende overgang hos os.
Det bliver ikke bedre at du selv skal hente og installere Scala separat (og antageligvis distribuere dette sammen med dine programmer?) etc etc.
Korrekt for desktop applikationer er det 8.5 mb ekstra der skal distribueres med. Men hvor stort et problem er det reelt med dagens hardisk størrelser og internet forbindelse, så længe det kan installeres og køres på samme måde som andre programmer? Ved installation via pakkehåndtering, vil problemet jo i øvrigt ikke være der, så det vil nok mest være windows og mac brugere der bliver ramt.
På backend siden, hvor udbredelsen for både Java og Scala er klart størst, ser jeg slet intet problem i dette.
Når det er sagt ville jeg blive *LYKKELIG* såfremt man aflivede Java og gjorde enten Scala eller Groovy til det nye sprog på platformen, men det kommer bare ikke til at ske.
Min præferencer for statisk typede sprog gør faktisk at jeg foretrækker Java frem for Groovy, men jeg indrømmer da gerne at Groovy har mange funktioner jeg gerne så i Java. Men ellers er jeg enig, Scala er vejen frem på, men det gør næppe at Java bliver aflivet.
En sjov detalje i den sammenhæng, er at James Strachan (skaberen af groovy) faktisk selv har peget på Scala som værende afløseren for Java på Java platformen:
http://macstrac.blogspot.dk/2009/04/scala-as-long-term-replacement-for.html