This content has been marked as final. Show 3 replies
I have had success in simply deleting classes from the rt.jar file. My application didn't use any AWT or Swing classes so I started there. Keep intermediate copies so you can back up when you delete too much. I found strange dependency issues with the SUN stuff, which required me to keep stuff I didn't need. I had even better success with trimming classes from GNUClasspath.
I also had success with determining what to delete programatically. Using BCEL (or other API for reading classfiles) you can inspect the constantpool for all Class_Info structures, and build a table of classes your application uses. You will need to inspect all referenced classes as well. Then you can delete everything that is not in your list. If you load any classes using Class.forName then you will have to find them another way (they are Strings in the constantpool not Class_info structures). Generally these are few enough that you can keep track of them manually. A number of the embedded java platforms do exactly this with the linker tool the manufacturer provides. Instead of deleting classes from the rt.jar they create an application specific jar file by copying your application and just the classes it needs need.
thanks for your explications :D
My application don't use swinf or awt so I tried to delete it :
I don't understand why I need java/awt/Graphics !!!! :(
Exception in thread "main" java.lang.NoClassDefFoundError: java/awt/Graphics at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.<clinit>(RuntimeBuiltinLeafInfoImpl.java:172) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.<init>(RuntimeTypeInfoSetImpl.java:25) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:78) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:41) at com.sun.xml.bind.v2.model.impl.ModelBuilder.<init>(ModelBuilder.java:97) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.<init>(RuntimeModelBuilder.java:44) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:320) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:198) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210) at javax.xml.bind.ContextFinder.find(ContextFinder.java:368) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:561) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:508) at com.myapplication.commun.config.AbstractConfigManager.loadConfig(Unknown Source) at com.myapplication.config.ConfigGwSystManager.<init>(Unknown Source) at com.myapplication.config.ConfigGwSystManager.getInstance(Unknown Source) at com.myapplication.start.GatewayMain.init(Unknown Source) at com.myapplication.start.GatewayMain.main(Unknown Source)
because of jaxb ?
I would like to know if there is some software who can analyse your code to determine all classes you will load at the runtime.
thanks again for your help !
I don't understand why I need java/awt/Graphics !!!! :(yeah. I found some really odd dependencies that I couldn't explain (or at least didn't seem to me like they should be there). Thats why I switched to GNUClasspath, there were fewer.
I would like to know if there is some software who can analyse your code to determineI didn't find anything, but that was 4 years ago. I wrote my own, but I'm not in a position to distribute it. I did just find these three:
all classes you will load at the runtime
I don't know if any will do exactly what you need. But it might be quicker to modify one of these that to write your own.