I posted over a year ago about Delegates in Java, and since I kicked off an exploration of the functionality I'm providing in my xjava framework with my previous post I thought I would continue with my newest iteration of the Delegates concept as utilized in xjava.

Until you use a language like Scala or Flex that has full delegate support, you can't really appreciate what it is you're missing. As Java programmers we take it for granted that if we need to do some "work" we usually have to create a Runnable implementation that implements the run() method to do the work we need to do:

  Runnable r = new Runnable() {
   public void run() {
    ... do work ...
   }
  };
  passWorkOff(r);

However, in other languages that support Delegates you can pass methods/functions as parameters to methods/functions to simplify this process greatly. Consider the alternative:

 public void someMethod() {
  passWorkOff(this.doWork);
 }
 
 public void doWork() {
  ... do work ...
 }

This minimizes the amount of custom/anonymous classes you must create in order to pass a unit of work off.

Unfortunately in Java this functionality is not (yet) supported. Many people have created work-arounds, generally with Java Reflection, but none can support the elegance of the native delegate support other languages have.

I may be known for my rants, but I won't leave you hanging here with a negative thought of Java, I love the language too much to do that. Besides, I have a framework to promote, so lets get to it. :)

In xjava there is a simple interface Delegate:

public interface Delegate {
 public Object invoke(Object ... args) throws Exception;
}

The invoke method takes a varargs of Objects and returns an Object. It's pretty straight and simple, but the out-working of the implementations are what add significant power to this concept.

There are several different implementations, but by far the most used and most powerful is MethodDelegate. In our above example of using delegates in other languages to pass a function, this imlementation fulfills that role with the following call:

MethodDelegate delegate = new MethodDelegate(this, "doWork");
passWorkOff(delegate);

This presumes that the passWorkOff method takes a Delegate as a parameter. Like I said, this isn't as good as native support, but it's pretty simple and although you lose the ability to have compile-time checking that you're referencing a valid method, it will throw an exception at runtime if the method referenced is unable to be found.

MethodDelegate has some extremely powerful features that have been added to make it even more powerful though. One such feature is the ability to mix and match when arguments are applied to the method being invoked. Say you have the following method you want to invoke:

public void doSomething(String name, String address) {
    ....
}

Now, at creation time of the Delegate you know what "name" is, but in the place you wish to use the delegate you only know the address. See the following:

public void someMethod() {
    Delegate d = MethodDelegate.createWithArgs(this, "createEntry", "John Doh");
    processAddress(d);
}

public void processAddress(Delegate d) {
    String address = "123 Nowhere Rd.";
    d.invoke(address);
}

public void createEntry(String name, String address) {
    ...
}

Notice that at creation time of the Delegate "John Doh" is passed in. This is assigned in the Delegate instance as the first argument to the MethodDelegate. Now, when d.invoke is called in processAddress rather than requiring both name and address just address is necessary to be passed since name has already been assigned.

This makes it incredibly easy to put parameters into the method when you're ready to do so rather than applying everything in one place.

Delegates in xjava also make it easy to abstract away from the underlying way data is being retrieved or being assigned. For example, in the above processAddress method, it simply takes a Delegate and invokes it passing the address to it. If you decided later that you would rather assign this to a field of an object rather than calling a method you would simply replace someMethod with this:

public void someMethod() {
    Delegate d = FieldDelegate.get(person, "address");
    processAddress(d);
}

This presumes the "person" reference is an object with a String "address" field represented within it. The FieldDelegate doubles for getter and setter since passing a value will apply it to the field and invoking without any arguments will get the value from it.

There are also implementations for CallableDelegate and RunnableDelegate that are self-explanatory.

As seen by the interface for Delegate it is extremely easy to create your own implementations of Delegate for whatever scenario you may want to support and abstract away the details of where and what you are actually accessing and though this isn't as elegant as it could be if Java supported delegates natively, it still provides a very decent mechanism for abstracting and simplifying the process of passable work.

See the xjava project for more information:
http://xjava.googlecode.com

Feel free to look at the source code directly:
http://xjava.googlecode.com/svn/trunk/src/org/xjava/delegates/

If you're searching the internet for the title of this post you'll see a lot of people ranting about how Java doesn't have Delegate support. Though I have been one of these people, and continue to be frustrated that there is no native solution, that is not the purpose of this post.

I write this to say I've created what I would consider to be a pretty clean alternative to native delegates in Java using reflection. I created this as a feature in jSeamless and have been using it heavily for a while, but after a few people asking about support in non-jSeamless applications for my friendly Delegate support I decided I would remove it from jSeamless and make it a stand-alone API that anyone can use.

The Delegate implementation I find myself using more than anything else is MethodDelegate. It provides the ability to reference a specific method on a specific object that can be invoked. For example:

I'm a big lover of Reflection in Java. It's extremely powerful and lets you do things that technically shouldn't be allowed. For example, an Object with a private method cannot be invoked outside of that method by virtue of the "private" keyword. However, if you use reflection:

public class MyObject {
private void doSomethingHidden() {
System.out.println("I'm hidden and can't be invoked!");
}
}

public class Test {
public static void main(String[] args) throws Exception {
MyObject o = new MyObject();

Method method = MyObject.class.getDeclaredMethod("doSomethingHidden");
method.setAccessible(true);
method.invoke(b, new Object[0]);
}
}

You can invoke the method by setting accessible to true.

I was attempting to do a similar breaking of rules to try to invoke the underlying method of an overridden class:

public class ObjectA {
public void doSomething() {
System.out.println("I'm ObjectA!");
}
}

public class ObjectB extends ObjectA {
public void doSomething() {
System.out.println("I'm ObjectB! Yay!");
}
}

import java.lang.reflect.Method;

public class Test {
public static void main(String[] args) throws Exception {
ObjectB b = new ObjectB();
b.doSomething();

Method method = ObjectA.class.getDeclaredMethod("doSomething");
method.invoke(b, new Object[0]);
}
}

Unfortunately this always invokes the overridden implementation instead. It's a shame the only way to do this is via super.doSomething() from within the overriding Class. Oh well, I guess it's best that you can't do it as it would be a blatant violation of the intentions of Object overriding.

It's been a while since I posted and after dealing with this horrid bug in Flash I figured it would be a great topic to get me back on track.

So, apparently there's this nifty little bug in Flash/ActionScript with the URLRequest object when you attempt to do a file upload, it uses a completely different browser session than the web browser or any other requests made from within Flash (image loading, sound loading, resource loading, etc.). This isn't a problem unless you care anything about security...and unfortunately most of us do. So the project I'm currently working on uses JCIFS (http://jcifs.samba.org/) for SSO, which is actually very nice by the way, and it uses a servlet filter configured in the web.xml to authenticate the user before they ever hit the page, so by the time they reach the Servlet they've properly been authenticated and I don't have to worry about rogue users.

Okay, so that all works well and good until I try to do a file upload. I try to establish a URLRequest to my JSLServlet (of course this is jSeamless) that I use for everything else, but this time I get a nifty little login prompt using basic authentication. Now, this is of course bad, but what makes it even worse is that Flash simply prompts you and then disregards it and streams the upload into the outer darkness (where there is weeping and gnashing of teeth) so the upload from the Flash perspective worked and uploaded fully (note, before I even enter anything into the login prompt) but the server never receives the upload at all. If I enter my credentials it accepts it and then disappears, but really doesn't care anything about it.

Okay, now for the hack. Now, for you programmers that are faint of heart, don't try this at home. For the rest of us that have to do the job no matter how dirty it might get, please forgive me for what follows...if there were another way I would have done it.

Alright, so I create a new Servlet filter called UploadOverrideFilter (yes, you see where this is going) that gets put in the filter order before the NtmlHttpFilter (JCIFS filter for SSO) that detects if the reference is made to an upload (endswith("jslupload") in my case). Now, what took me a bit of work to figure out is that all mechanism for referencing directly to the Servlet that the filter can pass off to is either barred or deprecated (from ServletContext there are methods for getting a Servlet, but they always return null since deprecation) so I pull out my ugly stick and turn JSLServlet into an evil beast by maintaining a static reference to "instance" that is the initted reference to the currently context JSLServlet instance. Then I simply reference that static JSLServlet instance and explicitly call doPost(...) instead of passing off to the filter chain. See the source code for yourself:

public class UploadOverrideFilter implements Filter {
 public void init(FilterConfig config) {
 }

 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
  if (((HttpServletRequest)request).getRequestURI().endsWith("jslupload")) {
   JSLServlet.instance.doPost((HttpServletRequest)request, (HttpServletResponse)response);
  } else {
   chain.doFilter(request, response);
  }
 }

 public void destroy() {
 }
}

Yep, it's having to write code like this that will be the death of me...a very good reason why I prefer to stick with 100% Java whenever possible is so I don't have to write hacks like this.

Well, I guess it wasn't as bad as it could have been, but it's still a hack and it's things like this that keep me up at night in the cold sweats.

So I lied, apparently my hackery wasn't enough to appease IE even though Firefox happily worked going forward. Apparently in IE it determines, "Oh, I've been authenticated on this URL before...so lets send broken authentication information instead of an upload", and then no matter what you respond back to the request with it just ignores it an on the Flash side acts like it sends the file (very quickly), but never actually comes across.

So now we must expand the previous hackery to not only ignore authentication on uploads, but we have to send to a different "url" in order to keep Flash from thinking it needs to authenticate. I originally tried doing a variation on the directory structure (ie. /authenticated and /unauthenticated), but it's a tricksy URLRequest and decided that it was the same host so it really wanted to send broken authentication information.

