Is the writing on the wall for client side JVM?

155 views
Skip to first unread message

Rich Oliver

unread,
Apr 26, 2013, 10:20:58 AM4/26/13
to scala-...@googlegroups.com
The recent delay for Java 8 seems to have been almost completely unnoticed within the Scala community. It has been delayed in order to focus on security. The JVM is widely seen as a security nightmare. Could its days be numbered on the bulk of client side OSs. The JVM on the Server is going strong. So I wonder how much of the Scala community really cares about this? It seems that the bulk of commercial Scala is server side.

The very low priority that the Scala team put on GUI seems to confirm a lack of concern for client side Scala. I'm not saying this is wrong. The Scala team have limited resources. They must choose their priorities, but it would be nice to have a clearer statement of those priorities. If Scala is to have a long term client side future then it may need a different target. Mono, LLVM, full compilation are all possibilities but would all require large investments of resources.

No one would deny the client world is changing at a great pace. Scala has always had limits on the client side notably game consoles. Now we have phones and tablets with smart watches just coming on line. Is Microsoft's long dominance on the desktop finally beginning to crack. The desktop market is shrinking. Most people don't need a desktop / laptop for their personal life. The desktop user base will be much more dominated by business and developers. Could Linux finally get a real look in on the desktop. Maybe that's just wishful thinking, but if correct, given Linux's domination of the Server market, it could make a linux compile target more attractive or even a linux-LLVM target. Alternatively one could attack from the top so to speak by forking openjdk. I was shocked to find out recently that Facebook is built on LAMP. Surely we can do better? Of course Typesafe does to some extent already provide an alternative, but surely Scala could go much deeper down the stack.

Anyway I'm not claiming my statements are all 100% accurate. I wanted to put out some ideas for debate on the big picture in which Scala will be living.

Rex Kerr

unread,
Apr 26, 2013, 10:45:02 AM4/26/13
to Rich Oliver, scala-debate
On Fri, Apr 26, 2013 at 10:20 AM, Rich Oliver <rzi...@gmail.com> wrote:
The recent delay for Java 8 seems to have been almost completely unnoticed within the Scala community.

That's because we don't need Java 8 for anything.  Some features might give a performance advantage, but until basically everyone is using 8, Scala can't assume they're present.
 
It has been delayed in order to focus on security. The JVM is widely seen as a security nightmare. Could its days be numbered on the bulk of client side OSs.

Er, it's days are already over on the bulk of client side OSes, because Windows is the bulk, and it doesn't install the JVM by default.
 
The JVM on the Server is going strong. So I wonder how much of the Scala community really cares about this? It seems that the bulk of commercial Scala is server side.

Security problems are a issue for servers too.  Maybe even a bigger issue, since if you get server access you generally have a lot more exploitable data available.  (Not so useful if you just want a botnet, though.)  I'm not sure why you think the security issues are client/desktop-specific.
 

The very low priority that the Scala team put on GUI seems to confirm a lack of concern for client side Scala. I'm not saying this is wrong. The Scala team have limited resources. They must choose their priorities, but it would be nice to have a clearer statement of those priorities.

Can't argue with that.
 
If Scala is to have a long term client side future then it may need a different target. Mono, LLVM, full compilation are all possibilities but would all require large investments of resources.

I don't think this is realistic.  Dalvik and Avian already seem to be beyond the reach of substantial efforts, and this is despite them opening up the entire mobile/smartphone market.  Instead, people rely upon the standard bytecode transformation toolchain to use Dalvik, and on Avian to not require anything different.
 

No one would deny the client world is changing at a great pace. Scala has always had limits on the client side notably game consoles. Now we have phones and tablets with smart watches just coming on line. Is Microsoft's long dominance on the desktop finally beginning to crack. The desktop market is shrinking. Most people don't need a desktop / laptop for their personal life.

People aren't buying a desktop/laptop becaues they don't need one, they're not buying one because they've already got one.  It's the same problem that car manufacturers have: a five year old car works just fine.  How, then, do you get people to upgrade?  Selling unreliable hardware doesn't really cut it, because people learn to avoid junk after a while.
 
The desktop user base will be much more dominated by business and developers. Could Linux finally get a real look in on the desktop. Maybe that's just wishful thinking, but if correct, given Linux's domination of the Server market, it could make a linux compile target more attractive or even a linux-LLVM target.

Why bother?  JavaFX is open source and works fine on Linux.  (Could work better, I suppose.)
 
Alternatively one could attack from the top so to speak by forking openjdk.

Ouch, why?!  That requires an enormous bundle of work just to stay compatible with mainstream Java.

Code reuse goes for not duplicating effort in libraries/compilers/operating systems/etc. also.  I think not seriously working on mobile platforms is a long-term strategic mistake, but bailing on the giant ecosystem built around the JVM seems precisely the wrong direction to go in.

Now, if you could _not care_ (except for performance) whether you were using the JVM and calling libraries there or calling C libraries, that would be awesome.  But it would also be impossible, I think: the models for what you are responsible for are just too different.

  --Rex
 
Reply all
Reply to author
Forward
0 new messages