Violating Java's privacy

Posted by F Tue, 20 Feb 2007 03:49:00 GMT

I found myself in the need to invoke a private method of a Java class that was out of my control. I really needed it.

So, I went ahead and violated the method’s privacy declaration via reflection. You can (under certain circumstances) invoke methods which are declared as private using the Reflection APIs (java.lang.reflect).

But before using reflection, I created two classes:

class A {
  public String method1() {
    return "Hello World!";
  }
}

class B {
  public static void main(String[] args) {
    A a = new A();
    System.out.println(a.method1());
  }
}

They compiled, and java B said “Hello World!” as expected.

Then, I made A’s method private and recompiled A. And I run java B again. Nothing changed. It just worked again.

That cannot be right. This would mean you can handcraft a class with the same name and methods as the original one but making everything public. Then you could use this class only at compilation time, allowing your code to call any method. (Or, one could modify the Java compiler to ignore access declarations altogether).

Read more...

Posted in ,  | no comments | no trackbacks

I'm sold to Beryl

Posted by F Thu, 01 Feb 2007 00:27:00 GMT

I’ve been trying Beryl (a 3D Window Manager for X) and I’m pretty impressed.

True, it’s full of useless graphical effects and pure eye-candy. But it also provides practical features and is very configurable.

Among the actually useful things: fast and practical ways to change windows, desktops, to expose the desktop area, scale and pick a window (ala Mac OS X’s “exposé”), visual notifications, desktop zoom, screen annotations.

Unfortunately, most demo videos concentrate on the graphical effects instead of the useful features, but they still give you an idea of what it can do.

I really like the idea of using a “water-ripple” effect as an unobtrusive -but impossible to miss- way of receiving notifications.

It integrates nicely with KDE, Gnome and pretty much any desktop environment. And you can easily switch back to your previous window manager at any time on-the-fly.

I have it running on my work laptop, with Fedora 6, KDE and AIGLX.

Very nice.

Posted in  | no comments | no trackbacks

History and auto-completion with rlwrap

Posted by F Fri, 19 Jan 2007 04:06:00 GMT

If you ever used Oracle’s sqlplus you’d agree that it provides an arcane command-line interface.

Being a textmode command-line tool is not what makes it arcane though. It’s that it doesn’t offer auto-completion or a command history. If you made a small mistake when typing a long statement, you would have to re-enter it all over again.

Most modern command-line tools (including MySQL and PostgreSQL’s equivalent to Oracle’s sqlplus) provide much more powerful interfaces, just like the bash shell does. They include auto-completion of the text you are typing (by pressing TAB), access to a history of commands (up/down arrows, or C-p/C-n), incremental search on the history (C-r), they remember the history in between invocations and more. Virtually all these tools use the GNU readline library to provide these capabilities.

Unfortunately, not all command-line tools use GNU readline (splplus being one). Fortunately, there’s rlwrap. I just came to know this nice little tool.

rlwrap “wraps” any other command-line tool and gives you a readline interface to it. So, you can invoke rlwrap sqlplus and you get sqlplus with the history capabilities of the readline library.

You may also pass to rlwrap a list of potential words to use for completion. For example, I also use rlwrap with groovysh (the Groovy language shell), so I created a file “~/.groovysh_completions” containing the list of commands groovysh accepts. Now, when I launch groovysh I get command history and specialized auto-completion.

Now, rlwrap cannot do magic. Being so generic, it cannot do intelligent context-dependent auto-completion. For instance, PostgreSQL’s command-line interface automatically pulls the list of potential table names after doing SELECT * FROM <TAB>. rlwrap cannot give this intelligence to sqlplus, but it’s still much better than nothing.

Posted in ,  | 1 comment | no trackbacks

On API Design Guidelines

Posted by F Mon, 20 Nov 2006 03:31:00 GMT

Update: Good news! Jaroslav Toulash emailed me that he published a book on Practical API Design !!!

Looks like Brian McAllister may be preparing a talk on Designing Elegant APIs.

I've been very interested in good API design for a long time. But I could never find a single book on the subject. Many design and programming books provide good advice and guidelines that are essential for designing good APIs, but none of them tackles the matter directly.

I reviewed "Interface Oriented Programming" a few months back with disappointment. It may not be a bad book, but I felt it was quite basic and superficial. May be my expectations were too high, and too focused on API design.

Over time, I collected some links on the subject and shared some with Brian:

So, let's hope Brian gives his talk at a big conference, signs a contract with a big publisher and fills the void.

Posted in ,  | 1 comment | no trackbacks

Variable Severity Logging

Posted by F Sun, 24 Sep 2006 23:21:00 GMT

Most software products and logging frameworks produce entries in their log files with different severity levels (say, from Debug to Severe). Then, you can configure which level of messages you want the application to log.

At development time, you may want all messages to be logged. But once in production, you normally configure things so that only Warning and higher messages get logged (for performance, space and other reasons).

The problem is that when a Severe message arises you may need more detailed (Debug level) information in order to understand the actual cause of the problem. So, a common practice is to increase the logging level at that point, and wait for the problem to happen again –not very effective.

This is one of the problems that motivated the guys behind LogBag. The idea they propose is nice and simple:

Make the system write only Warning (and higher) messages to the log, but when such a message is logged, it should also include some lower-severity messages that occurred right before and after this one.

It’s one of those good ideas that might seem obvious, but for some reason nobody thought (or did anything) about before.

To implement this, the logging system could keep a buffer of the last N messages generated by the application, and when a Warning (or above) message comes in, the whole buffer is flushed to disk. This should not be too hard to implement, since most logging frameworks already use some kind of buffering, in a producer-consumer pattern, to improve concurrency and performance.

From the LogBag site:

You keep on putting things in a Log bag. Then whether the entire log bag gets written or not depends on the highest severity level in the entire bag. So either you write everything or you write nothing.

I think it’s a nice idea. I bet the technical support guys would like it too :-).

Posted in ,  | 1 comment | no trackbacks

Older posts: 1 2 3 4 ... 6