Why seal a JAR File or why seal packages with a JAR file?

[Lil_Aziz1]

A friend told me it is good practice to seal JAR files. I asked him why and he didn't know why. Pretty fatuous if you ask me. Anyhow, three questions arise:

1. Is it good practice to seal JAR files?
2. If so, why?
3. When would one seal packages within a JAR file?

I did some reading ( Sealing Packages within a JAR File (The Java™ Tutorials > Deployment > Packaging Programs in JAR Files) )

This is the tutorial's explanation of question #3:

Packages within JAR files can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. You might want to seal a package, for example, to ensure version consistency among the classes in your software.

Isn't the bold text always true? Is it saying that it is possible for some classes of a package can be in a different JAR file? If so, wouldn't one always seal a package then?


This is the tutorial's explanation of question #2:

If you want to guarantee that all classes in a package come from the same code source, use JAR sealing. A sealed JAR specifies that all packages defined by that JAR are sealed unless overridden on a per-package basis.

When will it not be in the same source? Is it talking about a package being in a different JAR file? If someone can explain, I would be grateful.

Finally, is there any other reason why one should seal a JAR file or packages within it? Is it good practice to do so? Thanks in advance!

Best Regards,

Lil_Aziz1

[Webuser]

Study to read PMB, pal :)

[Lil_Aziz1]

What's PMB?

[Norm]

To test if all class in a package must be in the same jar file. Do a test: Create a project with >1 classes and put the class files into different jar files, put the jar files on the classpath and see if java can find them.

[JosAH]

Suppose you have package scope class that contains some 'secret' information so the information also has package scope (other classes in the same package can reach that information but nothing outside the package can see it).

Suppose the information isn't sealed: that allows me to define a public class in the same pacakge as where that information is stored; my class can reach that information. I jar my class in another .jar file (or I don't jar the class at all) and presto: I'm in.

Sealing a package (or the entire .jar file effectively sealing all packages) prohibits that type of peeking. OTOH: not sealing a package (or entire jar file) allows for the addition or modification of functionality.

kind regards,

Jos

[Lil_Aziz1]

Oh I think I got it. Let me try putting what you said in my own words and tell me if it's correct:

So there is a package called "com.test" in a JAR file called "test.jar". The package and the JAR file are not sealed. A mischievous person does the following:

package com.test;

public class Z {
...
}

Then he extracts w/e is in "test.jar" test and makes his own JAR file called "testx.jar" and adds all the files extracted from test.jar and the class Z. Sealing the package "com.test" will prevent him from doing that right? So when someone seals a JAR file, does that prevent him/her from updating the JAR file? (something like this: jar uf com.test Z.class)

Another question: Let's say a JAR file has 1 file, A.class. Class A writes/reads to a file somewhere in the C:\ directory. If the JAR file is sealed, will it let it read/write to that file (without the security manager)?

Last question: Let's say a JAR file (test.jar) has 1 package (test1). If you seal test.jar, is test1 implicitly sealed? What if you seal test1. Is test.jar implicitly sealed then? Thank you very much!

Best Regards,

Aziz Javed

[Lil_Aziz1]

Thought I'd bump because it's been two days.

[Norm]

Is this something that you could write a program to demonstrate?
You are asking will this work, will that work.
If no one has done it, then probably there won't be an answer.
Some one has to write a program, jar it, seal it and test it.
Can you do that?