Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

### Topics

InfoQ Homepage News JetBrains introduces the new JVM language Kotlin

# JetBrains introduces the new JVM language Kotlin

This item in japanese

So far, Kotlin has been primarily known as a Russian island thirty kilometers west of Saint Petersburg. More recently, the Czech company JetBrains introduced a new programming language named Kotlin running on the JVM (Java Virtual Machine). It is the intent of the language developers to get rid of some challenges in the Java language.

JetBrains’ product portfolio mainly consists of IDE for Java, PHP, Objective-C, Ruby and  MPS. With the Project Kotlin they are now entering unchartered space.

The language developers emphasize, that the main design goals behind their project are:

According to JetBrains, the new language is statically typed, object-oriented,  targets the JVM, is built for industrial use, and gets rid of problems and challenges in Java that are due to backward compatibility.

For instance, the type system takes control of Null references so that Kotlin does not need Null Pointer Exceptions. There are no raw types in Kotlin, arrays are invariant, and generics are type-safe even at runtime. In addition, the language supports clojures that can be optimized using inlining. And it doesn’t support checked exceptions, which many language designers consider a bad feature, anyway. An essential aspect is the interoperability between Kotlin and Java: Kotlin can call Java, and Java can call Kotlin.

The following code snippet illustrates a simple object-oriented “Hello World” implemented in Kotlin. Further examples are available by JetBrains.

class Greeter(name : String) {
fun greet() {
println("Hello, \${name}");
}
}

fun main(args : Array<String>) {
Greeter(args[0]).greet()
}

There are a couple of other languages that consider themselves reasonable alternatives to Java. In particular, Scala, Fantom, Groovy, Gosu, and Ceylon are natural competitors with Scala and Groovy having achieved the most distribution.

At the moment, there is lot of - sometimes heated - debate in different discussion groups how Kotlin compares to other languages such as in the Fantom website or in the Scala user group.

It remains to be seen how many software developers will consider Kotlin as their language of choice. At least, the reactions of many developers prove that Kotlin has at least entered the race for the next new cool language.

A public Beta will be available at the end of 2011. Reportedly, there will be an open source compiler and IntelliJ IDEA plug-in under the Apache 2 license. While the compiler will initially emit Java byte-code, there might also be a Kotlin version emitting JavaScript.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

• ##### Yet another one?

by Veggen Skrikk,

• ##### What the article is missing

by Dimitrov Dimitar,

• ##### Strengthening Java's grip

by Ingo Boegemann,

• ##### Re: Strengthening Java's grip

by Richard Clayton,

• ##### Re: Strengthening Java's grip

by Dan Tines,

• ##### Re: Strengthening Java's grip

by Luis Espinal,

• ##### Re: Strengthening Java's grip

by Dan Tines,

• ##### Re: Strengthening Java's grip

by Richard Clayton,

• ##### Re: Strengthening Java's grip

by Luis Espinal,

• ##### Re: Strengthening Java's grip

by Dan Tines,

• ##### Re: Strengthening Java's grip

by Luis Espinal,

• ##### Re: Strengthening Java's grip

by Dan Tines,

• ##### Re: Strengthening Java's grip

by Luis Espinal,

• ##### Right direction

by Hermann Schmidt,

• ##### Re: Right direction

by Richard Clayton,

• ##### Re: Right direction

by Hermann Schmidt,

• ##### Time to market?

by Javier Diaz,

• ##### Performance

by Marc Stock,

• ##### Functional Languages and the Enterprise

by Faisal Waris,

• ##### Don't forget ReSharper

by Florian Fanderl,

• ##### Closures, not Clojures

Your message is awaiting moderation. Thank you for participating in the discussion.

I think you mean Kotlin supports Closures, not Clojures.

• ##### Yet another one?

Your message is awaiting moderation. Thank you for participating in the discussion.

Wow, another language... just what we needed... yeeey...

• ##### What the article is missing

Your message is awaiting moderation. Thank you for participating in the discussion.

The distinguishing features of Kotlin are:

• - deep inferencing and flow analysis - for example checking instanceof or null changes the type of a variable in the subflow, so you don't need to cast.
• - low-overhead type system - rely on static analysis as much as possible, rather than runtime wrappers. This is a big one and I haven't seen any of the JVM languages go in that direction.
• - explicit syntax - they've tried to stay away from 'magical' features like MOP or implicit conversions. This makes the language more verbose, but potentially easier to read and maintain large bodies of code.

