Maybe I am not understanding this properly but java's
threadlocal storage seems funky. Unlike in other non-java
threading environments one cannot introspect a thread's
local storage and retrieve the objects needed. To retrieve a
thread local value one needs a reference to a ThreadLocal
object which was used to create this TLS. This seems a bit
funky; to retrieve a TLS value at a random point in that
thread I need a reference to a global ThreadLocal object; so
if I have to use a global object to grab TLS values I can
just make my TLS values globals !

The only difference b/w globals and TLS is that the value of
the TLS object can be unique per thread. This is cool but
the inability to introspect a thread's TLS values without
holding a global reference doesn't make sense. This stops me
from using TLS where I am unable to add/modify globals for
some reason (say I am writing callbacks for an established
framework).

I am not a Java person and have less than a week's
experience working with J2EE, maybe my brain is not wired
correctly to understand Java but I have significant
programming experience in multiple languages and I have
never seen such a proliferation of frameworks and abuse of
xml in the name of declarative programming. Most of the
latest Java based frameworks have a large amount of
documentation explaining how they are different from the
other frameworks and how using their framework apparently
makes it easier for the programmer to concentrate on
business logic and forget about the "grunt" work and loose
ends. This clearly seems like a bunch of authors writing a
lot of code to create a fwmk/api based on
an idea which was simply not significantly different from
the previous fmwk to stand on it's own merit.

Also why do most new java fmwks/api's state one of their
goals as "making programming easier" ? Surely the J2EE
programmer is smart enough to know that he should close
files he has opened in his program ? Surely the answer to a
bad programmer is not to create a brand new framework that
closes opened files via code injection and declarative xml
programming. If there is a problem with a existing framework
or an api - maybe everyone should just try fixing it ?

I definitely don't have enough exposure to
understand all
the problems of Java or J2EE and the need for so many
frameworks so you could definitely say I not qualified to
comment on something that I obviously don't understand well
enough. In my defense; neither do I have any significant
experience in say Python, Lisp or Perl but I can already see
that they have got their story right. Maybe after you have
spent enough hours hacking stuff at ungodly hours, you just
develop a sense of what is right and what is not, and Java
and it's framework hell just does not seem right

Just got a shiny new Dell E248WFP monitor. Awesome good.
Hooked up my Macbook Pro to the monitor and everything works
great. Well almost everything. "Mirror mode" forces the
monitor resolution to drop to the macbook's resolution.

I
will get myself a nice USB mouse and keyboard tommw and run
my macbookpro in "clampdown mode". That should make me
happy mmmm..

I recently had to write a server in java that can speak
SSL/TLS. The actual application protocol is handled by
classes upstream to the SSL/TL layer. For scalability I
decided to use Java NIO - which implied using the
javax.net.ssl.SSLEngine.

The SSLEngine api is pretty cool though could possibly be a
bit better designed. Essentially the application needs to
manage 4 buffers of data, 2 of which are read by and 2 of
which are written to by the SSLEngine. Sounds easy, infact
it is, if it were not for the Handshake and renegotiation.
Calling an api on the SSLEngine can cause it to ask you to call
another api which may in turn ask you to call the original
... and so on.

I first wrote the SSL layer using recursion but with upto 5
exit points and special code to take care of stack unwinding
and having to manipulate global buffers this was deemed too
risky. So I re implemented the SSL engine via state
transition. Since I was already playing with NIO and had to
use a thread pool to handle concurrent clients, I decided to
make the SSL processing asynchronous. Essentially I broke
down the SSL processing (including breaking down the
handshake and app layer protocol parsing) into various
states, the currently executing thread would finish
executing 1 state and hand over the "session" to the thread
pool where another free thread will finish the next state.
Ofcourse I have coded in optimization where an
implementation of a state can decide whether to transition
over a thread boundary or force the current thread to
execute the next state.

Long story short. It works andit fits very nicely into the
server's threading model.

Well actually not much of a story. I got my hands on a "Tata
Indicom Plug and Surf thinggy". This is really a Sungil cdma
usb modem using Qualcomm's mobile station modem (MSM)
chipset. Darwin groks the msm chipset alright.

So I plugged in the modem into the USB port, pulled up
"System Preferences", selected "Networking", filled in the
account details - which should be same for all tata
subscribers i.e dial #777, creds are internet/internet. Then
I went to the "Advanced" menu section and changed the
"Vendor" and "Modem" from "Apple" and "Apple Modem v34" to
"Generic" and "Dialup Device". Hitting "Connect" should now
get you online.

So I tried running Leenux on my shiny new dell d620 laptop.
Since my linux skills suck and specifically since the 4th
FC4 CD was fubar, I ditched the whole "put linux on my
laptop" experiment and turned to FreeBSD.

fbsd 6.2 is lovely !. I used the 24 MB "boot" only iso image
to get a install kernel on my box and performed the
ports/packages install over the net. Very nice !

After spending a day configuring stuff I finally have the
following working (or almost working..)

Video @1200x800 - thanks to 915resolution - which was in
"ports" yeah

Sound ! - had to get the snd_hda.ko driver.

Skype !!!! - yeah baby - (linux abi ofcourse :D)

xmms for my lovely mp3's

mplayer for all those pron mpegs.

firefox with flash7 (linux binaries). The flash 9
crashes :( and there are no native flash binaries...