Java ME MIDP, CLDC and BlackBerry APIs

It’s not difficult to develop a BlackBerry^® smartphone application. The development environment is expansive and free, the default development language is well known and well documented, the BlackBerry API is expansive and well documented, and a wealth of sample source code is available. As a bonus, back issues of the BlackBerry Developer Journal include in-depth development tutorials that clarify many development issues.

If you don’t like developing in Java^® ME, then you’re free to develop applications using the Plazmic^® Content Developer's Kit, the BlackBerry^® Mobile Data System, or use a free plug in to develop applications within a Microsoft^® Visual Studio^® environment.

If you prefer to use something other than the BlackBerry Java^® Development Environment, you can. Many people have successfully used third-party development tools to create BlackBerry software solutions.

This ease of development has resulted in a great deal of development activity throughout the world. Commercial developers have created a slew of amazing applications for BlackBerry smartphones while developers within corporate and government environments have created countless specialized applications.

With these facts known, it’s a mystery why so many developers find it difficult to create BlackBerry smartphone applications. Perhaps the key lies in finding something worthwhile to develop. After all, designing, developing, testing and refining software applications is a lengthy and expensive process. Many developers need to be fully motivated before work can begin.

With luck this article will help spur you on to creating world-changing BlackBerry smartphone applications.

It’s always best to learn from the past without dwelling on it. Learning from past experiences can help you right now, and will also help you to set processes in motion for the future. Dwelling on the past can tarnish the present and the future and make you miserable in the process.

To make this point clear, I’ll state that I spent many years detesting Object Oriented Programming and Java because of my programming background and work experiences.

I’ve always enjoyed doing things that are difficult or borderline impossible. In high school in the mid 70s I took an introductory software development class. We had no textbooks, used a keypunch to program, and had to wait for weekly batch runs of our cards on a mainframe that was in another city. While difficult and coming close to impossible, this was not the challenge I had been expecting when I took the course.

After high school I programmed on mainframes in a few languages, but that, too, was anything but challenging. Our biggest thrill came when we got a VAX/VMS system and could finally ditch punch cards entirely.

In the early 80s, I started writing applications for microcomputers. This was the challenge I had been waiting for!

Like many developers in the early days, I had to create lean and mean programs to get the most from computers that had slow processors and limited memory and file storage capabilities.

Back then, you took what you could get when it came to programming languages. Where Cobol, RPG and Fortran were good for mainframes and mini systems, I had to write in BASIC and assembler on early micros. Assembler was the first language that I truly adored. While initially difficult to learn, it was highly rewarding because the resulting applications always pushed the computer as hard as possible, using minimal memory and storage resources.

The major drawback with assembler is that it is specific to CPU, computer architecture and operating system. This was not too much of a problem in the early days but became a problem when trying to support dissimilar platforms. While it was a rush to write in assembler for several popular chips, doing so was far too limiting when trying to write a common application that would work on multiple platforms. When I reached that point I switched to C and never looked back!

C was portable across most platforms and compilers were refined enough to create highly optimized executables. The primary difficulties in writing common applications across multiple platforms related to display, menu, file and print handling, and occasionally, memory handling. This was handled with relative ease by creating platform-specific code and using preprocessor directives to separate the common from platform-specific code during compile.

I wrote in C++ when compilers started to support it, and came away convinced that C was still superior from a speed, storage and portability perspective. OOP techniques slowed down execution speed, slowed down memory and file access, increased the size of the executable, and made platform portability far more difficult. As an assembler programmer I knew that indirection wastes CPU clock cycles. OOP, by design, wastes clock cycles by making heavy use of indirection. Over time, hardware improved enough to make speed and storage less of an issue, and C++ libraries improved to make it easy to develop full-featured applications.

I wrote in Java when the first versions came out. Execution, memory and file access speed were far worse than C++, and storage was bloated because of the overhead required to run a JVM. This was to be expected from an interpreted language. The only true benefit at the time was that multi-platform support was designed into the language. Hardware and language implementations eventually evolved enough for Java to become acceptable.

My business and several companies that I relied on started to falter around the time that Java came out because the World Wide Web made my specialty largely obsolete. You see, my company mostly developed software for CD-ROM based products. We developed technology that worked across several platforms that included high-speed search technology, data compression, GUI front ends, reporting packages, print handling and more. Many people realized the potential of the web and made decisions that impacted badly on old-school companies like mine.

In turn, we became early adopters of the web and tried to raise funds to create a web search engine using our search technology. Unfortunately, the venture capital firms we approached could not see how they could get a return on their investment from a web search engine. It took me years to realize they were right because our business model failed to consider advertising.

