Hi Bob. As promised, continuing the discussion on the jalview-dev list.
Let's start thinking more specifically about Jalview, VARNA, and goals. Can we get anyone from the VARNA team involved? VARNA is part of Jalview, right? And I think it is a simpler objective. I have looked through its code and have some sense of what I need to do there.
VARNA is linked with Jalview - and we're integrating more tightly in this 2.9 release, but they are still separate projects, developed by different groups.
@Yann - do you have any thoughts on Bob's plan of tackling VARNA first ?
OK. Now to business:
There are quite a few things that need to be done at your end in preparation for porting to JavaScript. All of this is totally compatible with keeping everything in Java, of course. Most critically:
-- for any .jar file in that /lib directory that you use in the applet, we will need source code. There are a lot of jar files there, and many of them I have no idea what they are about. Can I get a list of what each is used for and issues there?
The JalviewLite applet is a subset of the full codebase. Its runtime dependencies live in appletlib, and it has a special build task (ant makeapplet, which does the build and obfuscation). We add package excludes which stop all the Desktop's GUI, web service, XML and figure generation stuff from being imported.
-- code necessary for the applet must be isolated from code that is not needed because it is application-specific. This needs to be done using reflection. The syntax:
xxx = new xxx.yyy.Xxxx()
has to be converted to
xxx = (Xxxx) Interface.getInstance("xxx.yyy.Xxxx")
where Interface.getInstance calls Class.forName().newInstance()
Ah - so that's org.jmol.api.Interface. We can do that. It means Jalview will have Jmol as a core dependency (not so bad really 
).
-- Even within the applet, the more reflection, the better.
OK. so what are the limits here ?
0. Reflect for all classes where no source is available ?
1. Reflect for classes in the same package ?
2. Reflect for classes in a different subpackage to the current subpackage (but still within jalview.blah) ?
3. Reflect for classes where source is available, but not
-- If possible, syntax like this:
/ for (int i = 0; i < java.lang.reflect.Array.getLength(getServices()); i++)
/
should be changed to/ import java.lang.reflect.Array;
...
/
/ for (int i = 0; i < Array.getLength(getServices()); i++)
/
Likewise, wherever possible, because we will absolutely need to know exactly what classes are being loaded. In Eclipse, one can very simply make explicit the import wildcards:import java.lang.*;
using ALT-s g. It would be great if someone could go through and do that.
We'll do that for the 2.9 release. Mungo Carstairs cleaned up our shared eclipse config so we now have autoorganise & explicit imports, but we'll apply the new formatting (and licensing) for the whole codebase as a final release step.
Does someone on your end have time to work on this?
Yes. We'll work out who's the best person for the job over the next few days. I suspect it'll be Mungo, but I'll let him have a think about it first !
Jim.
ยทยทยท
On 27/05/2015 13:24, Robert Hanson wrote: