3 Questions

Hi I have three questions which i still dind't figure out and still dind't find out a correct answer..please help me on this.

1 - What are all NFRs we do have ?

2 - IN Java 1.2 are applets still running in a sandbox?

3 - Does the RMI supposed a distributable garbage collector ?

Tks in advance!!!

Originally posted by Felipe Pittella:
Hi I have three questions which i still dind't figure out and still dind't find out a correct answer..please help me on this.

1 - What are all NFRs we do have ?

Tks in advance!!!

NFRs (Non Functional Requirements) are the requirements that are not asked by customers but needed for any successful application like Availability, Reliability, Performance, Maintainability, Manageability, Security etc. Keep in mind, you might not get all in your system, you must trade-off between these depends on application and its requirement.

Hope it helps.

check This

Originally posted by Felipe Pittella:
2 - IN Java 1.2 are applets still running in a sandbox?

Its thru policy and/or trust.

3 - Does the RMI supposed a distributable garbage collector ?

I think its only on RMI-JRMP.
[ December 19, 2007: Message edited by: Abhinav Srivastava ]

Hi Arkur, ok tks so much!!

Gowher , very nice link!!!

Abhinav , dind't understand the response for question 2.

and about the questions three...could anyone else confirm this for us??

Tks in advance folks!! ;-)

I meant to say security is enforced thru java policy and/or digital signatures, and can be customized for evey applet compared to the sandbox model of 1.0 which was equally resrictive on all applets. When both are absent, it would fall into what may be called a sandbox or rather just default restrictions.

http://www.securingjava.com/chapter-three/

When combined with access control, code signing allows applets to step outside the security sandbox gradually. In fact, the entire meaning of sandbox becomes a bit vague. As an example of how Java code signing might work, an applet designed for use in an Intranet setting could be allowed to read and write to a particular company database as long as it was signed by the system administrator. Such a relaxation of the security model is important for developers who have complained about Java's restrictive sandbox. Writing code that works within the tight restrictions of the sandbox is a pain, and the original sandbox is very restrictive.
The addition of code signing to Java complicates things. As it now stands, the Java sandbox has been reduced to a default.

Also check this out -
a-brief-history-of-applet-security
[ December 19, 2007: Message edited by: Abhinav Srivastava ]

Hey Abinhav,

Ah, ok..now I got it --> "sandbox or rather just default restrictions." .

Tks so much!! ;-)