From: Egon W. <ego...@gm...> - 2009-06-26 10:16:23
|
Hi Stefan, On Fri, Jun 26, 2009 at 11:19 AM, Stefan Kuhn<ste...@eb...> wrote: > On Friday 26 June 2009 08:33:42 Egon Willighagen wrote: >> What are the sizes of these current jars, and what is the content of >> the current core jar? > 412 kb. editor.jar is 65 kb. OK, excellent. So that defines the current minimum set of jars needed. How much is this combined? -rw-r--r-- 1 egonw egonw 440552 2009-04-20 13:39 jchempaint-applet-core.jar -rw-r--r-- 1 egonw egonw 70820 2009-04-20 13:39 jchempaint-applet-editor.jar -rw-r--r-- 1 egonw egonw 1511 2009-04-20 13:39 jchempaint-applet-editor-opts.jar That's 501kB in total, just for the most basic functionality. 10x the size of competing producs. > It might have changed a bit, since I did not redo > the partitioning with every development release, but that should not half or > double the size. Half the size would not even get us close to what I like to see. > If you want to see the content, build/download the application and have a look. These are the files of 10kB and larger: 10475 Mon Apr 20 13:34:58 CEST 2009 org/openscience/cdk/tools/manipulator/ChemModelManipulator.class 10904 Mon Apr 20 13:35:04 CEST 2009 org/openscience/cdk/renderer/generators/BasicBondGenerator.class 12604 Mon Apr 20 13:34:54 CEST 2009 org/openscience/cdk/tools/LoggingTool.class 13634 Mon Apr 20 13:34:58 CEST 2009 org/openscience/cdk/ringsearch/cyclebasis/SimpleCycleBasis.class 13739 Mon Apr 20 13:34:54 CEST 2009 org/openscience/cdk/graph/PathTools.class 14456 Mon Apr 20 13:37:28 CEST 2009 org/openscience/jchempaint/applet/JChemPaintAbstractApplet.class 15041 Mon Apr 20 13:37:28 CEST 2009 org/openscience/jchempaint/RenderPanel.class 15860 Mon Apr 20 13:35:10 CEST 2009 org/openscience/cdk/layout/RingPlacer.class 16584 Mon Apr 20 13:35:04 CEST 2009 org/openscience/cdk/DefaultChemObjectBuilder.class 17756 Mon Apr 20 13:35:04 CEST 2009 org/openscience/cdk/renderer/RendererModel.class 18828 Mon Apr 20 13:35:10 CEST 2009 org/openscience/cdk/layout/AtomPlacer.class 19426 Mon Apr 20 13:35:20 CEST 2009 org/openscience/cdk/smiles/SmilesParser.class 21502 Mon Apr 20 13:35:06 CEST 2009 org/openscience/cdk/io/MDLV2000Reader.class 22529 Mon Apr 20 13:35:02 CEST 2009 org/openscience/cdk/AtomContainer.class 29868 Mon Apr 20 13:34:58 CEST 2009 org/openscience/cdk/geometry/GeometryTools.class 30253 Mon Apr 20 13:39:54 CEST 2009 META-INF/MYKEY.SF 30338 Mon Apr 20 13:39:54 CEST 2009 META-INF/MANIFEST.MF 53831 Mon Apr 20 13:35:14 CEST 2009 org/openscience/cdk/controller/ControllerHub.class If we want to cut down the size of the applet, we have to start working in this area. Interestingly enough, modularizing the ControllerHub seems a promosing start. >> > Only those are loaded, which contain classes needed. >> >> How do you test how many jars are loaded when firing up the applet? >> And how many on normal use? > > I only put core, editor and editor-opts.jar in a directory and make sure the > applet shows up with this directory pointed to in the html. I also checked > the java cache when having the full set, but I did this on windows only, > since I couldn't find it on linux. Is that supposed to work for the 2.5.7 release? I get: java.lang.NoClassDefFoundError: org/openscience/cdk/controller/IChemModelEventRelayHandler at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:637) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) egonw@egonw-laptop:/tmp/jcp-2.5$ jar tvf jchempaint-applet-core.jar | grep IChemModelEventRelayHandler egonw@egonw-laptop:/tmp/jcp-2.5$ jar tvf jchempaint-applet-editor.jar | grep IChemModelEventRelayHandler egonw@egonw-laptop:/tmp/jcp-2.5$ jar tvf jchempaint-applet-editor-opts.jar | grep IChemModelEventRelayHandler <applet code="org.openscience.jchempaint.applet.JChemPaintEditorApplet" archive="jchempaint-applet-core.jar" name="Editor" width="600" height="500"> <param name="load" value="applettests/big.mol"--> <param name="impliciths" value="true"> </applet> <a href="javascript:alert(document.Editor.getMolFile())">show mol file</a> <a href="javascript:alert(document.Editor.getSmiles())">show smiles</a> <a href="javascript:alert(document.Editor.getSmilesChiral())">show stereo smiles</a> <a href="javascript:document.Editor.clear()">clear</a> <a href="javascript:document.Editor.addMolFileWithReplace('\n CDK 1/19/07,10:3\n\n 2 1 0 0 0 0 0 0 0 0999 V2000 \n 252.0000 1022.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0\n 227.0000 1047.0 000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0\n 2 1 1 0 0 0 0 \nM END')">insert CC (as mol file)</a> <a href="javascript:document.Editor.setSmiles('CCC')">insert CCC (as SMILES)</a> And: appletviewer EditorApplet.html (File copied from JChemPaint SVN) >> This matter, because I see no difference between downloading 1MB of a >> single .jar, or 1MB of downloading a set of smaller jars. > > It is the point with the whole concept that only the mentioned jars are loaded > at startup. If all jars would be downloaded, it would be useless, yes. > >> So, the question is, how much is currently being downloaded for a the >> simplest use case Chris is after? > > As I said, drawing can be done with only using the mentioned jars. The applet does not even start for me, see details above. >> > All jars together will contain >> > everything (we could in theory leave out classes never used, but it is >> > hard to find out which are really never used and there is no problem with >> > having unused stuff since it will not be loaded). >> >> This can be done by defining clear dependencies. > > But why do things which serve no purpose? If it can be done, ok, but I see no > pressing need for it. No, you made that pretty clear. I hope I also made it clear that I don't think a 500kB applet is a small applet. <snip> >> If this is the use case, the applet likely be a lot smaller than now. >> State of the art drawing applets doing the above functionality are >> less than 40kB, even open sources ones. If we want to be competitive, >> this has to be our goal. And surely this will be difficult, and surely >> this will require further CDK clean up. > > I think we cannot do this given the applet is a cdk thing. Something like 40 > kb is only possible with a purpose written application, I believe. I'm not religious. Did you even try? Do you have any argument to back up this belief? >> I don't care of the IsotopeFactory is in the first jar loaded, or in >> the third or fifth. I don't want it to be loaded at all. > > As I said and as it clear from the concept, this is of relevance. If the > isotopeFactory is used somewhere, it will be loaded at some point. If it is > never used, it will never be used, although it is part of some jar (we could > make an unused.jar). I think you missed the point I was trying to make. >> > As I said I do not want to discourage anybody from doing something, but >> > be aware of the concept. >> >> The above concept uses indices distributed with the first .jar so that >> your Java browser plugin knows what additional plugins to download >> later. >> >> What this concept does not address, is define what is the smallest set >> of CDK classes we need for a simple drawing scenario applet >> functionality. > > Well, it does, since the contents of the core jars are the minimal set. Yes, and a minimal set currently is 500kB+. I am not settling with that, and I have yet to see arguments why this should not be tried either. > For me, this "small applet thing" sounds like a major exercise. It is. > I wuold suggest we proceed as following: > - Fix bugs (this currently in sf and newly found ones) > - Implement a reasonable set of new features > - Make sure it is stable (this is a major problem with the applets, Angel and > Marcus reported problems which need to be addressed) > - Do the partitioning, make sure the minimal set works, further split up the > residue jar, which is a bit big right now etc. > - Then make a release, which might be 2.6 or 3.0, I don't care > I believe if we want to have the application in use, we need to do > maintainance releases regularly. If we now stop till the grand design is > finished, it will mean the next release is away years. We cannot seriously > expect people to use such an application, I believe. No, Stefan; this is not going to work. Please fork or what ever. Your above plan is not good, which I tried to explain for a couple of times now. > Since a small applet might be good as well, we could also do a maintainance > branch and a small-applet branch. I would favor this given the current situation. If there was not this strong urge by some developers to put in all the functionality the old applet had, but focus on basic functionality, you could have finished the applet already. Your above plan sounds nice, but has zero novel ideas and is what you have been trying for the past half year too, and that failed. First come up with good reasons why you think the above plan will now work, where it failed before. Your doom scenario of JChemPaint being years away is quite disturbing and unjustified. You do not show you want to make JChemPaint better and only show interest in quick-fixes here and there. Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |