The workshop immediately follows the WoTUG-19 conference at the same venue. Registration for this workshop is limited, free and separate from WoTUG-19; but it is expected that most participants will have attended the latter (which contains at least three papers that are directly relevant). Details of both WoTUG-19 and this workshop are being updated on:
/parallel/groups/wotug/wotug19/
Private enquiries can be emailed to P.H.Welch@ukc.ac.uk. Information about KRoC appears on:
/parallel/occam/projects/occam-for-all/kroc/
14:00 - 15:30: Informal presentations from people already working on KRoC. 15:30 - close: Working tea and discussions. The discussions may be in groups, depending on the number attending. There will be a wind-up plenary session to define future activities.
However, Java compiles to an abstract stack-oriented `ByteCode' which retains information about the type of information being manipulated. Hence, Java ByteCode can also be verified to obey the security rules of the higher-level Java language - and Java ByteCode interpreters/code-generators are obliged to perform such verification before they start interpreting/code-generating. This makes it secure to distribute applications in Java ByteCode over an insecure medium (such as the World Wide Web), so that the receiver may be sure that the incoming code will not damage the local host - if it's been `modified' to do something dangerous, it won't get past the verifier.
It's not possible to compile C/C++ to Java ByteCode (nor to any code with the above security features) - there are too many loopholes. That's why, according to legend, Java was born! As a language that enables secure WWW-distributed applications to be built, Java has arrived in style. No matter how good its language facilities and principles may be, without that WWW angle it is likely that not many would have taken notice of it.
Current `Transputer ByteCode' does not have enough type information to let it play the same security role for distributing applications as Java ByteCode. For the same reason, the KRoC translator (which starts on Transputer ByteCode - not occam) cannot easily generate (typed) Java ByteCode that will pass the Java verifier.
BUT the occam language takes security issues far more seriously than Java and the occam compiler checks that all its security rules are obeyed. It may not be too hard to modify the occam compiler to generate an extended Transputer ByteCode that includes the necessary type information. There would be two interesting benefits from this. One is that KRoC could then target Java ByteCode in a way that would satisfy the Java verifier (and, hence, give occam instant access to an enormous platform base). The second is that Transputer ByteCode could directly play the same role as Java ByteCode as a medium for secure (internet) distribution of applications. The KRoC translator already verifies that its transputer source code is `well-behaved', applying rules that are similar to those used by the Java ByteCode verifier. These rules need extending to ensure that addresses and user-data are always kept apart.
Is the world ready for the (TM) `HotOccam' WWW browser - not to mention the (TM) `occlet'?
occam Re-targeting Workshop II (Nottingham-Trent University: 3rd. April, 1996; 14.00 - 17.30)
Name:
Email:
Tel:
Fax:
Institution: