Re: reflection on fields

Re: reflection on fields

No it is not for javaspaces, it is an in house framework.
An annotation smells right to me?

On 6/1/09, Nils Kilden-Pedersen <nilskp <at> gmail.com> wrote:
> I'm guessing this could be for Javaspace Entry objects, which must contain
> public fields. If not, that's another example of the need for public fields
> if full Java framework compatibility is a goal. I can smell another
> annotation.
>
> On Fri, May 29, 2009 at 3:14 PM, Daniel Mahler <dmahler <at> gmail.com> wrote:
>
>> Alex,
>>
>> Thanks, but that is not quite what I need.
>> The  <at> BeanProperty annotation adds getter/setter methods
>> with JavaBeans compliant names.
>> That makes them bean properties, but not fields.
>> The Java code I am calling does not use the beans interface,
>> it just calls getFields on the class and looks in the result for what it
>> wants,
>> but Scala classes do not have public fields (from Java's point of view).
>> I suspect that there is no way to get Scala objects to have public java
>> fields,
>> but I would love to be wrong.
>>
>> Daniel
>>
>> On 5/29/09, Alex Boisvert <boisvert <at> intalio.com> wrote:
>> > This may help,
>> > http://scala.sygneca.com/code/defining-bean-properties
>> >
>> > On Fri, May 29, 2009 at 9:36 AM, Daniel Mahler <dmahler <at> gmail.com>
>> wrote:
>> >
>> >> I am trying to pass a Scala object to some Java code,
>> >> that calls getFields on the objects class,
>> >> and it expects to find certain fields there.
>> >> Scala normally compiles fields into a private Java field,
>> >> with a getter/setter methods.
>> >> Is there any way to get fields of a Scala object to be visible
>> >> as fields in via Reflection?
>> >>
>> >> thanks
>> >> Daniel
>> >>
>> >
>>
>

Java Collections, implicits and aspects

I have been trying to interface to a java framework
which uses nested javacollections and other generic types.
While implicit conversions are nice for simple interface,
converting nested collections seems problematic.
In the past I had considerable success using AspectJ
to add methods and parent interfaces to Eclipse EMF classes
without touching their sources
to develop an Eclipse interface for an application.
It occurs to me that waeving AspectJ extensions
into Java collection classes to make them implement Scala interfaces directly
should lead to a more seamless integration than implicit conversions.
Has anybody tried anything like that.

cheers
Daniel Mahler

Re: Java Collections, implicits and aspects

I forgot you cannot use LTW to weave into java.*,
so I guess this is a non starter.

Daniel

On 6/1/09, Daniel Mahler <dmahler <at> gmail.com> wrote:
> I have been trying to interface to a java framework
> which uses nested javacollections and other generic types.
> While implicit conversions are nice for simple interface,
> converting nested collections seems problematic.
> In the past I had considerable success using AspectJ
> to add methods and parent interfaces to Eclipse EMF classes
> without touching their sources
> to develop an Eclipse interface for an application.
> It occurs to me that waeving AspectJ extensions
> into Java collection classes to make them implement Scala interfaces
> directly
> should lead to a more seamless integration than implicit conversions.
> Has anybody tried anything like that.
>
> cheers
> Daniel Mahler
>

Re: Re: Java Collections, implicits and aspects

import java.util.{List => JList}

I'll imagine you have, um, a JList[JList[String]] for the sake of argument.

Given f : JList[T] => Iterable[T], could you not define g :
JList[JList[T]] => Iterable[Iterable[T]], and thus still use
implicits?

I imagine there's a way of generalising this.

2009/6/1 Daniel Mahler <dmahler <at> gmail.com>:
> I forgot you cannot use LTW to weave into java.*,
> so I guess this is a non starter.
>
> Daniel
>
> On 6/1/09, Daniel Mahler <dmahler <at> gmail.com> wrote:
>> I have been trying to interface to a java framework
>> which uses nested javacollections and other generic types.
>> While implicit conversions are nice for simple interface,
>> converting nested collections seems problematic.
>> In the past I had considerable success using AspectJ
>> to add methods and parent interfaces to Eclipse EMF classes
>> without touching their sources
>> to develop an Eclipse interface for an application.
>> It occurs to me that waeving AspectJ extensions
>> into Java collection classes to make them implement Scala interfaces
>> directly
>> should lead to a more seamless integration than implicit conversions.
>> Has anybody tried anything like that.
>>
>> cheers
>> Daniel Mahler
>>
>

Re: Re: Java Collections, implicits and aspects

If you need to pass nested collections back to some java code,
the converting to just Iterable is not enough,
you need to preserve the level in the hierarchy
These implicit conversions can get a little convoluted,
like some implicits I have written on top of the javautils library:

//   implicit def jlist2s[X](l: java.util.List[X]) = l.asScala
   implicit def jcoll2s[X, Y](c: java.util.Collection[X])(implicit
conv: X => Y) : Collection[Y] =
c.asScala.projection.map(conv).toStream
   implicit def jlist2s[X, Y](c: java.util.List[X])(implicit conv: X
=> Y) : Seq[Y] = c.asScala.projection.map(conv)

//   implicit def slist2j[X](l: Seq[X]) = l.asJava
   implicit def scoll2j[X, Y](c: Collection[X])(implicit conv: X => Y) :
    java.util.Collection[Y] = c.projection.map(conv).toStream.asJava
   implicit def sseq2j[X, Y](c: Seq[X])(implicit conv: X => Y) :
java.util.List[Y] = c.projection.map(conv).asJava

Apart from their complexity they will have a preformance impact.
I have also run into some issues getting these kinds conversions to
actually kick in.
See my earlier thread regarding mutual conversions.

Daniel

On 6/1/09, Ricky Clarkson <ricky.clarkson <at> gmail.com> wrote:
> import java.util.{List => JList}
>
> I'll imagine you have, um, a JList[JList[String]] for the sake of argument.
>
> Given f : JList[T] => Iterable[T], could you not define g :
> JList[JList[T]] => Iterable[Iterable[T]], and thus still use
> implicits?
>
> I imagine there's a way of generalising this.
>
> 2009/6/1 Daniel Mahler <dmahler <at> gmail.com>:
>> I forgot you cannot use LTW to weave into java.*,
>> so I guess this is a non starter.
>>
>> Daniel
>>
>> On 6/1/09, Daniel Mahler <dmahler <at> gmail.com> wrote:
>>> I have been trying to interface to a java framework
>>> which uses nested javacollections and other generic types.
>>> While implicit conversions are nice for simple interface,
>>> converting nested collections seems problematic.
>>> In the past I had considerable success using AspectJ
>>> to add methods and parent interfaces to Eclipse EMF classes
>>> without touching their sources
>>> to develop an Eclipse interface for an application.
>>> It occurs to me that waeving AspectJ extensions
>>> into Java collection classes to make them implement Scala interfaces
>>> directly
>>> should lead to a more seamless integration than implicit conversions.
>>> Has anybody tried anything like that.
>>>
>>> cheers
>>> Daniel Mahler
>>>
>>
>

Re: Java Collections, implicits and aspects

On Mon, Jun 1, 2009 at 8:50 PM, Daniel Mahler <dmahler <at> gmail.com> wrote:
> I have been trying to interface to a java framework
> which uses nested javacollections and other generic types.
> While implicit conversions are nice for simple interface,
> converting nested collections seems problematic.

Can you give an example of the problems you're seeing?

Cheers,

Miles

--

-- 
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://twitter.com/milessabin

Scala 2.7.5 final

We are releasing one more maintenance version of Scala 2.7, in
order to correct a couple of issues found in the actors library.
If you do not use actors in your code, there is no need to
upgrade. The new stable release of the Scala distribution, Scala
2.7.5 final, is available as usual from our Download Page at
http://www.scala-lang.org/downloads.

The Scala 2.7.5 distribution
================================

What is new?
============

Here is the changelog for the actor fixes in 2.7.5:

- Fixed #1999 (Starvation problem when lots of tasks are created
   from FJTaskRunner thread). This could result in the JVM running
   out of memory when a lot of actors where created at a very high
   frequency.