• ##### Strengthening Java's grip

Your message is awaiting moderation. Thank you for participating in the discussion.

Kotlin and Ceylon are not really bringing anything new to the table. For me they just try to copy the success Scala had recently.
Competetion is good in principal - but I fear these might just end up diluting the progress Scala made and as such delaying the point in time when we get an enterprise accepted multi purpose successor to Java.
Having several simmilar languages attempting to fill the same space only strenghtens the grip Java has in the multi purpose space.

• ##### Re: Strengthening Java's grip

Your message is awaiting moderation. Thank you for participating in the discussion.

I think these languages (Kotlin and Ceylon) are designed to be less jarring for a traditional Java developer to learn than Scala. In my opinion, I think it's great that there are a bunch of these languages popping up. The platform is the JVM; as long as these languages remain compatible with each other, it shouldn't matter what you write in.

• ##### Re: Strengthening Java's grip

by Dan Tines,

Your message is awaiting moderation. Thank you for participating in the discussion.

Kotlin and Ceylon are not really bringing anything new to the table. For me they just try to copy the success Scala had recently.
Competetion is good in principal - but I fear these might just end up diluting the progress Scala made and as such delaying the point in time when we get an enterprise accepted multi purpose successor to Java.
Having several simmilar languages attempting to fill the same space only strenghtens the grip Java has in the multi purpose space.

Your premise seems to be that Scala is/should be the enterprise, mainstream successor to Java. That's just not going to happen...ever. And it doesn't matter what the technical merits of Scala are. All that matters is the perception of Scala. There's a thing called time to market, and Scala didn't make it.

• ##### Re: Strengthening Java's grip

by Dan Tines,

Your message is awaiting moderation. Thank you for participating in the discussion.

I think these languages (Kotlin and Ceylon) are designed to be less jarring for a traditional Java developer to learn than Scala. In my opinion, I think it's great that there are a bunch of these languages popping up. The platform is the JVM; as long as these languages remain compatible with each other, it shouldn't matter what you write in.

But it does matter what the canonical JVM language is because management doesn't look at it as "go ahead and code any old JVM language your heart desires"

• ##### Re: Strengthening Java's grip

by Luis Espinal,

Your message is awaiting moderation. Thank you for participating in the discussion.

Kotlin and Ceylon are not really bringing anything new to the table. For me they just try to copy the success Scala had recently.

So, how did Kotlin copied Scala when it comes to nullable types, the "safe call", elvis, npe and predicate operators? As for nullable types, I hope you don't tell me they were copied from Scala's Option types.

Competetion is good in principal

It always is. That's how the state of the art of programming language design and compilers move forward.

but I fear these might just end up diluting the progress Scala made

Non sense. Scala has made a lot of progress, but at the same time, Groovy has been taking a lot of impetus, specially with Groovy++ and the new additions for dynamic language invocations in Java 7. I favor Scala more than Groovy, but at the end of the day, Scala (or any language for that matter) should "make" it on his own merits, independently of the size of its competition.

Besides, unless you give me a detailed, objective analysis of why Kotlin (or any other contender) would not be an adequate alternative over Java and Scala, this is just favoritist hand waving.

and as such delaying the point in time when we get an enterprise accepted multi purpose successor to Java.

Also nonsense. An enterprise accepted multi purpose successor for Java will come. It does not necessarily have to be the one we currently like the most, nor it is a popularity contest, nor does it have to occur within our liked time tables.

Having several simmilar languages attempting to fill the same space only strenghtens the grip Java has in the multi purpose space.

And this is bad because????? Our goal should not merely be to replace Java for the sake of it, but to deliver value to those who write our paychecks for the job we do. Java atrocious verbosity aside, it is a good language to get the job done, and rightly so has a grip on things. If things make more sense to be written in Scala, or Groovy or whatever, then you pick the language you need (or build your case for it).

One thing about Scala is that it is markedly different from Java syntax. Groovy, Ceylon and Kotlin OTH, have closer syntax to Java while at the same time providing a lot of the functionality that Scala provides...

... and some of them provide functionality out-of-the-box that Scala does not have. It is a wonderful language. But it is not perfect. Not one is.

