Integration so that you can easily integrate new Smalltalk code (in this case) with existing JVM code that your organisation/product might have.

Ecosystem because you don't need to kickstart a massive community of developers, open source libraries, a standard library, and so on, to have a useful language. Basically, by making a language that targets an existing platform (such as the JVM, CLR or JavaScript), you're "batteries included" from the very start. Better yet, the batteries will be familiar to shares of developers. This is major. Ever wondered why Lisp was only used by a couple of men with beards (and pg) until Clojure? I can promise you, it wasn't the square brackets.

Exit strategy because you want to be able to get out as easily as you got in. If you build non-hobby software with Redline Smalltalk, and for whatever reason the whole thing blows up in your face (e.g. big performance or security problems, project ends up unmaintained with large nuisances, and so on), you can migrate code to another JVM language bit by bit.

Unless your language's main features coincide with the very specific pain points poorly addressed by the JVM (like struct arrays or mobile-phone deployment), I'll say that the JVM is the default target choice. It is any other choice that will need to be justified.

For the JVM there are choices. IBM, Azul, Oracle, OpenJDK and many other more academic ones. With different tradeoffs and costs. I have switched massive code bases from one to the other with minimal effort.

Switching C compiler is more invasive than switching JVM providers. And many other languages only have a single sanctioned runtime.

Sure the JVM eco system is far from perfect. But it is dependable!

I lost hours trying to set up Maven to download one library and build my project. All the documentation pages seemed to point to other documentation pages. I ended up trying to download about 30 jars manually, but the versions seemed to clash. I am convinced that the best thing a programming language can to do improve adoption is not to create a JVM version, but to create a package management system like pip/npm/NuGet.

With Python, in the past things were a little trickier with easy install, but these days the library's web page would probably have told me to type:

    pip install third_party_library

Aside from developing on Windows with C extension libraries, those are increasingly rare. Pip + virtualenv works wonders, and the latter has been folded into the most recent official release of CPython (3.3), so it's now officially the right way to do Python package management, as opposed to simply the de facto approach.

As someone who's had to use both, I will say that my experience with even the most basic, functionality in Java's package management is a nightmare, whereas learning how to use the same basic functionality in pip/virtualenv was so easy, I wondered why I'd been putting it off so long.

It doesn't have to be:

http://xkcd.com/353/

You should check out Apache Buildr (http://buildr.apache.org/). It gives you the power of Maven repos with a Ruby "front end". And, yes, I know it's imperative and not declarative but I find that the build files tend to be small and understandable.

But I found JarFinder in IntelliJ to be a good replacement for many needs. You just start using a class and it suggests a couple of jar's to download and reference. :)

Well actually all of those you mentioned are awful compared to Maven ;-)

   "The JVM is a big black box and I think its veryhard to see whats happening inside."

   "have someone tried to write a patch for the JVM? no? then try!"

I'm not saying the JVM is perfect but I'm inclined to think that if the JVM is causing you problems, you already had them in your architecture.