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