And if one or more languages provide a fraction of what Scala provides while leveraging Java syntax, then that is also a very good feature, one with almost a clear ROI. At the end of the day, what we Java developers want is three things:

1. Ability to write internal DSLs
2. Closures
3. Non-checked exceptions
4. Auto typing and less verbose, more succinct syntax

If I can get these four with a syntax closer to Java, that's what I'd take.

Stop worrying about it, waving your hands about the prospect of having multiple languages competing against Scala. Scala does not have to be the winner. Programmers are the ones that should be the winners, and they will so long as they get the four capabilities I just mentioned.

• ##### Right direction

Your message is awaiting moderation. Thank you for participating in the discussion.

The Kotlin page says it is a language for industrial use. Industrial use to me means simplicity and safety. It is not about having 5 choices to solve one problem or including the latest language constructs for parallel programming, or having two programming paradigms combined in one language. In large companies, developers need to get up and running quickly, very often with legacy code or with little experience. The frameworks already present a steep learning curve, the language itself therefore should offer a safe and quick entry.

In Java, the combination of inheritance and generics already is too much for most developers. There is not much room left for even more sophisticated language constructs. They would do more harm than actually solve problems.

Java is a good language. There is nothing wrong with it in principal. It is too verbose in a few places, and the string, date, IO libs are terrible (i use apache utils and don't bother anymore :-) With closures (and properties instead of set/get, please), it will be ready for the next 15 years. Closures can massively improve the libraries, which, at the end of the day, contribute more to the productivity than the actual language.

Yet another one? Yes, please! Until none of the Java contenders exactly hit the pain points of the average Java developer, they won't have wide acceptance. Theoretical arguments get no traction, a Java developer must say "someone finally fixed this!" to be convinced.

• ##### Re: Strengthening Java's grip

by Luis Espinal,

Your message is awaiting moderation. Thank you for participating in the discussion.

But it does matter what the canonical JVM language is because management doesn't look at it as "go ahead and code any old JVM language your heart desires"

Depends of the type of management you worked for. And I'm not referring to the bleeding-edge type of startup, but also in what we typically consider as "traditional" financial institutions. I know of quite a few good old brick-n-mortar banks, shops and time-sharing corporations that are aggressively pursuing Groovy in lieu of Java for example (at least in South Florida). I also know that the same has been happening for quite some time in Cali.

Management is not the same from company to company, not even among what we'd think as "traditional-thinking" institutions. If we see a company like JP Morgan building a super computer as a cluster of FPGAs for risk analysis (or similar companies jumping into Erlang or Haskell), it is not (or should not be) surprising that companies embrace "new" technology (with the caveat that a lot of it isn't even new.)

