09-13-2008 04:07 PM
Ok,. so you need to provide JNI to actually get all of it to run but there ought to be a way to
get class libraries along with some jvm to start it without all the graphic junk.
I'd have to guess that UI load/init is where a lot of time goes.
The JVM itself provides a lot of good runtime debug info and if you don't care about some of the
graphics it should run pretty easily from the command line. I can't believe there is anything special about the emulator
JVM in as much as the real one runs in a phone. If I can run swing and awt from the command line with just adding
a window, you would think the phone would work too.
09-13-2008 04:53 PM - edited 09-13-2008 04:55 PM
To be able to do serious developments on JDE, one should be able to invoke the BB JVM from command line. This will also open the doors for real unit testing.
For the moment thought I would start with simple things such as keyboard short cuts for restarting the simulator, ability to set preferences so the LCD stays on all the time... there are times I have had to restart (ie every time I load new version of my app) the simulaor over 2000 times (literally, I have automated build# generation) in a given work wee.
Every small bit of improvement with the simulator helps, but I am not seeing any.
09-14-2008 08:00 AM
Well, someone could profile it and find out where all the time is going and fix the bottlenecks but I take it that isn't your concern
Java is never thought of as something that starts up fast but I this seems to be worse than most, probably all the
classes and UI stuff it wants to load. While you can imagine that a complicated debug environment could be needed
to debug for a limited target, the interpretted nature of the JVM itself already provides a lot of good diagnostics
and it is normally easy to write test classes to load with your target code. For example, I used to test audio/video applets destined
for browsers from the command line and the approach worked quite well. I didn't have a java browser emulator that had
the look and feel of IE, and I sure didn't need or want that. Certainly you do run into real world problems later
but emulators don't usually catch those in any case.
These results are always annoying because you either suspect commercial incentives ( MSFT wants to help INTC sell more RAM )
or simple laziness ( I copied a bunch of stuff out of a book that should work and it is good OO design and you can't do any better than that as java bytecode compilers can't or at least don't do a lot of stuff like inlining....) or ignorance ( object code ? huh?). And of course
design for GUI often limits the flexibility of the code or even introduces more bugs.