Nico and Miguel, It appears that any classes in packages in
org.jmol.* are read in full regardless of their access. Even when org.jmol.readers contains a single class that does nothing at all (I mean, totally empty), it is read. If, on the other hand, the desired optional classes are in, say, org.jmoloptions.readers then we are ok. They do not get loaded until needed. For example, I created: org.jmoloptions.readers.XyzReader.class org.jmoloptions.smilesmatcher.PatternMatcher.class and when Jmol loads now, that reader's jar file is only downloaded after caffeine.xyz is opened, and the smiles code is only downloaded after "select substructure()" is issued from the console. So I think I have at least defined the conditions for optional downloading -- optional classes cannot be in org.jmol. Before we act on this, I'd like someone to confirm that this is the defined behavior and that we are not just missing some sort of simple thing that would make any largescale changes unnecessary. If we do need to make changes, I suggest creating something like the following options: org.jmoloptions.jvxl org.jmoloptions.popupmenu org.jmoloptions.quantum org.jmoloptions.readers0 (some subset of readers) org.jmoloptions.readers1 (some subset of readers) org.jmoloptions.readers2 (some subset of readers) org.jmoloptions.shapebio org.jmoloptions.shapespecial org.jmoloptions.smiles Then, as Nico pointed out, we don't need any sort of additional user flags. I think I've done what I can on this until I hear from you two. Bob ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
