oyvind.teig@xxxxxxxxxxxx wrote: > Sun's process is at http://www.rtj.org/ > (You probably knew that already) I had a look at this briefly and have forgotten most. But two things stuck in my mind: *) it relies on a totally separate heap from normal Java. All RT classes derive from a different root than java.lang.Object, i.e. there is a similar but separate inheritance tree. By this means, garbage collection can be put into the programmer's control, but without affecting existing Java (java.lang.Oject derived) semantics. *) there are loads of other issues, but I was struck by the inter-thread channels. These clearly take their origin from the PipedInputStream/PipedOutpuStream i/o stuff. What they are trying to achieve is occam (/CSP) channels. What they actually have is some muddled hybrid in which either end (but not both) is non-blocking, the opposite end being blocking. Yuk! A total mess: Entia non sunt multiplicanda praeter necessitatatem I say! :-) Rick
begin:vcard n:Beton;Richard tel;pager:ICQ: 56840977 tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx tel;fax:01794 833434 tel;work:01794 833458 x-mozilla-html:TRUE url:http://www.beton.freeserve.co.uk/ org:Roke Manor Research Limited;Internet Technology & Networks adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK version:2.1 email;internet:richard.beton@xxxxxxxxxx title:Internet Consultant note;quoted-printable:The information contained in this e-mail is confidential and must =0D=0Anot be passed to any third party without permission. This =0D=0Acommunication is for information only and shall not create =0D=0Aor change any contractual relationship. =0D=0A fn:Rick Beton end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature