Import: 6 It is a very interesting topic. I think it is hot Novelty: 6 Although they didn't do any contributions to the RTOS supporting Java, they did compare the systems in their own words. This is the only one among those five papers. Quality: 6 The format is not very formal, but the content is well organized Overall: 7 Mostly based on their personally comparisons. -------- Java is a limited domain of operating systems, and this paper does not provide adequate proof that its methods will be used in modern systems. The paper was rather exhaustive with its details, and did not focus on the broader picture enough, as survey papers should. There were several grammatical errors, and lengthy paragraphs that detract from the points they are trying to make by losing the reader in irrelevant details. Overall, the paper cleaned up nicely at the end and suggested improvements to the JavaOS system. -------- Long paper. Intro would have been more complete with a motivating example of a useful real-time application that would benefit from being portable. Until then, I remain unconvinced. Breaking up the columns on page 5 with the diagram was okay, but the direction of reading should be consistent. Should be upperleft, lowerleft, upperright, lowerright I think. What is the (?) for on page 8? The implementation of the garbage collector for JN is counter- intuitive. Would think that the best approach would be to push unessential work further ahead in time (mentioned by Lampson I think) resulting in more fragmented work. Interesting result. A paragraph should develop one main point. This makes the logical structuring _so_ much easier for the reader. Some paragraphs (like page 2 and 3) are simply too long and are hints that clarity could be an issue. An informal style of writing such as (bottom page 10): "The paper we read on the real-time Java threads..." or on page 12 "While the paper we read..." should be avoided. The written word != the spoken word. You conclude that Java nanokernel is not a true real-time OS.... so why did you present it? (Other then having 4 people in your group.) Could have dropped this system without affecting the paper too much. The overall length of the paper would have been 10 pages instead of 13 and the presented systems would be more representative of OSs that support Java and that are real-time. This paper was ambitious and actually quite focussed. -------- Your comments on the paper. This is public comments that the authors of the papers will see. Provide feedback to improve their paper, etc. An abstract is a must. You mention some of the characteristics of Java that make it attractive, but don't those characteristics make it unattractive too?For instance, pointers are beautiful and professional programmers should know how to use them. You can't pointer hop in Java and that just sucks. Also, don't the runtime checks, dynamic memory allocation for all objects, add significant overhead. And if you're going to run it on an embedded system, you have to squeeze the JVM in there too. That alone could be larger than other apps written in C++. -------- Writing style needs more refinement to improve flow. There seems to be some confusion about the languages used in fast JIT compilers. JavaOS is not a realtime system and does not really fit in the paper and it is unnecessary to explain how Java is object oriented. It might have been better to cover another real-time Java platform. There needs to be some comparison of the approaches beyond just pros and cons. The analysis would benifit with some performance figures. -------- The title of the paper is somewhat confusing since not all the OSes discussed are real-time and not all of them provide real-time Java capabilities. The analysis part is confusing since it doesn't have any noticable structure and it jumps from topic to topic. Statements referring to UNIX operating system being real-time and Java language being a simple programming language suitable for real-time systems are misleading. -------- The paper begins by introducing the purpose of a real-time system. Next, it explains that most real-time systems are C/C++ based and that programming these systems in Java would be much easier. However, most real-time systems do not support Java. This paper continues by citing three real-time systems that do support Java, in one way or another, and another system that is Java-based that would be an excellent candidate for a real-time support upgrade. The first system discussed is the Real-Time Java Thread system which is implemented on top of an RT-Mach microkernel. In this system, Java is extended with a new thread class (RtThread) that is mapped to the RT-Mach kernel-level real-time thread. RT-Mach's mutex locks are also made available to Java programs. The second system discussed is the Java Nanokernel. This is a very lightweight kernel that only implements thread creation and destruction. Everything else required by Java is implemented at a higher level. This system allows Java applications to enable and disable interrupts and scheduling for thread control. It is a soft real-time system because of how the garbage collector runs (needs exclusive heap access). The third system, Joust, is a real-time system that does all its real-time work in the underlying OS layer (Scout OS) and uses Java to process data handled by the real-time threads. Last described is JavaOS, which does not support real-time threads but is fairly portable and so it would be a good candidate for adding real-time threads. The paper wraps up by pointing out that the first three systems are not very portable, and further that JN is not suitable for hard real- time work. I thought this paper was an interesting read -- that means a lot. The explanations of topics are clear. However, I did encounter a few problems. In the introduction, embedded systems are mentioned and then that is pretty much the end of that topic. I do realize that embedded and real-time often go together though. Also, I don't agree that programming in an RTOS is widely understood to be difficult and costly. Perhaps the validation of such a system is difficult and costly. In the analysis section, I didn't agree that JN necessarily didn't live up to its promises. I did not read the citation, however, earlier in the paper it is mentiond that JN is based on a SOFT real- time kernel. I think it does live up to being a soft real-time system. Regarding formatting, citations are done in two separate ways. I like them both, but it should be one way all the way though I think. For the analysis section, the paper made multiple passes through the presented OSes. It would have been easier for me to read if all the information for a given OS was in one place -- or if the analysis section had subsections to describe each topic of analysis. Nit-picky details: In section 3.3 (Joust), that question mark has to go. Also, at the end of section 3.3, do you mean that JIT performs faster when written in C? I also think that the title needs a slight change so that the non real-time JavaOS belongs in the paper. -------- Real-time OS that Support Java This was a very good paper that decribes is detail four OS that support Java applications. Three of them run on real time. The authors first set out to explain the purpose of running real time Java applications and benifits ect. Hard and soft real time are brought as this ties in with the purpose of moddifiying Unix OS to allow real time apps. This is great for industy testing. To support Java apps. reral time Java threads are needed although kind of simular to normal java threads execpt parameters must be set to declare timeing retraints and a constructir that requires parameters for star time, and deadline of the thread. Hence real time threads can run withought interuption(since Java has little time constraints). Of the different OS that support Java JN does not fullfil real time apps. but Joust does. JAVAOS althouth not real time is broken up into layers. The Java booter, microkernel, Java VIrtual manchine all witten in C. This was a great paper the only small thing I felt was the anylsis was repetitive, but in gerneral this was one of the best papers. -------- - Abstract is missing. - There are some presentational mistakes. "is has, ?" - The transitions among the sections is not well-formed. - Some sections are too long, especially sections 3. The reader might lost the point of paper while reading these long sections. - They refer to papers in an unusual way. "While the paper we read on JN was ..." - Some figures would be nice for summarizing the systems. -------- Well written, the only paper to perhaps tackle an original question, rather than just a complete survey. Although the reviews of the separate operating systems are not always clear. Distinctions are made fuzzy in the conclusion and analysis, the writing continues off in another direction.