Invert Your Mind

I may have just hit a nasty JDK varargs issue. If you have two constructors with the same number of non-vararg parameters and one of them has an additional varargs parameter, you need to be very careful which is called. Here is the code:

public void foo(Class klass, String str, String... names);

public void foo(Object obj, String str);

It looks like Java favors matching on parameter numbers and not types. If you invoke this method like this:

foo(Bean.class, "Bean");

It invokes the SECOND version and NOT the first! Looks like the JDK matches on the number of parameters (2) and ignores the fact that the first version of the method matches better because of typing and the fact that varargs is empty.

UPDATE;
Thanks to a commenter, I found the section in the JLS that determines if variable argument methods are invoked:

“The first phase (§15.12.2.2) performs overload resolution without permitting boxing or unboxing conversion, or the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the second phase.”

This states that in order to keep backwards compatibility, if first ignored methods with variable arguments (variable arity). This is ONLY for backwards compatibility and if JDK 5.0 was really a major release with no compatibility than my initial assessment of this being a bug would be true.

I spent a couple of hours trying to figure out how to handle 404 and 500 errors in Rails. This is not simple and actually really annoying. Hopefully future versions clean this up because right now it sucks pretty badly. Anyways, I found a page on the wiki and some other blogs, but the issue was that they wouldn’t handle all the cases. So, here’s the solution:

1. Edit your app/controllers/application.rb file and add these three methods:

  def rescue_404
    rescue_action_in_public CustomNotFoundError.new
  end

  def rescue_action_in_public(exception)
    case exception
      when CustomNotFoundError, ::ActionController::UnknownAction then
        #render_with_layout "shared/error404", 404, "standard"
        render :template => "shared/error404", :layout => "standard", :status => "404"
      else
        @message = exception
        render :template => "shared/error", :layout => "standard", :status => "500"
    end
  end

  def local_request?
    return false
  end

The first method will be explained in the next step. The second method is the method that Rails calls to handle most errors. This method will not capture a certain class of errors where neither the controller nor the action requested exist. The third method tells rails to stop sucking. Normally Rails handles requests made to localhost or 127.0.0.1 differently than all others. This might be for debugging purposes, but it sucks when testing error handling.

2. Edit config/routes.rb and add this line TO THE END OF THE FILE:

  map.connect '*path', :controller => 'application', :action => 'rescue_404' unless ::ActionController::Base.consider_all_requests_local

This tells Rails that if it can’t find any other route to handle the request (i.e. the *path) it should call the rescue_404 action on the application controller (the first method above).

3. Edit config/environments/development.rb and add this line:

ActionController::Base.consider_all_requests_local = false

This additionally tells Rails to stop sucking and stop handling requests to localhost and 127.0.0.1 differently.

Anyways, happy coding.

Finally found the plugin I was looking. It is called called Swift Tabs. Every other application I use provides the flexibility to change the next previous tab keys, and even though I had the option, the defaults for everything was always ALT and the arrow keys. I just got used to it and it works well and makes sense. Well, I finally found the firefox plugin that let me change the shortcuts for next/prev tab. Here’s the link

https://addons.mozilla.org/firefox/380/

I’m not a big fan of Google’s engineers in general, but this one is an excellent example of Google just being stupid:

http://www.ddj.com/dept/webservices/196800994

Apparently, the Google engineering genius decided that it wasn’t important to ensure the request coming in VIA an AJAX request had the correct user session cookie and that the users session was still valid on the server. No…. Instead they just decided that this and probably hundreds of other AJAX requests didn’t need any security and just worked no matter who the requesting client was. This is web programming 101 folks. Since the browser (user-agent) must provide the same cookies for an AJAX request as it does a normal request, there is NO reason a web application shouldn’t secure AJAX requests as it does normal requests using the in-memory session cookie.