After a decade of self-employment I started work for another high-tech company. At that time the company had a core group of software products that were highly optimized and written in C and C++. This was my type of company!

This did not last. Management decided that it was a waste of time, effort and money to create executables for several platforms, and then decided that it would be best to port their core products to Java. They made a mess of the ports, alienated their client base and almost went out of business. While there were several other factors involved in this disaster, porting to Java was one that really got to me.

I landed a job at another high-tech company that had a core line of software products written in C and C++. They, too, had to create executables for several platforms each release, and they, too, decided to port to Java. They made a mess out of the ports, alienated their client base, and also came close to going out of business.

With three companies shot out from under me, I started work with Research In Motion. At the time RIM had four BlackBerry devices, all developed in assembler, C and C++, and all supporting C and C++ development. Very cool!

The BlackBerry^® 5810 smartphone was released shortly after I started with RIM. This was their first Java ME-based smartphone. While a good first effort, it was slow compared to C/C++ BlackBerry devices, and didn't sell in volume. Thankfully, RIM has greatly improved, enhanced and expanded its line of products since then.

Time has proven my loathing of Java and OOP largely obsolete. Current BlackBerry smartphone are superior in every way to earlier smartphones. They're fast, stable and full featured. Best of all, it's far easier to write stunning Java ME BlackBerry smartphone applications than it was to write them in C and C++ for earlier devices. The MIDP, CLDC and BlackBerry APIs are full-featured, powerful, extremely stable, and highly optimized for speed, memory use and storage.

The moral of this story is that today is not yesterday. Things that were true in past are not necessarily true today. Dwelling over past experiences, good and bad, will never lead to doing better work or feeling better about life. It just makes life harder than necessary and limits natural abilities.

I finally have stopped dwelling on my past experiences and fully embrace the present. In my present, BlackBerry smartphones and Java ME reign supreme. Where I had to write from scratch in my assembler and C days, and also had to spend small fortunes to purchase specialty libraries, compilers and hardware, this is anything but true today. Java ME and the BlackBerry API are full-featured in the extreme and virtually free to write in. Best of all, you’ll find that it’s fairly easy to create software that takes full advantage of all that BlackBerry smartphones offer.

You should take some time to determine what you would like to write. It’s hard to learn something new without a strong desire to immediately use what you’ve learned.

The best way to stoke your programming desire is to wade through the JavaDocs provided with the BlackBerry Java Development Environment. While I could provide you with a massive compendium of all Packages, Classes and Interfaces contained in the Java ME MIDP, CLDC and BlackBerry APIs, it would be out of date in short order. Download and install the latest BlackBerry JDE then take some time to review the JavaDocs. After that, compile all sample applications that come with the JDE, try them out then review the source code to see what makes them work.

While reading through the JavaDocs, you may notice that several classes and interfaces have been flagged as Signed. Some crypto classes and interfaces have also been identified as being part of the Crypto Extension API. Use of these components within a BlackBerry smartphone application requires code signing before live deployment. Applications that are configured to automatically start when the BlackBerry smartphone starts also must be signed. Code signing has been employed to track the use of sensitive APIs for security and export control reasons.

If you use controlled classes, interfaces or the auto-start technique in your application, then your software application must be signed using signature keys provided by RIM before you can load the application .cod files onto a BlackBerry smartphone.

You can request code signature keys using this link.

You will pay a fee to get signature keys. The payment method is largely used to authenticate the keys to the user.

Note: Certain cryptography classes related to public/private key cryptography contain technology from Certicom. Use of these classes must be registered and licensed from Certicom directly. The cryptography API detailed in the JavaDocs identify items that are part of the Certicom Cryptography APIs.

The latest version of the BlackBerry JDE works best with Java 2 SDK, Standard Edition v5.0 or v6.0. Make sure to download and install either of these version of the SDK before installing the BlackBerry JDE.

You can download the BlackBerry JDE here.

To test and debug your applications, you’ll need to also download and install the BlackBerry^® Email and MDS Services Simulator Packages. You may also need to install additional BlackBerry Device Simulators.

Please use this link to download these tools:

The first thing to do after you get your development environment set up is determine if you know enough about Java ME and the BlackBerry APIs to write an application. If not then you need to ramp up fairly quickly. A good place to start is by reading articles published in the BlackBerry Developer Journal, and by reading some of the Product Documentation that is available through this link.

You can also search the web and prowl around book stores for books and articles and then delve into programming issues related to BlackBerry smartphone applications or Java ME in general. If you are anything like me, you’ll also need to create some original software to learn. Following step-by-step coding tutorials in a book or article is a decent way to gain some hands-on experience, but nothing beats coding something original from scratch.

Please email your comments, suggestions and editorial submissions to