My solution? Make Tomcat listen on another port by adding the following line to my server.xml:

<Connector connectionTimeout="20000" maxThreads="150" port="15000" protocol="HTTP/1.1" redirectPort="8443"/>

Then I told my upload to send to the exact same URL except on a different port. I still had to have my security hackery to keep it from requesting authentication, but that did the trick. Now both IE and Firefox can upload files in a JCIFS protected container and the client is none the wiser...unless of course a firewall is blocking that port for which they are trying to upload to....but such are the hacks we must work with when dealing with Flash.

On a side note I will say that Flex 3 has functionality built-in (apparently they got enough rocks through their windows from 2.01 to make them realize they needed to fix it) to tell it to handle authentication or not via a boolean flag. None of this would have been necessary if they would have had the fore-sight to implement that in the first place, but alas, mine is not to reason why...

My massive hack for native drag-and-drop in jSeamless Flex implementation is functional, but only in Firefox. Apparently there is an interesting "feature" in IE that even though you may sign your Applet and the user grants that they way to trust said Applet, it still never gives you read access to the file system.

That being said, here is my outlined approach for another hack that avoids the use of an Applet in favor of Java Web Start. I know Java Web Start can do what I want to do, but to my knowledge there is no way to communicate directly between the client-side web site and the JWS instance.

1. Load the JWS application that stays hidden


2. Load the Flex content page


3. Listen via JavaScript to the mouse cursor entering the browser window - throw an event to the server upon entry


4. Server sends event back to JWS (either socket or delayed Ajax necessary for both JWS and Flex)


5. JWS application triggers the single-pixel-at-mouse-position-window that is listening for dragging


6. If JWS doesn't receive a drag enter event it goes back to sleep and hides our friendly, yet scary, window


7. If a drag enter is thrown it continues to follow the mouse until either the mouse exits the window (another event thrown by JavaScript to Flex to the Server and back to JWS) or a drop event is triggered in the window.


8. If JWS receives a window exit event it goes back to sleep.


9. If JWS receives the drop event a new event is sent down to the server with the list of files dropped.


10. Server sends an event to Flex requesting the current component the mouse is over and temporarily stores the list of files dropped via a request id.


11. Flex determines the current component the mouse is over and sends an event back to the server with that id.


12. Server triggers internal jSeamless event for file dnd with the list of files and the component id (if the component accepts the drop).


13. Upon server-side accept of a file an event is sent to JWS to stream the file


14. JWS receives file stream request and streams the file to the server.

How's that for evil? I thought the original hack was bad, but this is just downright insane. However, it would seem this is the only plausible way to get native drag and drop support.

I had made the commitment a while back that I was going to add complete and perfect drag-and-drop support to jSeamless. The Flex Implementation proclaims support for DnD so I've just pushed off the investigation up until recently. However, now that I've come to implement this great functionality I realize that there is absolutely no support for native DnD. What I refer to as "native DnD" is the ability to drag a file or any other "draggable" content from outside of the application into the application and allow it to pick up and use that content.

Okay, so I figure I'll just do the same type of JavaScript hacks I've done all along to get missing functionality into Flash. To my surprise HTML/JavaScript has no native DnD support either. At this point I'm not only surprised, but afraid my dream of a beautiful drag-and-drop solution for jSeamless is in danger of never reaching fruition.

So I spent the day brainstorming with a colleague about how this can be done. Honestly, there was never a viable solution that wasn't a massive hack, and what we ended up with was actually far better than expected. The solution consisted of using a signed Java Applet to display a single pixel JWindow linked to the cursor when the cursor enters the browser window, it is able to use this as a check to see if the cursor is dragging a droppable item. If it is not carrying something into the browser it then disables itself until the cursor leaves the browser and re-enters again. However, if it is carrying something it remains locked to the tip of the cursor and accepts the droppable wherever they drop it in the application. This JWindow intercepts the drop event, passes an event to JavaScript, JavaScript passes an event to the Flash content and is handled appropriately from there. The event is assigned an ID that can be referenced back from the Flash, to the JavaScript, to the Applet in order to initiate the download at any point in the future.

Yes, this is a massive hack, but does provide a solution that is quite seamless to the user apart from the nasty, "Would you like to grant access to this application to do whatever it wants to your hard drive?" (okay, so it's a little friendlier than that) prompt that must be displayed for the Applet to be able to know pointer location and be able to actually read the file contents from the hard drive.

Fortunately internal drag-and-drop is quite easy to write into Flex. If all goes well, this will all be finished and useful in jSeamless next week. However, for reasons of the aforementioned "evil prompt" it will be disabled by default and will have to be specified to be turned on to be used.

Today was massive hack day. ;)