When run the jvm in verbose mode it shows files are loading from shared object file as shown below
[Loaded java.lang.Object from shared objects file]
[Loaded java.io.Serializable from shared objects file]
[Loaded java.lang.Comparable from shared objects file]
[Loaded java.lang.CharSequence from shared objects file]
What is this shared objects files? I thought these are files in rt.jar and it's getting loaded from there; but rt.jar is getting opened in long way down
[Loaded java.security.BasicPermissionCollection from shared objects file]
[Opened C:\Program Files\Java\jre6\lib\rt.jar]
[Loaded sun.misc.JavaSecurityProtectionDomainAccess from C:\Program Files\Java\jre6\lib\rt.jar]
[Loaded java.security.ProtectionDomain$2 from C:\Program Files\Java\jre6\lib\rt.jar]
any way after extracting the rt.jar i found it has all the classes which were loaded from shared object file.
This is Class Data Sharing. When running the Sun/Oracle Client HotSpot and sharing enable (either -Xshare:auto which is the default, or -Xshare:on), the classes.jsa file is memory mapped. This file contains a number of classes (listed in the classlist file) in internal representation suitable for the exact configuration of the machine running it. The idea is that the classes can be loaded quickly, getting the the JVM up faster. Soon enough a class not covered will be hit, and rt.jar will need to be opened and classes loaded conventionally as required.
Reference:
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/class-data-sharing.html
Related
I have thinking that release mode does not have .pdb file . Recently I publish .Net core web app using command line and it includes pdb files. This is bit strange for me.
It is confiugrable in project properties as many other aspects of code building (optimization level, enabling/disabling conditional compilation switchers etc.).
In many cases PDB brings you additional information which you would not have without it: line numbers in stack trace (in case of unhandled expception error wroted to the log). There is a long tradition to public pdb with release versions on MS dev platform. Actually you should have a strong reason to do not puplish them (I always do).
I've built a inproc com server dll which I can package as 1 file or many via the build utility py2exe. When I allow all the dependencies to remain external, I have no issues, but bundling as 1 file produces problems.
When the dll is utilized (either registering it or instantiating a com object from it), it immediately loads MSVCR90.DLL from the path c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.DLL no matter what I do, I can't change that. There is no information that I can find (using Dependency Walker) to indicate what is causing that to load. It just happens magically...
Then, later on it loads that dll again via an explicit call to LoadLibraryA("MSVCR90.dll") (part of some py2exe black box?), but this time it does not look into the winsxs manifests / directory. Instead it looks to the system path and/or will respect a dll redirection. That's when the problem occurs. If I set the system path to start with c:\windows\winsxs\x86_microsoft.vc90.crt...\ it will load the exact same dll and be happy - but if ANY other file is utilized - inclusive of a copy of the EXACT same dll - but at a different path - then the whole thing blows up. It can't handle using two different files.
How can I fix this? Ideally, I've love to make the initial magic loading of the dll draw upon a private assembly, but no matter what I do with manifests or .dll.local etc it will not respect that until this second dll loading takes place.
Note that with the non-bundled dll (external dependencies) it always uses the winsxs MSVCR90.DLL.
I can "fix" my failure to use the dll by forcing the system path to load the winsxs copy, but that is pretty useless for a deployable com server!
The reason is that you DLL has a manifest that tells the module loader to search also in the SxS storage.
You have several choices
Build your DLL using static linkage. Not using any of the MFC-DLLs (see project settings)
Don't use a side by side manifest for the DLL and still use the MFC DLLs. But beware you have to ship those DLL with your DLL in the local path (see DLL search sequence docs)
Use a later build of VS. Later versions of VS don't use the SxS storage any more and there are no manifests for those DLLs any more.
For the 2. see this article in code project. There is an update for VS-2008 [here].
2
Build your DLL
Use JDK , I can compile a .java file into a .class file, then I can run the .class file, does this mean that the .class file is the final executable file running on JVM ?
Moreover, what's a jar file ? and the difference between jar file and .class file ?
1. A class file is a byte code files, which is executed by the JVM, it has no meaning outside the JVM. Making it meaningful only on JVM but not outside, is what makes every java program run in its own sandbox .
2. Jar file is a collection of all the class file, libraries necessary to run the program, consider its an easy way to pack all the files and depending library and providing a single file. We also have Runnable Jars which can be known as Executable Jar
////////// EDITED PART//////////////////
Now this byte-code is converted to machine level executable during Run-time by the JIT (Just In Time Compiler). JIT will look for the runtime intensive part of the program during Runtime, and then it will convert it into machine level executable, this part of the program is known as Hot-spot, and the JIT is known as Hot-Spot-Compiler.
A jar (java archive) as its name says is an archive or collection of java classes that are ready to be executed.
A java decompiler is a tool that makes a reverse engineering from .class extension to .java extension.
To make a jar use following link
http://docs.oracle.com/javase/tutorial/deployment/jar/build.html
Or using windows command promt
jar cf JAR_FILE_NAME FILE_NAMES_OR_DIRECTORY_NAME
e.g.
jar cf MyApp1.jar C:\JavaProject\MyApp
I've an desktop application that implements Serializable class, but now I'm translating it to an web app with servlets, I use Netbeans for this work,I have the following code:
InputStream input = ClassLoader.getSystemResourceAsStream(file_input);
Where file_input is an bytecode fyle from an object serialized before, I don't know where I should put this file because in the desktop application I put it in the same dir where I had my classes.
(I have the file, I don't need to create it).
First of all, don't use ClassLoader#getSystemResourceAsStream() in a Java EE web application, ever. Instead, use ClassLoader#getResourceAsStream(). I would also put big question marks around using ClassLoader#getSystemResourceAsStream() in a Java SE desktop application, for sure if it's intended to be distributable, but that aside.
The ClassLoader ultimately loads resources from the classpath. So all you need to do is to make sure that the file is placed in one of the paths which are by default covered by the webapp's runtime classpath, or to add the new path to the file to the webapp's runtime classpath through a server specific configuration setting, such as shared.loader property of Tomcat's /conf/catalina.properties.
One of the default paths covered by the webapp's runtime classpath is the /WEB-INF/classes folder of the WAR. From IDE project's perspective, just drop the file in the root folder of the "Java Source" (src) folder, there where you have all your Java packages and classes. The IDE will take care that it ultimately ends up in /WEB-INF/classes of the built WAR file.
I by the way still assume that you are not creating the file from inside the webapp, as you explicitly told. That wouldn't work. If you actually need to have write access as well, you're going to need an absolute disk file system path instead. You can always make it configureable by providing it as a VM argument or environment variable, for example.
I am talking about win32 dlls, those plain pe files. I am confused after I doing a test compared to what I saw in explorer.exe process.
I wrote a test with following modules:(C++)
DLLLoader.exe links to A.dll in the same folder.
B.dll links to A.dll(2) in another folder. (A.dll(2) is a totally different DLL from A.dll, but with the same name)
DLLLoader.exe will load B.dll explicitly through ::LoadLibrary.
Now I start DllLoader.exe, firstly, A.dll will be loaded, but then when it tries to load B.dll, It just failed: I suspect that is because B.dll thinks A.dll is already loaded in process, but in fact, the loaded one is not the one B.dll wanted, the import/export table can't match, so B.dll is failed to load.
This seems to tell us we can't loaded 2 dlls of same name in the same process, even they are of different path.
But when I used process explorer to monitor loaded modules in Windows's explorer.exe process, I could see following 2 dlls being loaded, with same name:
comctl32.dll User Experience Controls Library C:\WINDOWS\WinSxS...\comctl32.dll
comctl32.dll Common Controls Library C:\WINDOWS\system32\comctl32.dll
Could any of you shed some lights on this?
It basically depens on if you load the dll with its full path or only by file name. The LoadLibraryEx docs cover this pretty well:
If lpFileName does not include a path
and there is more than one loaded
module with the same base name and
extension, the function returns a
handle to the module that was loaded
first.
See http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/b3eaa07f-7f92-4693-8aa1-b8fee0b92d2f/ for a good discussion on how this can be done implicitly for WinXP and up, by activation context (manifests) to control the loading.