At some point before 1994-1995, the canonical way to build apps was with modal windows or client-server approaches using VB, VFP, Clipper or PowerBuilder. Then new-blood and traditional companies made the shift to Java in a relatively short time (and to a lesser extend to C# and .NET).

It will be the same when a sector (be it small or significant) adopts a new canonical platform. So please, don't use "management" as a blanket statement. It is not like that.

• ##### Re: Strengthening Java's grip

by Dan Tines,

Your message is awaiting moderation. Thank you for participating in the discussion.

So please, don't use "management" as a blanket statement. It is not like that.

I was referring to the below quote:

The platform is the JVM; as long as these languages remain compatible with each other, it shouldn't matter what you write in.

Specifically, the vast majority of organizations are going to settle on one language for most work - Java in the case of the JVM. Much less likely is for a company to settle on some alternative language such as Scala. And even a less likely scenario is some polyglot shop where you have a multitude of JVM languages.

But the reason for that is simple. Risk needs to be minimized. So for the most part, shops are going to choose Java (the language), because even though there might be a reward for using Scala, they're not willing to take that risk.

• ##### Time to market?

by Javier Diaz,

Your message is awaiting moderation. Thank you for participating in the discussion.

There's a thing called time to market, and Scala didn't make it. <= Scala is not in a marketing competition.

What about Nice? It had *all* those features these "simpler" languages claim now but years ago, yet nobody seemed to care. Everybody seems now crazy to do Java++, when finally, java is going to do it itself (after 5 years ...).
And no, there is not going to be another Java soon: no new "word" you can put in your CV that will give you a job, sorry!

• ##### Performance

by Marc Stock,

Your message is awaiting moderation. Thank you for participating in the discussion.

Any word on what the performance of this language is compared to Java? (I realize it's not done yet but I'd be interested to hear the preliminary numbers.)

• ##### Functional Languages and the Enterprise

by Faisal Waris,

Your message is awaiting moderation. Thank you for participating in the discussion.

First off I must say that already having an IDE gives Kotlin a headstart.

However, I can safely say that Java will remain established for a long time in the enterprise for traditional, transactional business system.

However for complex, algorithmic processing (which any enterprise has its share of) I can see other languages taking hold.

Surprisingly, I have been allowed to write a paper on functional languages (Scala, F#, Clojure) from an enterprise perspective so its not a foregone conclusion that other JVM languages or functional languages will never take hold in the enterprise.

My personal opinion is that as Java develpers start to see the power languages like Scala and F# they (the smart ones) will start to see the light.

Of course, after Java 8, millions of Java developers will think Java invented lambdas and effuse that no end.

• ##### Re: Strengthening Java's grip

Your message is awaiting moderation. Thank you for participating in the discussion.

Dan,

I agree with Luis; I think the choice of language is highly dependent upon management's philosophy. Our company, Berico Technologies, does a lot of integration and polyglot architectures are the norm (typically a mix of .NET and JVM-based languages). Some languages are more appropriate for certain types of tasks. If those tasks can be abstracted into a library, there shouldn't that much of an adoption problem. I should mention that this is actually very common in organizations (consider the use of both JNI and Interop on .NET).

Rich

• ##### Re: Right direction

Your message is awaiting moderation. Thank you for participating in the discussion.

In Java, the combination of inheritance and generics already is too much for most developers. There is not much room left for even more sophisticated language constructs. They would do more harm than actually solve problems.

I really hate this notion that language features like inheritance and generics are too difficult for developers. "Too difficult" ends up being the justification for the creation of poor code. Any organization that adopts this philosophy is bound to fail because they've chosen to lower their coding standards than raise their expectations of professional developers.

• ##### Re: Strengthening Java's grip

by Luis Espinal,

Your message is awaiting moderation. Thank you for participating in the discussion.

Specifically, the vast majority of organizations are going to settle on one language for most work - Java in the case of the JVM.

That makes absolutely no sense. Almost every enterprise that does web development works with multiple languages. There is no 100% pure Java work at all, as the majority involves a combination of Java and JavaScript (not counting all the other things that run into the background, shell and perl scripts, database store procedures, rsync scripts and the like). The idea that the majority of organizations settle with one language is just that, a myth.

Much less likely is for a company to settle on some alternative language such as Scala.

Depends on the company, which is what I told you before. You keep making generalizations about companies and management, why? If that was the case, no company would have ever embraced Java back in 95 (oh noes, a new language!)... and yet, here we are, aren't we?

And even a less likely scenario is some polyglot shop where you have a multitude of JVM languages.

But that's been going on for years now. Welcome to the not-so-current state of affairs. I don't know where you work or what kind of industry you are, but seriously, haven't you been paying attention to the job postings for the last 3-4 years for Groovy, JRuby and Jython jobs?

But the reason for that is simple. Risk needs to be minimized.

Hand waving combined with a poor understanding of risk management. Risk minimization is not a blanket statement, and there is always a risk associated to staying with the same technology. There is a reason we are not writing in COBOL and FORTRAN anymore (at least mostly).

So for the most part, shops are going to choose Java (the language)

Which shops, which companies? If you mean the majority, can you back that up with actual, hard data?

because even though there might be a reward for using Scala, they're not willing to take that risk.

Again, which companies, which industries, which shops? Just as there are companies that maintain the same technology for some projects, they also introduce new technologies for other projects, in particular pilot projects. That's how people have gone from one stack to another (EJB 1/2, to Spring to EJB3 and so on...) and from one version to another, that's how they have moved into Ant at the very beginning and then into Maven if they feel that's advantageous.

One good example: Java shops that do TDD and BDD tend to use Groovy, JRuby and lately Scala for their unit tests. It is that much simpler. That's how companies asses risk (since you talk about risk minimization), develop expertise, and when they do an actual risk assessment (not hand waving as you do) they make the engineering decision to use any such language in lieu of Java (or not.)

Even Oracle in their ADF platforms and JDeveloper environment have full support for Groovy. I know for a fact of banks, financial institutions that have been steadily moving out of Java and into other languages for several years now. I can drop a few names if necessary.

Again, I don't know where you are or what you work on, but you seem to have been completely oblivious to what has been going on in the Java/JVM landscape for several years now. Seriously.

• ##### Re: Strengthening Java's grip

by Dan Tines,

Your message is awaiting moderation. Thank you for participating in the discussion.

That makes absolutely no sense. Almost every enterprise that does web development works with multiple languages. There is no 100% pure Java work at all, as the majority involves a combination of Java and JavaScript (not counting all the other things that run into the background, shell and perl scripts, database store procedures, rsync scripts and the like). The idea that the majority of organizations settle with one language is just that, a myth.

Except you forgot to read what I said carefully. I said for the JVM , not the browser, not the database.

Depends on the company, which is what I told you before. You keep making generalizations about companies and management, why? If that was the case, no company would have ever embraced Java back in 95 (oh noes, a new language!)... and yet, here we are, aren't we?

Yes, I'm making a generalization, which I already stated. But your logic about embracing Java back in '95 makes no sense. You're confused about going from C++ to Java back in the mid 90s, to Java to say Scala, or Kotlin, or whatever.

don't know where you work or what kind of industry you are, but seriously, haven't you been paying attention to the job postings for the last 3-4 years for Groovy, JRuby and Jython jobs?

Now you're handwaving. Those jobs are a blip on the radar screen compared to Java. You keep on missing the point, but more on that later.

Hand waving combined with a poor understanding of risk management. Risk minimization is not a blanket statement, and there is always a risk associated to staying with the same technology. There is a reason we are not writing in COBOL and FORTRAN anymore (at least mostly).

Again, you're trying to make a comparison of COBOL to Java. We're talking about the JVM as the platform, and languages on the JVM....not Javascript, not COBOL, not Fortran...

Which shops, which companies? If you mean the majority, can you back that up with actual, hard data?

Seriously? I really have to back up with "hard data" that most Java shops are writing their code in Java and not Scala? I don't know what planet you're living on.

Again, I don't know where you are or what you work on, but you seem to have been completely oblivious to what has been going on in the Java/JVM landscape for several years now. Seriously.

You seem to be completely oblivious to the real world, and relying on the blogosphere way too much for your information.

• ##### Re: Right direction

Your message is awaiting moderation. Thank you for participating in the discussion.

That is my observation. I have seen too much nonsensical generics code. I don't advocate lowering the developer standards. In terms of safety in industrial environments, I consider simplicity (or call it lower confusion potential) as a risk attenuator. Developers should focus primarily on stability, scalability, robustness, decoupling, readability, etc. Those things count in large applications and require plenty of skills, so don't worry, there is enough to ask for from developers.

• ##### Don't forget ReSharper

Your message is awaiting moderation. Thank you for participating in the discussion.

JetBrains is also active in the .NET community. I think ReSharper is also a very successfull tool they have in their portfolio :)

• ##### Re: Strengthening Java's grip

by Luis Espinal,

Your message is awaiting moderation. Thank you for participating in the discussion.

Except you forgot to read what I said carefully. I said for the JVM , not the browser, not the database.

I do know that you said for the JVM, but even with that restriction, the argument for monolingual development still applies. Combining more than one JVM language is just an extension to what has been the de-facto practice for ages. Just take a look at anyone doing TDD/BDD. Most people (at least the people I know at multiple companies) have been doing their unit tests and TDD/BDD work with Groovy for a while now.

Similarly since Spring 2.5 came out, one of the first things done was to implement glue code (integration beans, JMX beans, AOP interceptors) with Groovy within the XML configuration. Which is extremely useful for minimizing namespace polution (and super-good for prototyping). Obviously it can be open to abuse, but that is true with almost everything.

Anyways, going back even further back in time, we have been using JSTL EL/UEL for what, 6 years now. That runs/gets interpreted in the JVM, and although it is interpreted directly from a Java variable context (or "world"), it has distinct syntax and semantics (ergo, qualifying it as a distinct language on its own... that runs on the JVM before getting its output sent to the client.

Yes, I'm making a generalization, which I already stated. But your logic about embracing Java back in '95 makes no sense. You're confused about going from C++ to Java back in the mid 90s, to Java to say Scala, or Kotlin, or whatever.

Uh, people weren't just moving from C++ to Java back in the 90's. They were moving from DBase, Clipper, FoxPro, VB and a plethora of BASIC implementations, PowerBuilder, FORTRAN, RPG and COBOL, MFC and Borland's OWL, Turbo Pascal, Delphi, and a lot of other strange beasts no one remember anymore.

So, what is the difference between then (moving not just from that language bestiary to Java, but from one distribution paradigm to another) to now (moving to new languages that 1) run on the same platform, and 2) are designed with the Java language spec as the main reference for the technology they need to interoperate with)????

