I frequently get questions about applications that dies, either due to pure bugs or due to high memory usage. So the question is often, what does it require to terminate an application? And the answer is, quite much  In most case when a Throwable is created an not caught by any code in the thread, it will end up as an "uncaught" Throwable. There was at some point an MSA requirement that an uncaught Throwable should result in application termination. But this requirement was later dropped before the final release. So, uncaught Throwables will not result in application termination except for two cases: - If the MIDlet class throws a Throwable in any of the MIDlet class methods (e.g., startApp()).
- If OutOfMemoryError is uncaught in any thread.
In order to show some examples of this, I have attached a small application with source code. Look into the code and try the application on your phone. Make sure to have the USB cable connected and use the "ejava open" command to see the System.out.println() printouts! Have fun!  Update: For some reason, I can't upload the file in the blog. Please look here instead: http://developer.sonyericsson.com/community/thread/49852
In JP-8.5 we have introduced some major changes when it comes to the Java heap. Most notably is that the initial Java heap is much bigger than on JP-8.4 and earlier. The initial size is now 2 MB. The reason for this change is purely performance. At start up there are many different Java applications starting, as most of the phone applications are now written in Java. With the larger initial size of the Java heap, the garbage collector can run less frequent and thus the penalty on the performance is less. Depending on phone model, the SonyEricsson Java applications will consume up to at most 1 MB of the Java heap at start up. Another change is also that we try to keep more space free on the Java heap. After each GC we perform an adoption of the Java heap, if needed. We try to keep approximately 50% of the Java heap free after the GC. This also improves the performance (slightly) over JP-8.4.x. As before, the GC is a precise GC which means that when the GC is running the entire Java heap is examined (while the VM is stopped). If there are dead Java objects, they will be finalized and removed during the GC. However, we have also introduce asynchronous finalizers to be able to handle Java classes that need more time in their finalizers. Unfortunately, this is currently only available for internal API code. But you may sometimes see the result of these asynchronous finalizers since some objects will not be finalized during the first call to the GC. To add to the problem list for you developers: there will be phones with small amount of memory and there will be phones with too much memory  So, on most phone models you will start to get problems when the Java heap is 5 MB and for at least one particular phone model (Aino) you will easily be able to get 30-40 MB of Java heap. What to keep in mind: - Be careful with how much memory you application allocates. The more memory you allocate, the worse everything else in the phone will work.
- Since the Java heap is larger than before, the GC will not run as frequently as it used to. Sometimes you may therefore encounter situations where native resources (UI components, image objects, 3D objects, camera, network etc) are not freed when you need it. Make sure to implement correct error handling and you may need to perform a System.gc() yourself in the application.
- If the Java heap is too big, i.e., you store a lot of data on the Java heap, the GC will not be fast...it will take time and you will get performance problems!
Good luck with your projects on the new JP-8.5.x devices!
Hi, It was a long time since my last blog. I have been quite busy and not been able to spend much time on the forum and making blog posts. But since the manager the community site of SonyEricsson developer world stepped by my office, I now feel that I must make a small update  I have spent the most of my spare time during this summer preparing for a charity bike ride here in Sweden: Ride of Hope.The purpose was to collect money for research in cancer, specifically for children. 
We had a really great week and completed roughly 1300 km in 9 days. During my training I have, of course, used different SonyEricsson phones with GPS or with external Bluetooth GPS. It's really great to be able to have powerful map features, tracking features etc easily available within a small handset that you just put in your pocket. However, using many different applications on many different handsets also means that I have found many problems (and in some cases even bugs). Just to list a few things: - The phone will get wet when you bring it along on bike rides! A transparent plastic bag can be very useful to save the phone. It works well under most conditions, but on sunny days your are unable to see anything on the screen through the plastic bag.
- When riding on the bike the commands to navigate on the map and in the menus must be really simple. Not all programs have different modes of their menus during setup and usage. I would recommend developers to really make some efforts to have both "advanced" and "simple" menus.
- Error handling and startup: Some applications really did not want to start without everything being perfectly in place. For example, first you have to have proper GPS coverage. After that you need to publish some info to Twitter and Facebook. Thridly, the application needs to send info to the server of the service. And so on. If one step failed, you were stuck
 All I want to do is to start my application and go on my bike ride. If somethings goes wrong, I expect the application to resolve this when possible without waiting for my feedback/input.
- On some handsets, using Bluetooth GPS and HTTP-upload at the same time did cause some problems. I don't the root cause of this problem, but the problem usually didn't appear until after a few hours. Basically, the Bluetooth link stopped to work in these cases.
If you have any experiences of using GPS services/applications on the SonyEricsson handsets, please don't hesitate to share your experiences. It would be really great to have your feedback as well! (and of course, if you have a really great application of your own that you would like me to try out, just send me a PM)
So, my parental leave is over and in a few minutes I'm heading back to work. There are new challenges in the world of Java and my manager has prepared an new project for me at least the next 6 months or so. I'm really looking forward to this. (Sorry, can't give you any details at this point but it is related to my previous blogs) Unfortunately, this means that I will not be able to read that many forum posts. If you post a question with detailed information about the problem you have encountered and don't get any replies, please do the following: 1) Make sure to follow the hints about debugging in my previous blog. 2) Read about the "common mistakes" that wrote about in a forum post. 3) If you don't find the problem, please send me a private message and I will ask a developer to look into your question. Please make sure to state in your forum post that you have done 1 and 2 above since, in some sense, it's very expensive to get the developers to spend an hour or so helping you. Final advice: Keep writing Java applications for SonyEricsson phones. Push our APIes to the limit to take full advantage of the phone capabilities!!!
I thought that I should share some small things that may help you debugging problems in your application. Hopefully it will save you a lot of your time and also improve the quality of the forum posts. First of all, applications and threads never terminate for no reason. All your threads should always be wrapped in a catch of Throwable as a last resort to catch unhandled exceptions and errors. Please look in the following document: Catching throwable Another things is of course to have proper logging in your code. A very simple way of doing this is by using System.out: Notes about logging in Java ME I should of course mention that the way I prefer to obtain the System.out stream on the PC is by using the "ejava" command that is available in the SonyEricsson SDK. By issuing the "ejava open" command, you will get the System.out stream. Sometimes it is sufficient to just look at the output in the command window, but usually, you will need to pipe the result to a file for later analysis, i.e., "ejava open > debug1.txt". Well, the above helps me in more than 90% of all cases where I analyse a problem in an application. Depending on the type of problem, the next step of debugging is either on-device-debugging or debugging in the emulator. For my own applications where I need to sort out logical problems, the emulator is usually the way to go. But if you are trying to sort out a problem that only occurs in on the device, then you need to use on-device-debugging. It's quite cool, make sure to try it out! For the more advanced developers or for "investigators" that need to analyze applications without access to source code, I can recommend ASM (http://asm.objectweb.org/). With ASM you can modify the byte code of the class files directly. I have promised in Notes about logging in Java ME to show howto insert tracing of method entry and exit. I will have to get back to this in a few weeks time, it's really cool. And finally, make sure to read my post: Some common mistakes seen in this forum. I can promise you that every now and then you will encounter one or two of the problems that I mention. This happens to me as well!!! If you have any questions regarding this blog or the "common mistakes", don't hesitate to ask.
Hi and welcome to my blog! Many of you already know me from various discussions and posts in the Java ME forum on this SonyEricsson developer site. For those of you that are new to this site, here is a short presentation of me: My name is Nicklas Ekstrand and I'm working in Lund, Sweden at SonyEricsson. Since January 2006 I have been working with the core Java VM for the SonyEricsson "feature phones", i.e., those with JP-6, JP-7 and JP-8. For those of you that recognizes "SonyEricsson Enhanced VM" (see for example http://www.paxmodept.com/telesto/blogitem.htm?id=607) know what I'm talking about. When I talk about the core Java VM I really mean the core, not the Java APIes, JSRs or AMS. Well, the core Java VM is actually JSR itself, the "JSR 139: Connected Limited Device Configuration 1.1" (see http://jcp.org/en/jsr/detail?id=139). This also means that when I'm debugging a problem it is usually with Lauterbach (http://lauterbach.com) equipment and special phone hardware on assembler instruction level. So please, no questions about how different APIes work Currently, fall 2008, I'm on parental leave. But I will try to keep an eye on the Java ME forum and I will write a few blogs whenever I have some spare time. About our platformsUnfortunately, we don't have any names on our various platforms (at least not until now) and this causes a lot of problems in the Java ME forum. But in short the platforms are: As all of you that produces content to our phones already know, the feature phones are the ones we sell the most of. Therefor, it is really great that we have our own Java platform on these devices. This also makes it possible for me to say: Java is THE programming language for mobile phones Since the introduction of JP-6, the native phone applications has started to be converted from C to Java. At JavaONE (http://java.sun.com/javaone/sf/) this year, 2008, you could read the following in our booth: Full MSA compliant (since JP-8). Java execution speed on par with native C code (since JP-6). AOT (since JP-6). Multitasking Java VM (since JP-7).
But this is what you already know because this is available to MIDlets today. What you don't know is that under the hood there are a lot other "stuff" that enables our native Java applications. To handle the increasing internal code base there have been major updates of the Java VM for JP-8.3 and yet another major update for JP-8.4. At some point, JP-8.3 was actually called JP-9 internally because of the updates. During the fall you will get more information about new features, APIes and tools. Make sure that you logon to the developer site regularly and that you have the correct permissions on your account to get the proper access to your information. The world of fragmentation? Yes, this is terrible and we don't like it! SonyEricsson does not wish to publish proprietary API unless really needed and there is no JSR covering a specific functionality. If you ever find anything in the core Java VM that is different from other Java VMs on the market, please let me know. Use our tools! If you have not already, make sure to read the blog from my colleague Erik: https://developer.sonyericsson.com/blogs/mrhellman/2008/08/28/hello-world. Erik is responsible for the PC tools for Java ME development and I'm working with the Java VM on the phone. So, please make sure to use Junit, on-device-debugging, profiling and the resource monitor. Your feedback is necessary in order to improve these tools further! Please stay tuned for coming blogs! BR, Nicklas Ekstrand
|
Developer World
Corporate Home