I like it too. Aubrey's work on graphic design for the web site and even on LimeWire client's look and feel is appreciated. She's probably very busy because we waited for that work since long.
Thanks also to Sam for working on the script to refresh the translation status page, and more generally to the LimeWire team to make limewire.org live again after the migration of servers and tools.
Gregorio Roper should be the next one, in my opinion. I think this is the opinion of other LimeWire crew members.
I don't know. I've been busy and not connected very often on the Internet since last June. May be I'll have more time in the next weeks. For now I just review some code and test it, but I have not developed serious things on LimeWire since 4 months.
I don't know. I just informed them about this code (on http://www.rodage.org/pub/java/security/) as well as Sun. This was also used by Sun because it revealed a bug in the HotSpot compiler of the Java Server VM (this bug normally does not affect LimeWire as it uses the Client VM), as well as some other performance issues. I've received various responses from Sun about it. For now, Sun will not change its implementation, as it is busy working on the 1.5 release coming soon, and its feature list is now closed. Sun is also working on porting and checking its core library to support generic types (a concept similar to C++ template types), and there are still some compiler quirks to solve with the new language definition and reference implementation. Also Apple is still finalizing its port of Java 1.4.2. Other JCE rity providers have received a copy of my version. They will do what they want with this code. But my search on this subject helped me to reveal how HotSpot works and where performance bottlenecks appear (these areas are not covered in the Java Language specification, and not even in the Java VM specification). I have tested this code with other VMs and it's interesting to see that my optimizations benefit to all of them, even if their implementation is very different, or they work with distinct platforms/processors.

I have discovered when working on this code that the Java VM HotSpot compiler uses internal fixed-size static structures to compile the Java Bytecode, and that this has a great impact on performance due to arbitrary limits that are documented nowhere in the Java language and VM specifications. This is certainly a place for improvement in future VM versions (I consider that these arbitrary limits are a bug, Sun considers this is rather a RFE, even if my code also solves a few possibly critical security issues in multithreaded environments; anyway, my code is now included in the Sun Java VM regression tests used by its developers, as the current limits in HotSpot are not coherent between phases C1 and C2 of this runtime compiler).

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml