Felipe Leme's Blog: February 2007 Archive

Posted by felipeal on February 27, 2007 at 08:18 PM | Permalink | Comments (4)

Have you ever spent hours trying to run 2 instances of Firefox on Linux, using command-line arguments (like -ProfileManager) that *used* to work, but now simply open a window in the same Firefox process? If you did, this blog is for you...

First of all, Mozilla-based products like Firefox use profiles. That feature is so useful that it deserves a blog of its own (no, I won´t reinvent the wheel). But basically speaking, it means you can create different profiles, each with its own mozilla data (like cookies, bookmarks, passwords, etc...), and use them simultaneously. This is quite useful when you are developing web applications and must test it as different users. Or in a more mundane (and less development-based) situation, when you need to access a website using 2 different accounts (for instance, I have 2 main GMail accounts, felipeal and felipealists, the former being my main user, and the latter used only for managing mailing lists).

So far, so good - no big news in the scenario I described above. The problem is, the CLI (command-line interface) seems to be broken in more recent versions of Firefox and/or Fedora Core. I.E., if I have a running firefox instance using the default profile, and type the following command in the shell:


firefox -P sidekickProfile

or even:


firefox -ProfileManager

it opens a new window using the same firefox process (and hence using the same profile), instead of starting a new process (with a different profile, or popping up the profile manager window, respectively)!

That issue has been hunting me for many months, but as I just needed that feature a couple of times during this period (and being a professional procrastinator :-), I never had the patience to figure it out what was wrong - I just su-ed to a new user and ran a different instance of firefox (which is an ugly hack).

Well, last week, I finally got ashamed of myself, decided to fight the laziness, and figured out what the problem was! Looks like somewhere in the Firefox/Mozilla evolution (I guess it was Firefox 1.5), the startup scripts assumed the responsibility of deciding if a new process should be started, or if the CLI parameters should be passed to an existing (remote) instance.

Long-story short, in order to achieve the desired (for me, at least) behavior, you must set the variable MOZ_NO_REMOTE, to any value (or even none, as seem in the second example below - don't ask me why, I've never seem such behavior before!). For instance:

MOZ_NO_REMOTE=hell,yes firefox -P sidekickProfile
MOZ_NO_REMOTE= firefox -ProfileManager

Or, in a nice Unix way, create aliases to do the job:

alias ff2=`MOZ_NO_REMOTE= firefox -P sidekickProfile`
alias pm=`MOZ_NO_REMOTE= firefox -ProfileManager`

As a final note, I will leave here my 2-cents rant: why have this behavior changed in recent versions of Firefox? I mean, I´m fine with the script taking the responsibility of reusing existing process (I guess that burden was taken care off by the Linux/Unix integration before), but once you *explicitly* pass CLI arguments to invoke the profile manager, why the hell should the script pass them to a running process???

Final? Not yet...

Posted by felipeal on February 13, 2007 at 08:11 AM | Permalink | Comments (8)

Now that the pandora box is open is open, it is my turn to suggest a (possible worthless, I know) change to the Java language: the semifinal modifier!

I had this idea on my way home last week, after teaching the final keyword for my current Globalcode class. The idea was basically this: final is a well designed modifier, as it has a similar meaning on the many places it can be used (variable, method and class definitions). So wouldn't it be nice if there was a similar modifier for definitions that are not quite final?

Enters the semifinal modifier - too bad I didn't have this idea during the World Cup :-(.

The first and most useful case (if not the *only* useful case at all) is when defining a class: a class (or interface) marked as semifinal can be extended, but its public behavior cannot change. In other words, you can override any method of this class (as long as you do not make then more accessible than the original), but you cannot add any public method (or attribute).

The reasoning? I think such classes could be useful when defining APIs, frameworks, or components, where you do not want to allow extended classes to be more capable than its superclass (a side effect of this new class modifier is that the compiler could generate warnings when a subclass of a semifinal class is used as the type of a reference, parameter or method return). For instance, say you have an interface I that has methods mA() and mB(), and one implementation X that adds a method mC(). Over time, mC() becomes so popular and necessary that the clients of I always cast it to X, in order to call mC(). Well, if this method is so necessary, it should be part of I, and not an implementation detail - declaring I as semifinal would force it (i.e., X could not add a new public method mC()).
Here is an example:

semifinal class SuperClass {
   protected void m1() { 
   }
   protected void m2() { 
   }
   public void m3() {
   }
}

class SubClass extends SuperClass { 

   // declaration below is valid: same access level (protected)
   protected void m1() { 
   }

