To all you bozos sending me mail saying "get me off this list", I have
nothing to do with subscribership. Try talking to
[EMAIL PROTECTED] or [EMAIL PROTECTED]
>That sounds like the problem... and yes... running rmic in /tmp runs
>a trillion times faster.
Ah, good. I'd still be curious to know why Linux is so much worse than
Solaris with unbuffered NFS writes. Again, my guess is that Solaris is
caching the data a bit in the kernel before doing NFS. I believe this
is officially disallowed (NFS writes are synchronous), but it sure
makes things nicer. Maybe 2.1.x kernels do a better job of this?
>Unfortunately I can not perform all of my compiles in /tmp. Any ideas
>on how to get around this?
This problem convinced me to switch to CVS. I do my development on
local disk, then check the sources in to CVS on my NFS mounted (and
backed up) disk. Not exactly a simple solution, but it was good to use
CVS anyway.
The other option is to write a shell script wrapper around rmic that
writes to /tmp and then copies the output back.. If rmic has a -d option
similar to javac, then it's easy. Just do something like
rmic -d /tmp Foo.java
mv /tmp/RMIFoo.class .
(sorry, I don't know rmic that well. I hope the idea is clear).
Without a -d option you'll have to copy Foo.java to /tmp first.
The only other thing I could think is to reverse engineer rmic, fix it
so that it uses a buffered output stream, and recompile it. That's
probably illegal.
(Bummer about not having source to rmic. Jini is going to be open
source, which is incredibly cool.)