One could make the argument that the transition or the ability to interoperate is even easier now than back in the 90s.

Now you're handwaving. Those jobs are a blip on the radar screen compared to Java. You keep on missing the point, but more on that later.

It is not a question of whether they are substantial or not compared to the number of Java positions. It is a question of whether that is a new trend (it is not), and whether both a) the number of such jobs and b) the rate at which this growth occurs are increasing (they are.)

Again, you're trying to make a comparison of COBOL to Java. We're talking about the JVM as the platform, and languages on the JVM....not Javascript, not COBOL, not Fortran...

Well, that exactly the point. You claim that companies don't or won't move out of Java because of "risk management". But that factor has always been taken into consideration and that has never stopped companies, whole industries, from moving forwards.

Companies have always been able to move from one platform to the next (or to integrate older platforms with new ones.) And that type of move always involved not just on programming languages, but platforms, runtimes and hardware. Companies willing to take that risk were able to do so and reap the benefits.

And all of the sudden in the late 2000's, there won't be companies willing to do a less risky move that doesn't involve changes in platform or hardware (which pretty much that's what it is to move or integrate between JVM languages)????

You claim that it won't happen. I claim that it will.

I'm not claiming that it will be easy, or that there will be a floodgate of change, or that there won't be failures. But it will happen. It is happening, and it's been happening for the last 5-6 years (which is an eternity in this business.)

And I'm not claiming that it will happen in some sort of fanboyish, messianic kind of thing. I'm claiming so based on historical evidence and current trends.

Seriously? I really have to back up with "hard data" that most Java shops are writing their code in Java and not Scala?

Strawman. I'm not claiming that most Java are not writing Java, but Scala (quote me where I did that). Your are claiming that the majority will not (a distinct argument, one which I'm asking for some sort of evidence, which is not unreasonable.)

I'm not claiming for a second that Java will disappear (just in case another strawman comes this way).

The claim I made, based on direct work experience and collaboration and observation of what others do in other companies for the last 5 years, is that companies will at the very least be integrating their Java code base with other JVM languages (integration/glue code, testing and configuration), and with some (if not a lot of) new development being done with something else.

I don't know what planet you're living on.

Not in the same based on the differences between our first-hand impressions of the job market and past work experiences.

You seem to be completely oblivious to the real world, and relying on the blogosphere way too much for your information.

If by blogosphere you mean direct, paid work experience, and reliable evidence from ex-colleagues doing the same in other companies for a living, then I guess you are right. Talk to me about your real world in 3-4 years. I'll talk to you about mine starting from 5 years ago.

Things change man, they always do. Not necessarily always for the better, and not necessarily at the rate we think at this moment, but they do. They always do The idea that companies don't ever take technology risks, that's not true. Some, not all, might be slower than others, but they always do.

There are companies that are completely ossified (think the ones that still mandate to use IE 5 and JDK 1.3... there are those still around.) But are they really relevant to this discussion. Are they the ones that dictate the final pace at which technology gets adopted or replaced? Do they even make a good case with respect to risk management.

Most companies that do some sort of risk management do take baby steps. They don't go YAH!!! Scala!! or whatever, on their production systems, but take pilot projects using whatever technology they'd like to explore. Small risk, high yield. Experience gets build, yes we go for it, or no we don't. Yes? Ramp up the usage? No? Re-evaluate something else. Rinse and repeat.

And this is what goes at the core of your original argument (quoted below, bold by me):

But it does matter what the canonical JVM language is because management doesn't look at it as "go ahead and code any old JVM language your heart desires"

Neither is management a monolithic thing that you can generalize things about (first in bold), nor does it look at it they way your counter-argument points out (second in bold).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p