BoxedUnit vs void

[Edmondo Porcu]

Dear all,
what does it mean when a method returns a BoxedUnit ? This is causing
me some problems with legacy code, where I am expecting the function
to return a "java void" and it returns a BoxedUnit....

Best Regards

Edmondo

[Daniel Sobral]

Is it extending a class where that method is defined as returning a
type parameter? For example:

class A[T] { def f: T }
class B extends A[Unit]

In that case, the method f must return Object because of erasure, and
the erasure of Unit is BoxedUnit.

--
Daniel C. Sobral

I travel to the future all the time.

[Edmondo Porcu]

No...this is not. The problem is that I have a caching/event framework
and I found in the cache millions of scala.BoxedUnit.

In this framework I define an eventHandler in the following way

@EventDriven

class MyEventDrivenClass {

@EventHandler def handler (event:MyDomainObject)

@EventTemplate def template:MyDomainObject = new MyDomainObject(1,2);
}

It is legal to write a method annotated with @EventHandler with a
return type of VOID or with a return type equal to the input type. In
case the return type is void, the processed event won't be put back in
the cache, in case the return type is equal to the input type, the
object will be written back in the cache.

I have therefore a method which I thought would have returned java
VOID and returns BoxedUnit. Is there a way I can investigate that?

Best Regards

Edmondo

2012/3/16 Daniel Sobral <dcso...@gmail.com>:

[Edmondo Porcu]

Dear Bjorn,
I absolutely agree with you there is a problem inside my class, but I
don't know which one might be triggering that. Is it possible to
detect at "global level" where a BoxedUnit is generated happens, such
with a breakpoint, a decompilation, or something like that?

Best Regards

Edmondo

2012/3/16 Björn Antonsson <bjorn.a...@typesafe.com>:
> Hi Edmondo,
>
> I'm pasting your example into the REPL, and everything seems ok.
>
> scala> class MyEventDrivenClass {
>      | def handler(event: String) {}
>      | }
> defined class MyEventDrivenClass
> scala> :javap MyEventDrivenClass
> Compiled from "<console>"
> public class MyEventDrivenClass extends java.lang.Object implements
> scala.ScalaObject{
>     public void handler(java.lang.String);
>     public MyEventDrivenClass();
> }
>
> If that's really your whole class, then I've no clue to what's going on.
>
> /Björn
> --
> Björn Antonsson
> Typesafe - The software stack for applications that scale

[√iktor Ҡlang]

On Fri, Mar 16, 2012 at 5:02 PM, Edmondo Porcu <edmond...@gmail.com> wrote:

Dear Bjorn,
I absolutely agree with you there is a problem inside my class, but I
don't know which one might be triggering that. Is it possible to
detect at "global level" where a BoxedUnit is generated happens, such
with a breakpoint, a decompilation, or something like that?

I suspect that the sample code isn't the truth, and that there somewhere is a class with a type parameter in the return type such that it return T, which would return BoxedUnit when T is Unit.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Edmondo Porcu]

That might be true, actually...at a framework level..

for every class annotated with @EventDriven the framework create an
object, which is the real EventHandlerImpl, through reflection.

I guess the object exploits generic, as you are saying, and probably
the reflection mechanism can't recognize that a method returning Unit
is a void, and therefore treat it like the others...

Does it sounds reasonable?

Best Regards

2012/3/16 √iktor Ҡlang <viktor...@gmail.com>:

[√iktor Ҡlang]

On Fri, Mar 16, 2012 at 5:10 PM, Edmondo Porcu <edmond...@gmail.com> wrote:

That might be true, actually...at a framework level..

You have to tell us the truth, we can't help you otherwise.

 

for every class annotated with @EventDriven the framework create an
object, which is the real EventHandlerImpl, through reflection.

I guess the object exploits generic, as you are saying, and probably
the reflection mechanism can't recognize that a method returning Unit
is a void, and therefore treat it like the others...

Does it sounds reasonable?

Sounds plausible enough.

Cheers,

√

[ericacm]

Edmondo: 

I realize this is pretty old but I ran across this today.

scala> def f(i: Int) = if (i > 0) throw new Exception

f: (i: Int)Unit

scala> val u = f(0)

u: Unit = ()

The type of u is actually BoxedUnit. 

[Dave]

I don't see a BoxedUnit there. It's a unboxed Unit otherwise I could unbox it.

 

 

scala> def f(i: Int) = if (i > 0) throw new Exception
f: (i: Int)Unit

scala> val u = f(0)
u: Unit = ()

scala> Unit.unbox(u)
<console>:10: error: type mismatch;
 found   : Unit
 required: Object
Note: Unit is not implicitly converted to AnyRef.  You can safely
pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so.
              Unit.unbox(u)
                         ^

scala> val v = Unit.box(u)
v: scala.runtime.BoxedUnit = ()

scala> Unit.unbox(v)

[ericacm]

My bad - I shouldn't have given an example using the REPL.   I was actually seeing that in the debugger.  I set a breakpoint right after getting the value of f(0) and the type of the "u" object in the debugger is scala.runtime.BoxedUnit.