not suported Java features

[Vlad Dumitrescu]

Hi!

I am using Xtend more and more and there is one thing that is
bothering me. I might have mentioned it before, but it's kind of
important.

Not everything one can do in Java is possible in Xtend. The official
position is that if one needs those parts, then one can use Java for
them. This is a sane position and it helps keeping the focus on what's
impossible or too verbose in Java.

However, the problem is that when I have an Xtend class that suddenly
needs a feature that is not available in Xtend (like for example a
synchronized block, or a bit manipulation operation), then it is
cumbersome to create a separate Java class and delegate to it. Just as
cumbersome is to convert the Xtend class to Java (because the
generated code is not what I would write manually).

I'm not sure what I would like to happen to address this issue, but if
it's not only me that resents it then I hope that a discussion will
help clarify the alternatives.

best regards,
Vlad

[Sven Efftinge]

Hi Vlad,

thanks for the feedback. Could you please write down the specific features you are missing, so we can discuss how to address them individually.

Sven

[Vlad Dumitrescu]

Hi Sven,

On Thu, Aug 23, 2012 at 12:11 PM, Sven Efftinge <sven.e...@itemis.de> wrote:
> thanks for the feedback. Could you please write down the specific features you are missing, so we can discuss how to address them individually.

At the moment, the thing I stumbled upon is the lack of 'synchronized'
blocks. There is the alternative of using the java.util.concurrent
classes instead, but for simple cases it feels like overkill. Maybe
this will be addressed by the coming custom annotations?

I also mentioned the bit operations. "a&b" is
"IntegerExtensions::bitwiseAnd(a, b)", which is a little unwieldy. Is
it possible to add Xtend extension classes to the list of JDT
"favorites" (i.e. classes that are automagically imported statically)?
That would help a lot.

I don't really mind going back to Java when it is better, but if my
class already uses Xtend idioms heavily, I don't really want to
rewrite that or handle tons of FunctionX/ProcedureX anonymus classes.

regards,
Vlad

[digulla]

Am Donnerstag, 23. August 2012 12:54:45 UTC+2 schrieb Vlad Dumitrescu:

At the moment, the thing I stumbled upon is the lack of 'synchronized'
blocks. There is the alternative of using the java.util.concurrent
classes instead, but for simple cases it feels like overkill. Maybe
this will be addressed by the coming custom annotations?

Use a lock instead. With an extension written in native Java, you can write:

    lock.run [ ...code... ]

Many other problems can be solved in a similar way. As for bit operations: It would make a lot of code much more readable if people would wrap bit operations into clearly names extension methods:

    class.isStatic

    field.isFinal

    a.lowest1Bit

Regards,

A. Digulla

[Vlad Dumitrescu]

Hi!

On Tue, Sep 11, 2012 at 9:37 AM, digulla <adig...@gmail.com> wrote:
> Am Donnerstag, 23. August 2012 12:54:45 UTC+2 schrieb Vlad Dumitrescu:
>
>> At the moment, the thing I stumbled upon is the lack of 'synchronized'
>> blocks. There is the alternative of using the java.util.concurrent
>> classes instead, but for simple cases it feels like overkill. Maybe
>> this will be addressed by the coming custom annotations?
>
> Use a lock instead. With an extension written in native Java, you can write:
> lock.run [ ...code... ]

Good idea!

> Many other problems can be solved in a similar way. As for bit operations:
> It would make a lot of code much more readable if people would wrap bit
> operations into clearly names extension methods:
>
> class.isStatic
> field.isFinal
> a.lowest1Bit

Yes, I agree. The main thing to remember is that Xtend has its own
ways to solve problems and straight conversion from the Java code is
often not the best solution. However, now at the beginning we are
still discovering what the "Xtend way" is and the very basic things
should arguably be included in the standard libraries. There's no need
for every man and his dog to discover and implement the same stuff
from scratch.

regards,
Vlad

[Boris Brodski]

Hello Sven,

I miss more control over anonymous classes.

At the current time I try to get JMockIt to work. In order to do this, I have to write an anonymous class (extends Expectations, for example), that

adds a new methods or defines initialization block (JAVA: new Expectations() {{ ... code ...}} )

What I try to do is to get this Xtend syntax to work:

mock [

  login("user", "pass")

  result = true

]

This should produce the JAVA code like this:

new Expectations() {{

  login("user", "pass")

  result = true

}}

or 

new Expectations() {

  public void someMethod() {

    login("user", "pass")

    result = true

  }

}

or something similar.

I already tried to declare my own abstract class in between the Expectations and the anonymous classes, that defines the new method as an abstract.

abstract class MyExpectations extends Expectations {

    public abstract Object init(Object o);

}

and then

protected void mock(final MyExpectations e) {

  e.init(null);

}

But I get the following error:

Incompatible types. Expected a.b.c.MyExpectations but was (java.lang.Object)=>void

It's important, that the mock-code placed directly to the anonymous class and not called from the anonymous class, like this:

protected void mock(final Procedure1< Expectations > proc) {

    new Expectations() {

        {

            proc.apply(this); // Doesn't work with JMockIt :-(

        }

    };

}

Do you have an advice for me?

Thank you!

Regards,

Boris

[Sven Efftinge]

No idea sorry. Xtend doesn't support initializers nor anonymous classes. 

I'd look into the internals of JMockit to find an API that better fits Xtend.

After all they seem to stretch the boundaries of "Java" quite a lot. ;-)

[Boris Brodski]

Thank you very much! I'm waiting! (also looking for possibilities)

If we get it to work I would like to make a screen cast about it :-)

[Boris Brodski]

Hello,

it looks like I managed to get it work. I will push it to the github and post the url here.

Thank you for your help!

[Caleb holt]

Inner classes/interfaces

UIBinder for GWT requires that you create an inner interface class to use UIBinder. But it seems this feature is missing so I am unable to convert my UIBinder classes to XTend.

I created the interface outside of the class, but I still received this message from the designer view of UIBinder. 

You are attempting to use UiBinder for com/mycompany/deploy/clients/first/FirstView.ui.xml, however your companion Java type (UiBinder inner type subclass) does not exist. Please use the wizard to create a new ui.xml template and companion Java type.

[Hilco Wijbenga]

On 25 September 2012 16:14, Caleb holt <bonele...@gmail.com> wrote:
> UIBinder for GWT requires that you create an inner interface class to use
> UIBinder. But it seems this feature is missing so I am unable to convert my
> UIBinder classes to XTend.

FYI, GWT most certainly does *not* require that. None of our UIBinder
interfaces are inner interfaces. They *do* need to be in the same
package as the *.ui.xml file.

[Caleb holt]

I'm not saying that it's happening to you, evidently it is not happening to you; this is happening to me though possibly we get different results because we have different GWT versions?

I think the error message is fairly clear though, it states "however your companion Java type (UiBinder inner type subclass) does not exist." It says inner type subclass, I mention above that I extracted the interface from the class I left out that I placed it in the same package, though I did place it in the same package.

Does this picture verify what you meant? I could have misunderstood you.

I'm sure your first question will be why are there 2 broken views. Because one was the original view, the second is because the UIBinder interface gives me an error when I don't have a view that matches up exactly to how the interface is named. But in any case, neither of them work.(As you can see in the picture).

I have uploaded a project that demonstrates what is happening, I would very much appreciate it if you would let me know that you do something different and get it to work.As far as I can understand the problems I'm having are very much in line with the error messages that eclipse is giving me. And that is my reasoning for bringing this up not being able to do inner sublcass interfaces in the "Not supported java features thread"

[Hilco Wijbenga]

Hi Caleb,

On 27 September 2012 10:26, Caleb holt <bonele...@gmail.com> wrote:
> I'm not saying that it's happening to you, evidently it is not happening
> to you; this is happening to me though possibly we get different results
> because we have different GWT versions?

I know this works in both GWT 2.5-rc1 and GWT 2.4.

> I think the error message is fairly clear though, it states "however your
> companion Java type (UiBinder inner type subclass) does not exist." It says
> inner type subclass, I mention above that I extracted the interface from the
> class I left out that I placed it in the same package, though I did place it
> in the same package.

You seem to be using the GWT Designer plugin. I never use it as it
never worked for me. This seems to be a hardcoded message from GWT
Designer and as such does not represent any GWT requirements. It may
be a GWT Designer requirement, though.

> I have uploaded a project that demonstrates what is happening, I would
> very much appreciate it if you would let me know that you do something
> different and get it to work.As far as I can understand the problems I'm
> having are very much in line with the error messages that eclipse is giving
> me. And that is my reasoning for bringing this up not being able to do inner
> sublcass interfaces in the "Not supported java features thread"

I just spent a couple of hours trying to get your project to work.
Sorry but I spent too much time on this already. We have a more
reliable way of working/building: Maven. :-)

The only differences that I can see is that I use the @UiTemplate
annotation on my UiBinder interfaces. And ours are public (but that
*really* should not matter). Neither difference should be relevant. I
suspect you ran into a GWT Designer limitation.

Cheers,
Hilco

[Caleb holt]

Thanks for looking, the @UiBinder annotation did bring me one step closer (It allows me to run my application now, before I also could not launch) but it still breaks GWTDesigner though in a new way that has nothing to do with UIBinder interfaces being inner classes. I guess that removes any reason for me to ever use inner interfaces in XTend. Though I have asked google groups why something that runs perfectly fine in eclipse doesn't work with GWTDesigner. I am looking forward to being able to use XTend more heavily in GWT.