Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <4704B818.5020909@cheiron.org>
References: <E9192052-6EC2-4C9E-A8AA-29F0E5668262@artima.com>
 <470149EA.90604@dcrdev.demon.co.uk>
 <47404DAF-9DB6-472A-8990-9321A0CCD62F@artima.com>
 <47032BE4.7040004@cheiron.org> <4704B818.5020909@cheiron.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <72AC2506-04CD-4FEE-B4CE-FCCA257862AA@artima.com>
Content-Transfer-Encoding: 7bit
From: Bill Venners <bv-svp@artima.com>
Subject: Re: Concurrency and River
Date: Thu, 4 Oct 2007 09:21:27 -0700
To: river-dev@incubator.apache.org

Hi Mark,

On Oct 4, 2007, at 2:53 AM, Mark Brouwer wrote:

> Hi Bill,
>
> Your posting related to your intentions with SuiteRunner and
> Jini/JavaSpaces made me think a bit more about the relation between  
> Java
> and Scala, so I have some additional questions.
>
> Mark Brouwer wrote:
>
>> Also Scala is lacking a strong security model which, if you take code
>> mobility into account, seems to be a necessity.
>
> I think I talked BS here, and I need some help to really try to
> understand the relation between Scala en Java the Platform and verify
> whether I made an incorrect statement.
>
> The reason why I said Scala is lacking a strong security model was
> because when I first read about Scala the language (over a year ago) I
> read about Scala for the JVM and .Net and that Scala the language  
> could
> easily integrate with Java en C#.
>
> So for me Scala represented:
>
>   the language
>   the class libraries written in Scala (packages scala.)
>   the VM (either .Net or JVM)
>
> At that time I found no notion of a security model in the  
> documentation
> or the API. But now that I looked better I even can't find a String
> class or IO libraries etc. in the class libraries. When looking at  
> some
> examples and reading some documentation I noticed that a string  
> resolves
> to java.lang.String and that the Java libraries are almost used for
> everything low level (networking, IO, etc.).
>
java.lang is imported automatically in any Scala source file, as in  
Java. So when you say String you get java.lang.String.

> Am I correct that Scala the environment actually represents:
>
>   the language
>   the class libraries written in Scala
>   the class libraries as specified for the Java Platform
>   the JVM (I can't find a reference for .net anymore on
>            http://www.scala-lang.org/)
>
> Or in other words is a requirement for Scala that Java the class
> libraries is available. If that is the case it seems Scala inherits  
> the
> Java security model by default and I would qualify it to be on par,  
> i.e.
> having a strong security model. Although I don't know whether in that
> case 'Scala the class libraries' also call into
> SecurityManager/AccessController to protect certain operations.
>
Scala is compiled to Java bytecodes. I don't know of anything it  
offers in its libraries that would need to call the access  
controller. Scala is a thin layer on top of the Java API. The main  
libraries you use instead of Java libraries are Scala's collections.  
But to read from a file you use java.io.FileReader or what not. To  
read from a socket you'd use java.net.Socket, etc.

> If the above assumption is true and the integration of Scala and  
> Java is
> seamless then one could argue that everything that is available to  
> Java
> is available to Scala. Wouldn't that mean that there are a huge number
> of web frameworks, unit test frameworks and also distributed
> technologies available to Scala. Or is it the case that while they are
> available there is some idiom mismatch when being used in Scale and  
> that
> for that reason you want to have a pure Scala SuiteRunner, one that  
> will
> rely though on a lot of calls into the Java class libraries.
>
That's correct. Scala is binary compatible with the Java API and JVMs  
and any Java library or framework out there. The only thing it isn't  
compatible with is tools that work directly with Java soruce code.  
What Scala is not compatible with is that Scala code isn't valid Java  
code.

There is also a version of Scala that compiles to .NET, but the LAMP  
team stopped supporting it many versions ago. It is open source, so  
its future depends on someone picking it up and continuing it. But  
Martin Odersky and his team is focused on the JVM.

> The reason why I also ask is that e.g. Seven is a great development  
> and
> deployment Platform for Jini services that solves a great bunch of
> things that are quite hard to arrange yourself (code mobility and
> configuration only a few of them) and if there could be Scala  
> version of
> the JSC API that runs on top of the Java version I think the Scala
> environment would have a another nice distributed computing platform
> which could cooperate between any other Jini service, either  
> implemented
> in pure Java or a mixture of Scala and Java.
>
> I can even imagine that there can be layers over the current net.jini
> utilities as part of the River project that would bring them into the
> Scala idiom.

Yes, I call that "scalifying" your API. That's sort of what I'm doing  
with SuiteRunner. In the old Java SuiteRunner, to test whether a  
method throws an exeception, you write:

try {
     someMethod("hi", null, "there");
     fail();
}
catch (NullPointerException e) {
     // expected
}

In Scala you can wrap such boilerplate code in a method and pass in a  
closure. So with the new SuiteRunner you can just write:

expectNPE {
   someMethod("hi", null, "there")
}

This makes the API easier to read and use. Another example is  
java.math.BigInteger. Scala does define a scala.BigInt class that  
"scalifies" BigInteger. To use BigInteger, you would write:

x.multiply(factorial(x.subtract(BigInteger.ONE)))

whereas with Scala's BigInt you can write:

x * factorial(x - 1)

Since SuiteRunner didn't get much adoption in the past, instead of  
just Scalafying it, which means I'd wrap the Java API with a Scala  
layer, I decided to go ahead and just transform it to Scala  
completely. People who were using the old Java SuiteRunner can still  
continue to use the last release, but the new version may not run  
tests written for the old version without some changes, though in  
fact most of them would probably still continue to work.

Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com