- Fixed #2000 (Linked actors do not always terminate properly).
   This could result in memory leaking in applications that create
   many linked actors.

- Disabled reference-counting actors using WeakReferences, since
   this could lead to memory leaks. Termination of actors is still
   tracked, although using a simpler scheme that does not rely on
   WeakReferences. In some cases, users must now call
   `Scheduler.shutdown()` explicitly to terminate an actor-based
   application.

- Fixed a `NullPointerException` bug in `Scheduler.restart`.

For additional information on Scala 2.7, and on the Scala IDE for
Eclipse, you may also be interested in reading the previous
Scala 2.7.4 release notes, available at
http://www.scala-lang.org/node/1593.

Break and Continue using Exceptions

Hi,

Scala doesn't support "break" and "continue", and the Scala FAQ says
the easiest solution for break is create a new method:
http://www.scala-lang.org/node/257

I implemented "break" and "continue" using exceptions:

=== Usage ========================
package test
import util.BreakLoop._
object TestBreak extends Application {
  var i = 0;
  whileTrue {
    i += 1
    if (i < 3) continue
    if (i >= 5) break
  }
}
=== Implementation ========================
package util
object BreakLoop {
  object Break extends RuntimeException;
  object Continue extends Exception;
  def break { throw Break }
  def continue { throw Continue }
  def whileTrue(block: => Unit) {
    try {
      while (true) try { block } catch { case Continue => }
    } catch { case Break => }
  }
  def whileTrue(condition: => Boolean) (block: => Unit) {
    try {
      while (condition) try { block } catch { case Continue => }
    } catch { case Break => }
  }
}

