-
Notifications
You must be signed in to change notification settings - Fork 37
Applet class lists
== Generating class list files ==
In order to make loading of the applet faster, we use the class index system. This means the classes are split in several jars and only one (jchempaint-applet-core.jar) is mentioned in the applet tag. This contains a list where other classes are found. It should have all classes which are needed for loading the viewer. Classes for loading and doing basic tasks should be in jchempaint-applet-editor.jar. How do you know which classes are needed?
-
To write all classes loaded by the ViewerApplet to classes.txt: appletviewer -J-verbose:class ViewerApplet.html > classes.txt
-
To extract only those classes, which are loaded from our .jar files and write them to realclasses.txt cat classes.txt | sed -n -e s'/^[Loaded ([^ ]) from .:/.*$/\1/p' | sed -e s'/.///g' | sed -e s'/$/.class/g' | sort > realclasses.txt
-
Then compare these classes with all the classes in applet-core.files (all these classes are in applet-core.jar): diff realclasses.txt META-INF/applet-core.files | grep class
Normally it should be enough to replace existing applet-core.files with realclasses.
You can check for classes needed by editor in the same way. When using realclasses for applet-editor.files you will get the core classes in again. This should be ok, since during building jars classes added once are not added another time. For the editor classes, we do some basic drawing whilst spooling to classes.txt : click around a bit with the bond tool selected, change some bond orders, and hover/click around with some phantom rings. This ensures that basic editor classes end up in the jar files loaded on applet start.
== Required manual editing ==
Manual steps for post-processing applet-editor.files and applet-core.files.
-
It looks like you need to '''manually''' add the line "io-formats.set" to META-INF/applet-core.files, since this is needed by the ReaderFactory, which is part of applet-core, but not included automatically and is loaded via this.getClass().getClassLoader().getResourceAsStream, which requires the resource to be in the same jar as the ReaderfFactory.
-
Another '''manual''' step after creating file "applet-core.files" needs to be done when JCP Jar files are going to be shrunk with Yguard (a shrinker tool makes the jar files smaller so that the applet can initialize faster). To prevent the CDK AtomTypeFactory from failing, search for "AtomType" in the file "applet-core.files" and remove all lines hit, such as **org/openscience/cdk/atomtype/CDKAtomTypeMatcher.class **org/openscience/cdk/AtomType.class **org/openscience/cdk/atomtype/IAtomTypeMatcher.class **.. and more
-
Open both applet-editor.files and applet-core.files, and remove any reference to org.apache.log4j from them. This makes sure that bare log4j classes get put in a separate apache jar file, and not in the core/editor files where they have to be protected from Yguard. You can test if the log4j mockup works by running the applet and trying to save a structure as CML. It is the xmlcml library that actually demands some basic log4j classes to be around.
Finally there is applet-editor-opts.files. This is handcrafted. I added the following classes which may be used frequently:
- org/openscience/cdk/exception/InvalidSmilesException.class
The same is true about applet-viewer-opts.files:
- org/openscience/jchempaint/JExternalFrame.class