Weird Question Regarding JVM and Packages

[Brian Goetz]

It's a complicated question, because you've left out some detail needed 
to answer.

If you are in a non-modular world, yes, JARs are irrelevant to package 
boundaries.  One of the big changes of the Java module system is to 
enforce that modules represent a partitioning of packages (this improves 
both security and performance.)

The missing piece of the story here is class loaders.  A class loader is 
responsible (among other things) for taking a class name (including the 
package name) and finding its classfile bytes.  Different parts of an 
application may use different class loaders to resolve class names.  So 
the question of "will it pick up my weirdly named classfile when someone 
says `new JInternalFrame`" depends on which class loader they ask.  If 
both your library and your application are using the same class loader, 
*and* that class loader's search priority (such as the class path) 
prefers your JAR over the library JAR (such as, yours appears first in 
the class path), then JInternalFrame will resolve to your version.  But 
that's a lot of ifs.

On 4/26/2021 12:05 AM, Sean Carrick wrote:
> Greetings, All!
>
> I have an old project that I maintain, which uses an ancient library.
> The library it uses does an excellent job for the project, but lacks one
> thing: the ability to save session state of JInternalFrame windows. I
> have figured a fix for this, but, I am using a plugin for my IDE that
> relies on the original library. So, let me explain the situation and
> then ask the question...
>
> The library in question provides for application life-cycle and session
> state saving/restoring. It works great for top-level windows, such as
> JFrame and JDialog windows. It also is able to save/restore session
> state for items such as JSplitPane, JTabbedPane, and JTable controls
> within the windows. However, my project uses the JDesktopPane and
> JInternalPane windows, and I have clients asking (practically begging)
> for me to get the project to save the state of the JInternalPanes.
>
> The library that I am using is completely dead: there has not been any
> active maintenance on it in over a decade. The project that is using it
> does not generate enough revenue to justify the work that would be
> involved by moving the project to a newer framework. But, I have figured
> out a solution to my issue, though I do not know if it will work as I
> think it will...
>
> My project has its packages, such as com.mycompany.project, with many
> sub-packages below that. The library has its packages, such as
> com.library.lib. My question involves how the JVM parses out this
> information. The reason I am curious about this is because the solution
> that I discovered involves subclassing one of the old library classes.
> However, that class has package private and private methods that I would
> not be able to reach if I included my subclass within my own package
> structure.
>
> Therefore, I was thinking, "What's in a name?" I got to wondering, if I
> placed my new version of the library class on the root of my source
> tree, mimicking the original library's package structure, would I get
> access to the original class' private methods and members, if I named my
> class the same, but was just adding what is missing from the original class.
>
> For example, if the original library class' absolute classname was
> com.library.lib.SessionStorage, and I recreated that package structure
> on the root of my project source folder: com.library.lib.SessionStorage,
> but only added to it the missing requirements, would the JVM merge them
> at runtime?
>
> To further explain, let's say the original SessionStorage class has all
> of the functionality I need, except for the ability to save the session
> state of the JInternalFrames within my application, would I be able to
> create a class called SessionStorage in a package named the same as the
> original library's and only include the ability to get the session state
> from the JInternalFrames, would this work.
>
> Let's say that the original SessionStorage class contained the following
> methods and classes:
>
>    * public void save(Component root)
>    * private void saveTree(List<Component> roots, Map<String, Object>
>      stateMap)
>    * public void restore(Component root)
>    * private void restoreTree(List<Component> roots, Map<String, Object>
>      stateMap)
>    * public interface Property
>    * public JSplitPaneProperty
>    * public JSplitPaneState
>    * public JTabbedPaneProperty
>    * public JTabbedPaneState
>    * public WindowProperty
>    * public WindowState
>
> Then, let's say that I create the package structure
> 'MyProject/src/com/library/lib/', then create the class
> JInternalSessionState within that package, which contains only the
> following:
>
>    * public JInternalFrameProperty
>    * public JInternalFrameState
>
> Let's go one step further and say that my JInternalSessionState class
> extends SessionState. Would what I believe would be the case actually
> happen?
>
> Would the JVM simply use my class as an overridden version of the
> SessionState class, even though they are in completely different
> projects, because their packages are named the same? For example, would
> I be able to replace the private saveTree and restoreTree methods with
> custom methods that would use the two new classes that I created,
> without the need of overriding the two public methods, save and restore?
>
> I hope that I have explained my thought process well enough for someone
> to give me an answer, even if it is just laughter for thinking way too
> far on this. I appreciate any responses that I may get, and thank you in
> advance.
>
> -SC
>