river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thor Wolpert <t...@lunartek.com>
Subject Re: Concurrency and River
Date Fri, 12 Oct 2007 04:37:01 GMT
A timely article?
http://www.theserverside.com/tt/knowledgecenter/knowledgecenter.tss? 
l=ConcurrencyTestingJavaApps&asrc=EM_NLN_2350350&uid=2626495

Cheers,
Thor HW

On 4-Oct-07, at 9:21 AM, Bill Venners wrote:

> 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
>
>
>
>


Mime
View raw message