   // declaration below is not valid: more accessible (public)
   public void m2() { 
   }

   // declaration below is valid: overriding public method
   public void m3() { 
   }

   // declaration below is valid: new method, but private
   private void myMethod() { 
   }

   // declaration below is not valid: new public method
   public void myExtendedMethod() { 
   }
}

To be honest, I never designed a long-lasting API, so I am not sure it makes sense at all - but if you make an analogy to Java EE specification and vendor-specific features, it might...

Now, if this new modifier is as orthogonal as final, it could be applied to variables and methods as well. In the case of a variable, it means its value must be defined at least once, and at most twice (and not exactly once, as it happens with final). I can see at least two situations where this is helpful:

1.When there is an optional assignment for an nonexistent value . Example:


semifinal MyObject o = getMyObject();
if ( o == null ) {
  o = new MyObject();
}
// from this point on, o is final and cannot be changed

Without semifinal, you have to either create a temporary reference:


final MyObject tmpObject = getMyObject(); // dirty hack
final MyObject o = tmpObject != null ? tmpObject : new MyObject();

Or not use final at all:


MyObject o = getMyObject();
if ( o == null ) {
  o = new MyObject();
}
// o can be changed, as it is not final

2.Before try/catch blocks:


semifinal MyObject o = null;
try {
   o = getMyObject(); // getMyObject() throws NastyException, which is checked
   // from this point on, o is final and cannot be changed
} catch( NastyException e ) {
  throw new NastyRuntimeException( "o is a nasty reference. No dessert for it!", e ); 
}
// we must use o from this point on, but it should not be changed

Again, without semifinal, we have to use the dirty hack or not use final at all:


MyObject tmpObject = null;
try {
   tmpObject = getMyObject(); // getMyObject() throws NastyException, which is checked
   // from this point on, o is final and cannot be changed
} catch( NastyException e ) {
  throw new NastyRuntimeException( "o is a nasty reference. No dessert for it!", e ); 
}
final MyObject o = tmpObject;


MyObject o = null;
try {
   o = getMyObject(); // getMyObject() throws NastyException, which is checked
   // from this point on, o is final and cannot be changed
} catch( NastyException e ) {
  throw new NastyRuntimeException( "o is a nasty reference. No desert for it!", e ); 
}
// we must use o from this point on, but it can be changed as it is not final

The final (no pun intended) case is the method definition: a semifinal method means it can be overriden, but at most by the direct subclass (i.e., it cannot be overriden more than once). To be honest, that's the less useful of the three situations (I mean, assuming the other two are any useful at all :-), but it would allow some interesting (not to say weird) possibilities, like this:


protected abstract semifinal void doIt();

Such definition means the method doIt() must be overridden by the subclass (as it is abstract), but is final after that (i.e., it cannot be overridden by a subclass of the subclass). It *might* be useful when implementing the Template Design Pattern, for instance.

Anyway, useful or not, that's just one idea I had in a 10-minutes car ride. I have no plans (neither time :-) to implement it, and it might not be as simple as it is described above - there are probably many corner cases to consider (like inner classes and generics), decisions to be made (for instance, it is clear that a subclass of a semifinal class must be defined as semifinal or final; but what about an overridden semifinal method?) and this is not just compiler fun (it might be in the case case of variables, but for methods and classes, that information must be somehow stored in the byteclass). But if someone has the nerves to give it a try, please let me know...

Hello, McFly?

Posted by felipeal on February 12, 2007 at 03:26 PM | Permalink | Comments (1)

I have this blog for a long time - in fact, I think I was one of the first 100 or so weblogers, as I joined it shortly after JavaOne 2003. Still, I haven't blogged that much (just 22 entries in 41 months), specially last year (only 4 semi-crappy posts).

There are many reasons for this inactivity, but I guess the main one is lack of time, aggravated by lack of interest. But the good new is, this year I am in an overall better mood, so I write more frequently. At least, I will try to write about some topics I've been queuing over the months, such as:

suggestion for a new (useless :-) Java keyword
an useful Mozilla/Linux tip
rants about Ubuntu
JUnitFactory and its possibilities
nice-to-have Google features
Java EE productivity
Netbean issues
Eclipse improvements
cool Eclipse tips
Cactus and DbUnit 'state of union'
useful annotations usage
JCP, OSS and personal expectations
... and so on

Of course, the fulfilment of this promise is subject to the conditions of time, mood, and good will - most likely I will procrastinate it, but I will try my best to write about at least the first 4 or 5 items....

Powered by
Movable Type 3.01D

java.net RSS Feeds