I know some people say "Exceptions shouldn't be used for flow
control", but as far as I know it's already used for non-local
returns, and it's actually quite fast if done correctly. The slow part
of my solution is the closure, not exception handling. If closure
elimination would work (it doesn't do anything for me currently), then
this solution would be about the same speed as using Java "break":

while (i < 500): 274 ms
while (true) .. if (i >= 500) break: 276 ms
whileTrue (i < 500): 1801 ms
whileTrue .. break: 1961 ms
for (i <- 0 until 500): 5688 ms

What do you think? A viable option, or just a hack to simplify migration?

Regards,
Thomas

Re: Break and Continue using Exceptions

On Tue, Jun 2, 2009 at 9:43 PM, Thomas Mueller
<thomas.tom.mueller <at> gmail.com> wrote:
> Hi,
>
> Scala doesn't support "break" and "continue", and the Scala FAQ says
> the easiest solution for break is create a new method:
> http://www.scala-lang.org/node/257
>
> I implemented "break" and "continue" using exceptions:
>
> === Usage ========================
> package test
> import util.BreakLoop._
> object TestBreak extends Application {
>  var i = 0;
>  whileTrue {
>    i += 1
>    if (i < 3) continue
>    if (i >= 5) break
>  }
> }
> === Implementation ========================
> package util
> object BreakLoop {
>  object Break extends RuntimeException;
>  object Continue extends Exception;
>  def break { throw Break }
>  def continue { throw Continue }
>  def whileTrue(block: => Unit) {
>    try {
>      while (true) try { block } catch { case Continue => }
>    } catch { case Break => }
>  }
>  def whileTrue(condition: => Boolean) (block: => Unit) {
>    try {
>      while (condition) try { block } catch { case Continue => }
>    } catch { case Break => }
>  }
> }
>
> I know some people say "Exceptions shouldn't be used for flow
> control", but as far as I know it's already used for non-local
> returns, and it's actually quite fast if done correctly. The slow part
> of my solution is the closure, not exception handling. If closure
> elimination would work (it doesn't do anything for me currently), then
> this solution would be about the same speed as using Java "break":
>
> while (i < 500): 274 ms
> while (true) .. if (i >= 500) break: 276 ms
> whileTrue (i < 500): 1801 ms
> whileTrue .. break: 1961 ms
> for (i <- 0 until 500): 5688 ms
>
> What do you think? A viable option, or just a hack to simplify migration?
>
that's actually very close to the implementation of break in Scala
2.8. After some fairly involved discussion, we decided to drop
continue.

Cheers

 -- Martin