Well, we’ll end up with having two aspects – one for <1.5 and >=1.5. This sucks….

• package protected – Scope that indicates that an instance variable is visible to other classes within its same package, or to subclasses of the class containing the instance variable. This scope is the default scope in Java, and is indicated by no scope indicator.
• private – Scope indicator that hides an instance variable from all other classes, regardless of their package or their class hierarchy relationship to the class containing the variable.
• protected – Scope indicator that makes an instance variable visible to subclasses that inherit from the class containing the instance variable.
• public – Scope indicator that makes an instance variable visible to any class, regardless of package or class hierarchy relationship to the class containing the instance variable.

“Beware of using regular source lists with this; javac may prune unchanged files, which excludes them from the compile process for ajc, which requires that all files affected by any aspects be listed explicitly.”

I haven’t tried it yet, but it looks like a nice thing to know.

Anyway, it looks like a nice technology for developing servlets.

public static void someStaticMethod() 
{
    System.out.println("I'm in " + new CurrentClassGetter().getClassName() 
        + " class");
}

public static class CurrentClassGetter extends SecurityManager 
{
    public String getClassName() 
    {
        return getClassContext()[1].getName();
    }
}

}

Correction – Java sucks LESS It’s not so well documented though…

I have a fully functional non-blocking IO for Java 1.4. It is multithreaded and it works great. What I tried first:

SOLUTION1

InputStream in = System.in;

while(wantToContinue) {

while (in.available() == 0) { try {Thread.sleep(sometime); } catch(InterrputerException ioe) {}; }

int bytesRead = in.read(buffer);

}

PROBLEM1 available() doesn’t report any data on end of file (which is reported by non-blocking read() returning -1), so there’s no way to detect this state.

SOLUTION2 Ok, what if we do the blocking I/O in a separate thread and simulate non-blocking I/O to the main thead (a simple producer-consumer programming exercise).

PROBLEM2 Once, a thread is stuck in a blocking read(), there’s NO WAY to terminate it. Closing the stream, interrupting or even terminating the thread has no effect whatsoever.

(PARTIAL) SOLUTION 2 The same as solution2, but assuming that we want to terminate the thread at the end of application, we can simply cat System.exit() in a finally{} statement.

Ugly like hell, but for our limited purposes, it works.

CONCLUSION Java is a nice programming language, but it’s of limited use for writing a simple Unix-like tools processing streams asynchronously (pipes, reading from stdin, etc.). java.nio (NEW I/O) doesn’t help here at all.

IMPROVED AND WORKING SOLUTION: Use Channels, but unstead of converting System.in to Channel, we use FileChannel fc = new FileInputStream(FileDescriptor.in).getChannel(); ByteBuffer b = ByteBuffer.wrap(tmpBuffer);

Now synchronous calls to FileChannes CAN be interrupted. BTW: it’s still not selectable though, which means we have to use another (ternimable this time) thread to do non-blocking ops.