Jon Brisbin wrote:
I used Java 1.5 generics in places, though those sections could
probably be back-ported.
Do generic just get compiled out? If so, then the real issue would just
be targeting the bytecode to 1.3. If not, then yes.
JLine uses stty on POSIX and a native Win method to get unbuffered
input. I'm guessing using the Bundle-NativeCode manifest header of
"/jline/jline.dll" will work. I'm a Mac user and don't get within 6
miles of a PC, so I'm not much help there. :)
Yes, we would have to try to do this. Because the web page says that
JLine tries to dynamically extract the DLL and put it into a temporary
place where it can load it from, but this wouldn't work well under OSGi.
JLine has an UnsupportedTerminal type, which it returns if it's not
POSIX or Windows. A simple check for this could default it to a
System.in read like in the TUI. The command completion relies on
JLine, though.
If it can fallback to the simple approach for unsupported platforms,
then that would be reasonable.
This doesn't come without cost, though. Currently, shell.tui.jar is
about 12k. If I remember correctly, the JLine JAR is around 80k. So,
this is a substantial increase in size, although small in general by
today's standards on the desktop.
I guess the question is, do people think it would be worth it?
Of course, there is also another possibility, which is to not to merge
it, but create a separate shell UI bundle.
-> richard
I have to say...the completion and history support makes one just flat
productive. :)
Thanks!
Jon Brisbin
http://jbrisbin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
