Its regarding the two methods used to get the resources. I use it through applets. 1. getSystemResourceAsStream(s) 2. getResourceAsStream(s) where s is a string and refers to a properties file.
I make a main class, and use getSystemResourceAsStream as shown in the below code :
Well, the above code works perfectly fine with main method, but as soon as I keep it in the init method of an applet, It doesn't work. the method returns null into obj. Now if I use the other method - getClass().getClassLoader().getResourceAsStream(s); it runs perfectly, even in the applet. I am not able to understand the difference between the both.
I know you would be really busy. But please, make me understand this.
You're hitting one of the security restrictions that is enforced by the sandbox in which applets run. The clue is in the javadocs of the getSystemResourceAsStream method which states "This method locates the resource through the system class loader (see getSystemClassLoader())." If you follow the link to ClassLoader.getSystemClassLoader you'll see that it throws a SecurityException if a security manager is present (which is the case for applets).
In short, applet client code can't use the system class loader, because that would allow it to access all kinds of system internals. Using the user class loader (which is what getResourceAsStream does) works fine, as you've found out.
(By the way, I've added CODE tags to your post, so that the formatting of the code stays intact. You should do that whenever you post code of any length: UseCodeTags)
well... talking abt the security exception as stated in the doc. I have changed the policy file and given all rights to applet signed by me. moreover, I have also accessed the com ports and file system through applet. That didnt give me any exceptio. Also if it was the problem of the sandbox security, it would rather throw Security exception instead of returning null in obj. Its stated :
Returns: An input stream for reading the resource, or null if the resource could not be found
so as far as I see it, the cause is not security... It has something to do with the classloader. The ClassLoader.getSystemResourceAsStream calls the system classLoader(I may be wrng here... do correct me if so). which searches for the resources in the classpath of the system. where its not found. and if I use that getclass.getclassloader.getresourceasstream, It will use the class loader of the class from which it is called. and hence would search for the resource in directory from whr the class had been found. I may be wrong. actually I am confused by the way class loaders work...
Also note thhis case: I use ClassLoader.getSystemResourceAsStream() and keep the jar in the archive of applet tag. and also I supply it by giving the "-classpath=<myDir>/myjar.jar " parameter as a runtime argument in the jre it is running, It gets it.