Re: [Rxtx] Implementing javax.comm for free software javaimplementations(Was: Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
On Mon, 14 Jul 2003, Dalibor Topic wrote: > Hi Trent, > > Trent Jarvi wrote: > > > We'd be more than willing to work with Classpath and or Kaffe to get this > > working. RXTX 2.1 implements CommAPI from the top down but is in package > > gnu.io to avoid confusion with Sun's impementation. > > > > RXTX 2.0 implements the lower portion of CommAPI and could be made to work > > with the upper portion offered in Kaffe. The Kaffe shell classes did look > > acceptable when I read through them. > > Could we implement the javax.comm shell classes on top of RXTX 2.1 > gnu.io API? I.e. would it be enough to just delegate method calls to > gnu.io. for a basic javax.comm implementation? Hi Dalibor That would be one possiblity. Another option would be to keep a diff which simply converts RXTX 2.1 into javax.comm. There are even scripts floating around which do that. -- Trent Jarvi ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Rxtx] Implementing javax.comm for free software javaimplementations(Was: Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
Hi Trent, Trent Jarvi wrote: We'd be more than willing to work with Classpath and or Kaffe to get this working. RXTX 2.1 implements CommAPI from the top down but is in package gnu.io to avoid confusion with Sun's impementation. RXTX 2.0 implements the lower portion of CommAPI and could be made to work with the upper portion offered in Kaffe. The Kaffe shell classes did look acceptable when I read through them. Could we implement the javax.comm shell classes on top of RXTX 2.1 gnu.io API? I.e. would it be enough to just delegate method calls to gnu.io. for a basic javax.comm implementation? cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Rxtx] Implementing javax.comm for free software javaimplementations(Was: Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
On Mon, 14 Jul 2003, Dalibor Topic wrote: > Hi Chris, > > I've CC:ed Trent Jarvi, the maintainer of rxtx, see http://www.rxtx.org > for more information about it. > > Chris Gray wrote: > > On Monday 14 July 2003 00:11, Mark Wielaard wrote: > > > > > >>- javax.comm stuff > >> - Kaffe has incomplete stubs > >> - There is the rxtx (sp?) project which has been usable. > >>(Check kaffe mailinglist archives) > >>They have ported to lots of platforms > >> - Wonka also has a implementation... (Status?) > > > > > > Wonka implementation status: > > [+] works, tested in a number of real-life situations. Uses async i/o on > > Linux. > > [-] ugly as hell: hard-coded data structures for 4 serial ports, giant > > switch statements, etc. Uses Wonka Native Interface (WNI), would need porting > > to JNI (but this is not hard). > > > > For a project I'm working on currently it could be interesting to either > > convert the current Wonka implementation to JNI or switch to rxtx. Has anyone > > out there anyhing good or bad to say about rxtx? > > For kaffe it would be nice to use rxtx, since > > * we had it nicely running under kaffe > http://www.kaffe.org/pipermail/kaffe/2003-April/029251.html > > * it is supposed to be quite portable > > The following OS's should have full Serial Commapi Serial Support: > > mingw32 (windows 9* NT*) (no printer support) > WinCE (no printer support) > Solaris 2.x (*-*-solaris2*) x86 and sparc > Linux ELF (*-*-linux*, except aout, coff, and oldld) > FreeBSD 3.x 4.x (*-*-freebsd2*, *-*-freebsd3*) > Mac OS X > HP-UX 10.x (*-*-hpux10*) > SCO OpenServer 5.x (*-*-sco3.2v5*) (there may be recent breakage) > UnixWare > Digital/UNIX > > * it appears to be in widespread use in different projects. > > * it can be 'plugged in' into Sun's javax.comm implementation. > > On the negative side: > * it needs someone to write the java part of javax.comm (which wonka > already has working, kaffe has a GPLd implementation of unknown quality). > > * We don't have anyone from rxtx on Classpath's or Kaffe's mailing > lists, so there is a communication gap. > There should also be minimal support for printer ports on w32 also. We'd be more than willing to work with Classpath and or Kaffe to get this working. RXTX 2.1 implements CommAPI from the top down but is in package gnu.io to avoid confusion with Sun's impementation. RXTX 2.0 implements the lower portion of CommAPI and could be made to work with the upper portion offered in Kaffe. The Kaffe shell classes did look acceptable when I read through them. -- Trent Jarvi ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Notes on kaffe (GNU Classpath integration) todo items
Tom Tromey <[EMAIL PROTECTED]> writes: > Mark> - Security/Crypto - Choose default provider > Mark> (kaffe, GNU Classpath and/or GNU Crypto). > > For libgcj we've settled on recommending GNU Crypto as the choice (we > don't ship it by default). GNU Crypto is actively maintained by > friendly people -- big pluses. I should mention here that GNU Classpath also has settled upon recommending GNU Crypto. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Implementing javax.comm for free software java implementations (Was:Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
Hi Chris, I've CC:ed Trent Jarvi, the maintainer of rxtx, see http://www.rxtx.org for more information about it. Chris Gray wrote: On Monday 14 July 2003 00:11, Mark Wielaard wrote: - javax.comm stuff - Kaffe has incomplete stubs - There is the rxtx (sp?) project which has been usable. (Check kaffe mailinglist archives) They have ported to lots of platforms - Wonka also has a implementation... (Status?) Wonka implementation status: [+] works, tested in a number of real-life situations. Uses async i/o on Linux. [-] ugly as hell: hard-coded data structures for 4 serial ports, giant switch statements, etc. Uses Wonka Native Interface (WNI), would need porting to JNI (but this is not hard). For a project I'm working on currently it could be interesting to either convert the current Wonka implementation to JNI or switch to rxtx. Has anyone out there anyhing good or bad to say about rxtx? For kaffe it would be nice to use rxtx, since * we had it nicely running under kaffe http://www.kaffe.org/pipermail/kaffe/2003-April/029251.html * it is supposed to be quite portable The following OS's should have full Serial Commapi Serial Support: mingw32 (windows 9* NT*) (no printer support) WinCE (no printer support) Solaris 2.x (*-*-solaris2*) x86 and sparc Linux ELF (*-*-linux*, except aout, coff, and oldld) FreeBSD 3.x 4.x (*-*-freebsd2*, *-*-freebsd3*) Mac OS X HP-UX 10.x (*-*-hpux10*) SCO OpenServer 5.x (*-*-sco3.2v5*) (there may be recent breakage) UnixWare Digital/UNIX * it appears to be in widespread use in different projects. * it can be 'plugged in' into Sun's javax.comm implementation. On the negative side: * it needs someone to write the java part of javax.comm (which wonka already has working, kaffe has a GPLd implementation of unknown quality). * We don't have anyone from rxtx on Classpath's or Kaffe's mailing lists, so there is a communication gap. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items
On Monday 14 July 2003 00:11, Mark Wielaard wrote: > - javax.comm stuff > - Kaffe has incomplete stubs > - There is the rxtx (sp?) project which has been usable. > (Check kaffe mailinglist archives) > They have ported to lots of platforms > - Wonka also has a implementation... (Status?) Wonka implementation status: [+] works, tested in a number of real-life situations. Uses async i/o on Linux. [-] ugly as hell: hard-coded data structures for 4 serial ports, giant switch statements, etc. Uses Wonka Native Interface (WNI), would need porting to JNI (but this is not hard). For a project I'm working on currently it could be interesting to either convert the current Wonka implementation to JNI or switch to rxtx. Has anyone out there anyhing good or bad to say about rxtx? -- Chris Gray/k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Notes on kaffe (GNU Classpath integration) todo items
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> - java.util.zip Mark> How to modularize to allow multiple implementations to coexist? Mark> (See what classes are different between classpath/gcj) Here's a handy URL: http://gcc.gnu.org/java/libgcj-classpath-compare.html Note that the java.util.zip diffs will show up with the wrong mime-type, due to a server configuration oddity :-(. You should still be able to get them with wget though. Any zip classes listed as missing from libgcj are part of the pure-java zip implementation. Last time I looked there was at least one correctness bug in classpath here -- a constant had the wrong (byte-swapped) value. Mark> - Classpath seems to have all the proper Permission checks in place. Mark> (But has anybody every really used it? Probably not, because Mark> AccessController isn't really implemented.) As far as I know nobody has ever tried this. I'm certain they haven't with libgcj. I suspect not with any other VM, since I've never seen a bug report about it; the few security-related patches I've seen could plausibly have been found by inspection (e.g., misspelling somewhere). Mark> - Security/Crypto - Choose default provider Mark> (kaffe, GNU Classpath and/or GNU Crypto). For libgcj we've settled on recommending GNU Crypto as the choice (we don't ship it by default). GNU Crypto is actively maintained by friendly people -- big pluses. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Notes on kaffe (GNU Classpath integration) todo items
Hi,
Dalibor Topic from the Kaffe OpenVM project and me saw each other last
week when we went to the Libre Software Meeting. Attached are the (very
raw) notes I made on what things could be imported from GNU Classpath
into the kaffe library (and some other random notes). They might also be
interesting to the GNU Classpath hackers to see where/how the code ends
up in another free software project.
Cheers,
Mark
Notes LSM meeting, Friday Jul 11, 2003 (Dalibor Topic, Mark Wielaard)
=== Things that could be imported from GNU Classpath into kaffe ===
- Complete GNU Classpath Collection import.
Importing AbstractMap makes some mauve tests fail.
-> Goal to run japitools.
-> And import even more classpath classes that depend on collection stuff.
- java.util.zip
How to modularize to allow multiple implementations to coexist?
(See what classes are different between classpath/gcj)
Deflater/Inflater...
Dalibor has still some outstanding bug reports against Classpath
java.util.zip.
-> Goal automatically use pure java implementation if zlib isn't
available. (This is currently already done for the BigInteger
class, kaffe has a native implementation, but falls back to the
non-native GNU Classpath version if the gmp library is not installed.)
- Serialization ObjectIn/OutputStreams.
Completely different implementations kaffe/GNU Classpath
Some Mauve failures with Classpath/gcj code.
Some other/same failures with current kaffe code.
See also Eclipse startup stream failures.
-> Goal Jython installer to run.
-> Eclipse installer without ObjectStream failures
- StackTraceElement stuff ("pure java Throwable"). Mark has some
code hacked up. It compiles... but crashes in spectacular ways.
-> Goal log4j (used by either JBOSS or Tomcat) uses XMLized stacktraces
from StackTraceElements.
- Verifier and security manager checks
- Classpath seems to have all the proper Permission checks in place.
(But has anybody every really used it? Probably not, because
AccessController isn't really implemented.)
- Jar verification/certification handling isn't implemented.
(Neither in Classpath or Kaffe.)
- Policyfile processor (What to use for it?)
-> Goal savely run applets with appletviewer.
- NIO
- Only java part in Classpath.
- gcj has some native (CNI) implementations (not complete)
but JNI is completely stubs at the moment.
- Talk to Michael Koch. Mark bought a book on NIO stuff and will
probably look at it soon.
-> Goal run Freenet!
=== Some random other stuff ===
- Security/Crypto - Choose default provider
(kaffe, GNU Classpath and/or GNU Crypto).
- FAQ combining kaffe and GNU Crypto
(provides javax.crypto and much more algorithms)
- Make gjdoc the default tool to generate API doc.
- Problem, only really available in CVS, not current packaged version.
- javax.comm stuff
- Kaffe has incomplete stubs
- There is the rxtx (sp?) project which has been usable.
(Check kaffe mailinglist archives)
They have ported to lots of platforms
- Wonka also has a implementation... (Status?)
- Swing (text)
- Claspath has some implemented stuff, but large parts are just stubs.
- Start simple with javax.swing.text.html parser stuff.
Some could get going with gnu jaxp giving it correct DTDs
(Dalibor his crazy idea).
Look at JTidy/HTMLTidy.
-> Goal make Appletviewer really parse parse.
- Bugs that poped up when Mark showed various things on his laptop.
- -Xmx doesn't work (off by one bug), workaround use -mx.
Dalibor quickly hacked up a patch, but the current command line parsing
is broken...
- gmp replacement configuration is broken when both tests fail.
- tritonus install goes bad...___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
