What a .NET guy likes about AppEngine

I recently completed work on an app built on AppEngine and Google Web Toolkit:

It's basically a logo design app with a twist - follow the link if you wanna find out more on the app itself.

To the point, the team on this project came mostly from a Java background and even though I am mainly a .NET nut I also have a bit of Java under the belt, so this project represented the perfect opportunity for me to get some sweet  AppEngine + GWT action.

So here we go, here's the good old list of things I really liked about the setup on this project (Java/AppEngine/GWT on Eclipse + Google plugins) compared to the setup I am more familiar with (C#/ASP.NET + SQLServer + Azure hosting, all on VS):

• With AppEngine and the Google-Datastore you don't have to cope with SQL or SQLServer (and if you follow this blog you know how I feel about SQL)
• You can literally deploy your app with one-click from the eclipse plug-in (all extremely easy to setup - and it works)
• Hosting is free on google appspot (if you don't go over the free quotas, and quite cheap after that anyway)
• GWT = virtually no messing around with javascript (I do like javascript but not if I am in a hurry)
• .NET/VS to JAVA/Eclipse transition turned out to be OK (Eclipse is pretty cool) with people around to rely on

So far AppEngine has proven reliable - the app still runs a bit slow but we did not put any effort into improving performance (I've seen ASP.NET apps running much slower, and it rarely boils down to hosting anyway) - stay tuned for more.

Nightmare before Christmas: How to use JFace + SWT standalone

I could've as easily called this Eclipse plugins from HELL, but being Christmas and all I thought I would go for the Christmas thing, which gives me the opportunity to wish Merry Xmas to all the geeks who happen to be reading this lame-ass blog over the holidays instead of watching Star Trek as per tradition.

Being mainly a .NET guy, I am not too familiar with the eclipse platform, but I desperately needed to put together a quick UI and decided to go with JFace and SWT after @tarelli suggested so (he's the JAVA guy). Unfortunately, at the time I didn't realize he was talking about an Eclipse plugin project and not about using JFace and SWT in a standalone Java app.

So I went on and got started with some nice tutorials specific to running JFace + SWT standalone, and some more gentle introductions.

Time to get my hands dirty, so I started a new Java project, and dropped in some of the code from the tutorials. In order to get it build I needed to import JFace and SWT plugins as external jars, which I could not find anywhere in my plugins folder (I am on Galileo C:\eclipse 3.5\plugins). I needed to somehow get the damn plugins, but could not quite figure out how to get only those I needed from Help --> Install Software Updates, so I ended up pulling down anything to do with Eclipse SDK. To my delight the SWT and JFace plugins were there (in the plugins folder) after the lengthy process of downloading tons of stuff I didn't need.

After a bit of mocking about (blindly trying to import anything with jface or swt in it) I managed to understand which jars I needed to import to get the damn thing to build (org.eclipse.jface_3.5.1.M20090826-0800.jar and org.eclipse.swt.win32.win32.x86_3.5.1.v3555a.jar) I started mocking about with the code and spent a good while playing around with ContentProviders, ListViewers and so forth. Everything was building nicely, but as soon as I tried to run it as java application got the cold shower:

Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/core/runtime/IProgressMonitor
    at demo.ui.test.EntryPoint.main(EntryPoint.java:18)
Caused by: java.lang.ClassNotFoundException: org.eclipse.core.runtime.IProgressMonitor

Apparently some type was missing somewhere. I've seen a lot of sh*t working on Visual Studio and all, but errors don't get much more cryptic than this.

After a good while, after unfruitfully trying to offline troubleshoot the heck out of my project (offline troubleshooting is just madness but I was waiting the phone company to turn on my broadband in the new apt i moved to recently), I reverted to @tarelli, the eclipse guru who got me into this mess, and begged for help: he promptly told me that I was in a bit of a feckin' mess, and if I wanted to get out of it alive I would've had to create a Plugin Project "with a view" and take it from there. I tried, and he was right, but I did not want a plugin and all the overhead that comes with it, so I kept pulling my hair for several hours with no luck, then went to bed. I felt rightly and truely screwed, if you want.

Luckily the day after the phone company turned on my broadband and I could stop passively obsessing about the problem and started aggressively abusing google in search of a solution to the problem.

After a not too long research (God bless THE INTERNET), turns out that if you want to use JFace + SWT outside a plugin based project you need some other jars. Basically if you're using JFace and SWT in a plugin project runtime dependencies are managed for you through the manifest file (I seem to understand) but if you go for the rogue option of having SWT running standalone then you need to know you need that stuff.

In the specific case of the IProgressMonitor thingy, adding a reference to the org.eclipse.equinox.common jar did the trick. After that I got the same error on a different class, EventManager, and after a couple of blind trials I got it working by importing the org.eclipse.core.commands jar. Obviously, not a mention of this in the tutorials, as I seem to understand there was a bit of refactoring on those packages after those tutorials were drafted (looks like this problem is around since eclipse 3.2 --> read this bug report for further info).

What can I say? If you're coming from .NET sometimes Java == Pain.

[.NET vs Java] Event Handling: Are you sure pure OOP is always the simplest?

After a long time I'm again here for another post!
I will talk about event handling, focusing at first on .NET way to supply it, and then spending 2 words about the Java style.
What I want to talk about is delegates and how are they used...I know old good Giovacchia has already spoken about them in a previous post (here) but I wanna talk about them again.
Why?
I'm leaving for a while the Java world and walking through the .NET Framework (I have to take some Microsoft Certifications, 2 or maybe 3 exams in just 1 month and a half...sounds crazy but it's my task in the short term): this means I have to study, as for now, 2 book of about 1000 pages each one.
I'm not taking part in the war between Open Source Multi Platforms Java Conding and Mama Microsoft Windows-Platform Framework yet, but in this path toward the MS certifications I will try to catch what's good and what's not in both frameworks.
At a first sight (I'm about at the half of the first book) 2 years of experience in Java programming has helped me a lot, but I stopped a while learning about delegates.
I don't want to explain what actually they are (Giovacchia in his post said it perfectly), let's just say delegates are a kind of function pointers, and you have to subscribe a delegate to a particular event in order to make it running when that event is raised.
Because my memory is so short term (could it be Google's fault?), during the reading I made a simple schema to remember which key words to use when declaring a delegate and rasing your own event.

namespace HereIsMyDelegateNamespace{
 . . .

 public delegate void MyEventHandler(object o, System.EventArgs ev);

 . . .

 public class MyClass{
    . . .
    public event MyEventHandler MyEvent;
    . . .
 
    /* this method raises an event */
    publlic ReturnType RaisingMethod()
    {
        System.EventArgs ev = new System.EventArgs();
        . . .
        MyEvent(this,ev);
        . . .
    }
 }
}

namespace ConsumerNamespace{

 public class Consumer{

      public static void Main(string[] args)
      {
          . . .
          MyClass m = new MyClass();
          m.MyEvent += MyEventHandler(m_MyEvent);
         . . .
         /* from now on we can call a method
         *  or make an action which causes MyClass to
         *  raise the MyEvent event */
         m.SomeMethodThatRaisesTheEvent();
         . . .
      }

      public static void m_MyEvent(object o, System.EventArgs ev)
      {
          . . .
          /* handles the event */
      }
 }

}

You have to remember few things:

• The signature of the delegate has to be the same of your own handling method


• The signature of the delagete has to contain 2 parameters: the first one is an object reference, that refers to the object that launches the event, and the second one must be a subclass of System.EventArgs (there are a lots of them implemented for the common events)


• You can subscribe to an event using the overloaded operator += but you can also unsubscribe by using the -=


• For common applications, you won't need to raise yourself an event, but just supply a method and subscribe it to the event (the method, as said, has to have the same signature of the needed delegate)

And what about Java?
Learning Java I actually never had the need to write down some code to remember how Event Handling works.
Why? There are no delegates, in the sense you need to specify an entire class as the delegate for that event. What does it happen when you need to subscribe to an event?
In that situation Java is more OO then .NET, indeed you only use your Handler Class (such as MouseListener class, but for the common events, e.g. such as Mouse and Keyboard, you have at your disposal tons of ready-to-use classes) to manage the event. In this scenario you call directly by the object that throws the event, an addXXXListener() or removeXXXListener(), and inside your class, in which you surely have an array of potential listeners, when you want to raise the event, you have to iterate manually by calling all the needed methods of the listeners subscribed.
IMHO Java is straightforward to the OOP, but you need more code, and .NET allow you by using delegate and event keywords not to think to the propagation of the event. Moreover, in .NET you won't need to specify an entire class to handle the event, bringing to a more concise code style.

I'm not as experienced in .NET as I'm in Java, so maybe in few weeks I will post the exact opposite kind of opinion, but as for now I'm feeling better using C#, as it seems it has taken the good in Java and brought it to a more powerfull level (I'm refering to the whole framework ofcourse and not to the language itself).