Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
September 22, 2017, 08:51:27 PM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
Pages: [1]
Print
Author Topic: ICommand not applicable for arguments in registerCommand  (Read 16330 times)
carman23
Newbie
*
Posts: 1


View Profile Email
« on: November 19, 2012, 11:11:13 AM »

I have Eclipse Indigo, and JDK 1.6.0_37
I have downloaded PureMVC for Java: J2ME demo, which uses v0.2 of the PureMVC Java port.

When I try to use v1.1 of the PureMVC Java port, in the downloaded J2ME demo, I get the following error on registerCommand and addSubCommand, both of which expect an ICommand as the second parameter:

"The method registerCommand(String, ICommand) in the type Facade is not applicable for the arguments (String, Class<StartupCommand>)"

Here's StartupCommand:
public class StartupCommand extends MacroCommand {...}

Here's the registerCommand that has the error shown above:
registerCommand(STARTUP, StartupCommand.class);

I notice that version 0.2 of the PureMVC for Java port does not require an ICommand for the second parameter of registerCommand() and addCommand(), which tells me why the above statements work in the downloaded J2ME sample.

But version 1.1 of the PureMVC for Java port requires an ICommand as the second parameter for registerCommand() and addCommand(), which to my mind should still work, since the second parameter, StartupCommand extends MacroCommand which itself implements ICommand.

REQUEST:
Can anybody help me registerCommand() or addCommand() without the error shown above, when using PureMVC 1.1 for Java?

Thanks

Logged
Tekool
Sr. Member
****
Posts: 192


View Profile WWW
« Reply #1 on: November 19, 2012, 12:31:52 PM »

The update from «Class commandClassRef» to «ICommand command» has been made when upgrading the PureMVC standard Java framework from PuremVC Java multicore framework.

I'm not too much on Java development, but I did the upgrade myself to help the community because we had many silmutaneous problems with the standard framework. I near have copied the multicore framework and converted it back to standard. To be honnest I don't remember that it required to use an ICommand instead of a class reference. It would be better to use a class reference here if we really can without unknown side effect.

For your exact problem, this is normal that the compiler throw an error here as the type on the object you pass as an argument is not an ICommand but really a Class object.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW
« Reply #2 on: November 19, 2012, 03:03:36 PM »

I believe that the standard version (which has had quite a tumultuous history, to say the least) was last re-implemented by a team who was focused on GWT, and one problem (as I understand it) was that you couldn't pass a class reference. Perhaps GWT doesn't (or didn't) have reflection support, I'm not sure.

I was unhappy at the idea of reusing an ICommand instance, because it is counter to the original design philosophy and thus the same advice cannot be applied across platforms, which is bad.

I think Frederic is right in thinking of just back-porting the MultiCore version to Standard so they operate the same, except that may mean inability to use in GWT. Frederic, could you look at whether GWT can pass class references around?

-=Cliff>
Logged
Tekool
Sr. Member
****
Posts: 192


View Profile WWW
« Reply #3 on: November 19, 2012, 03:32:34 PM »

I believe that the standard version (which has had quite a tumultuous history, to say the least) was last re-implemented by a team who was focused on GWT, and one problem (as I understand it) was that you couldn't pass a class reference. Perhaps GWT doesn't (or didn't) have reflection support, I'm not sure.

You're right! I remember the whole history now. I was quite surprised of this.

could you look at whether GWT can pass class references around?

I don't think I will have time before a while for that. I already have too many things on the grill to finish before. I even tried to recruit someone interested in PureMVC Java recently:https://github.com/ndeverge. Nicolas kindly made a pull request to add Maven support to the Java standard port I was hosting on my own Github for the work on converting it from multicore. Now that even PureMVC is on Github I will push it back to PureMVC Github. I may ask him again if he is interested in this problem.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW
« Reply #4 on: November 19, 2012, 06:06:46 PM »

Apparently reflection is not possible in GWT without jumping through hoops:
http://stackoverflow.com/questions/4195233/can-you-use-java-reflection-api-in-gwt-client
https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/64lJJ6GHa6E

For the time being, carman23, it looks like the answer (as awful is it seems) is that in the Standard version, you have to send in an instance of the command and make sure that it doesn't do anything stateful (i.e. make sure to clear your variables each time execute is called).

In the MultiCore port (which this demo should get ported to) you could send the class reference.

The very oldest version of the framework did pass class references. Then it was completely replaced with the GWT version, and this demo didn't get updated.

This difference is untenable, and we'll have to address it, if I have to dive back into Java myself to do it. It has been many years, but it'd be a matter of tooling up again for it. Not a bad exercise.

The problem is just what to do, and I think it would be reasonable to move GWT to its own port. It can't be claimed to be Java without reflection. Java is Java and GWT is GWT. Therefore it would become the GWT standard port and we'd backport the Java MultiCore to Standard and just strip it of the multicore aspect.

That is a tangle in terms of people who may be using the port, but moving it to a branch is not something that works well either for the long term.

-=Cliff>
Logged
Pages: [1]
Print
Jump to: