Try to run attached test case by Internal
On my computer Solaris5.8,
MainWindowOperator.getFrame() takes more than 16
So, in my opinion it is long time, it means each
test which uses Jelly spends 16 seconds on looking
for Main Window and it's really bad performance.
Created attachment 7873 [details]
I changed the summary because it is not problem of Jellytools but
Jemmy. Following test case takes long time as well:
long start = System.currentTimeMillis();
long finish = System.currentTimeMillis();
System.out.println("It takes ["+(finish-start)+" ms] !!!");
It is caused by initializing of jemmy drivers. For example, look at
org.netbeans.jemmy.drivers.focus.MouseFocusDriver constructor. A lot
of operators are loaded to memory by command AnOperator.class and it
takes a long time.
I think it is not necessary lo load all operators at this time. Shura,
is it possible to change implementation to decrease initialization time?
First Jemmy call requiring Jemmy initialization causes almost all
Jemmy classes loading. First of all it means that compiled classes
need to be loaded from filesystem, or an archive need to be
loaded and decompressed. Uncompressed compiled files take almost
3 MB to store - no wonder it takes some time. Full list of packages
with sizes is attached.
This classes need to be loaded anyway - either during Jemmy
initialization or during test execution one by one. Well, not all
of the classes need to be loaded, but most of them are. Like, for
example, the biggest class is JTreeOperator (152 k), next
going ComponenOperator (146 k) - they need to be loaded.
Class loading takes place once for one JVM (i.e. once for one
testbag). If test extends JellyTestCase, initialization is
performed during runBare() method execution - before testcase.
I do not clearly see what could be done here without full
revriting of drives registrating, but even then - the only
possible way I see - rewrite DriverManager so it would implement
lazy initialization technique. But it woud mean endless "if/else
if" statemens, an, in addition it's not clear how to work with
Any ideas how to do it other way?
BTW, I've got interesting results: in my environment, Jemmy
initialization takes 3 sec when executed from commond line, 4 sec
being executed from NB externally ans 23(!) sec - internally.
The testcase I use is also attached.
Interesting resutls: in my en
Created attachment 8247 [details]
Sizes of packages and operators.
Created attachment 8248 [details]
Code to measure initialization time
It is annoying especially when you developing a test case in IDE and
every start of jemmy test takes about 20 s.
If you will not rewrite drives registration, it would be better to
discuss (or file a bug) with guys from core why loading of classes by
internal execution is so slow.
Ok, I finally have an idea.
I can create another class - analogical to SupportiveDriver, but
working through reflection. It will be initialized by an
array of String - full names of supported classes.
Then, the check for an operator to be supported will be
performed by a comparision of those strings to a name of
an operator class and any its superclasses.
I'm starting this development.
Fixed in 2.2.0
Verified in 2.2.1. Thanks.