Java Development

[simon_hain]

With java running in a virtual machine anyhow there is no big change for a blackberry developer unless APIs change, too.

Until now the OS of a blackberry was of no concern for a developer except for the tied API version and i don't see why this should change in the future.

The real question will be if the BB API stays limited as it is and if Android will have a wider functionality and a better API. While there are many possibilities with the current API there are also many limitations, and J2ME was developed to run on 50kb phones, not the dual-core 1GHz smartphones we have now (which could have replaced some full PCs not too far ago).

On the one hand i feel pretty well accommodated within the confinements of the RIM API, i know many of the dirty tricks, can write my own sublayouts and am no longer an enemy of Graphics.paint or deviceside=xxx, but on the other hand i am looking at the things other developers can do, the look and feel of their apps and the usability, and i see the blackberry API as a bit backwards.

The upward compatibility is great, but if there will be multiple VMs (aka players) on the device anyhow it could be the time to either modernize the BB OS without looking back (and providing a legacy VM) or switching to Android altogether, even with me and us having to learn a new language (kind of).

[ekke]

---

simon_hain wrote:

...

The real question will be if the BB API stays limited as it is and if Android will have a wider functionality and a better API.  ...

---

of course using Android as a Java Developer it's easier to develop with more comfort and BlackBerry has to change things in the future.

on the other side the fragmentation of Android with so many different software versionsn + so many different hardware vendor addons doen't make it really easy for an Android developer

from this POV its much more easier to develop for iOS

---

simon_hain wrote:

...

On the one hand i feel pretty well accommodated within the confinements of the RIM API, i know many of the dirty tricks, can write my own sublayouts and am no longer an enemy of Graphics.paint or deviceside=xxx,  ....

---

RIM provides so many different ways and also flexibility with BISB, BES, ... and I can imagine this will be the same in the future. (otherwise BB would only one of n devices from n vendors - and this really couldn't be the goal ;-)

so many of your dirty tricks (also helping me reading your messages at this forum will also be needed in the future - even using a more modern Java SDK I'm also hoping will come

---

simon_hain wrote:

...but on the other hand i am looking at the things other developers can do, the look and feel of their apps and the usability, and i see the blackberry API as a bit backwards.

---

veto: using OS 6 you can really develop modern UI with great experiences for the users and great look and feel. such apps can play at same level as iOS or Android

---

simon_hain wrote:

...

The upward compatibility is great, but if there will be multiple VMs (aka players) on the device anyhow it could be the time to either modernize the BB OS without looking back (and providing a legacy VM) or switching to Android altogether, even with me and us having to learn a new language (kind of).

---

thats my point, too: upward compatibility is great - some days ago I wasn't sure if there will be an upgrade path - now it's announced.

but this is only the first step needed. I'm really hoping that there will be a modern Java SDK for BB in the future and that this isn't Android, because I would love to see RIM as a unique player in mobile business like Apple

[rcmaniac25]

I see this as great news two.

I have one question and one comment that I think people are missing:

First the comment:

They didn't say that Android Marketplace will be included with the player, they said you need to package the apps for App World. So the "X million apps for Android" gets reset to zero. Only those willing to move the apps over will be on the device. Also we don't know what changes might exist with the API. The API might be there (like we have with multiple JSRs for BlackBerry) but it might not be implemented.

Second, the question:

Can we make our own players? This is the kind of stuff I like to do.

If we can make our own players, I see WP7, Desktop Java, and a little thing called iOS "players" coming.

Heck, we might be able to get linux applications running on a specialized "player". I love the concept and have wondered why no one did anything like that, now not only is someone doing it, it's a major corporation.

[simon_hain]

A good read about the "openness" of Android is here:

http://arstechnica.com/open-source/news/2011/03/android-openness-withering-as-google-withhold-honeyc...

when i look at this i think RIM is at least trying with the developer community. if we get the new feedback forum soon it will be a big improvement i hope.

[sblantipodi]

My apps are identical on both Android and Blackberry Java,
I prefer the java environment, I feel more at home, creating a new activity instead of a class is something ridiculous to me so I will choose BB Java for Tablet.

Sincerely I really don't like to see Android on a RIM product, RIM got Java+RIM API and this is its strengh, no problem, no compatibility issues, no fragmentation at all.

The only thig that should be improved in the RIM ecosystem imho is the internet connectivity, leave android to kids who needs to play games with phones.

When will you give us an SDK and when we can submit our apps to app world?

[dnepr]

Our Apps on Android and BB have identical functionality, but BB apps are way more OS integrated.

Will this new repackaging deal work with current OS integration? Calednar, Email, On screen notifications, etc, etc, etc.

As far as UI.    BB GUI framework can compete and win over anything out there right now.   It might be painful to write it initially, but once you know what you're doing it's very easy to create very complex UI via custom managers, etc.

[heynow]

My company has several applications on iOS, Android and BlackBerry and the biggest disadvantage we see on BlackBerry is JME which is years behind Android's Java.

On Android I can grab just about any 3rd party library written for JSE and drop it into my Android project and it will work.

On BlackBerry I am forced to find a JME version (good luck) or port it myself. In our most recent application, for the BlackBerry version I had to implement zip file support, ftp support and implement a huge layer of networking code where on Android I just used off the shelf libraries for everything.

If BlackBerry changed nothing at all except bringing its VM and toolset up to Java 6 then it would be a huge win for developers. BlackBerry would no longer be the ? on the schedule. OK, great feature, so how long will this take on BlackBerry?

[DIegoR]

---

simon_hain wrote:

The real question will be if the BB API stays limited as it is and if Android will have a wider functionality and a better API.

---

I have just independently posted a question to RIM as to why they keep their API so limited

Java development is so easy and there are thousands devs doin it. Just learn by Android example. The more you open your APIs the more devs get involved! Look, Simon is one of the most active contributors here, he sure have a good overview of the issues. Please RIM, help us help you.

[sblantipodi]

---

dnepr wrote:

Our Apps on Android and BB have identical functionality, but BB apps are way more OS integrated.

Will this new repackaging deal work with current OS integration? Calednar, Email, On screen notifications, etc, etc, etc.

As far as UI.    BB GUI framework can compete and win over anything out there right now.   It might be painful to write it initially, but once you know what you're doing it's very easy to create very complex UI via custom managers, etc.

---

I completely agree.

---

heynow wrote:

My company has several applications on iOS, Android and BlackBerry and the biggest disadvantage we see on BlackBerry is JME which is years behind Android's Java.

On Android I can grab just about any 3rd party library written for JSE and drop it into my Android project and it will work.

On BlackBerry I am forced to find a JME version (good luck) or port it myself. 

---

Ok but what about the pain of fragmentation in Android? On BB there is no fragmentation at all.

If you are able enough to write your own UI Toolkit with BB you can write a code that is able to run for the 99% on Bada, Symbian and JavaME phone.

Our BB software runs as his on BB, Bada, Symbian, Java Phones, Windows Mobile 6.5 with really few differentiations when building the final binary using pre-processor.
There is also no way to preprocess code on Android and on a such fragmented OS I can't understant why developers like it so much.

[br14]

I'm not sure why any BlackBerry developer sees this as "great news". Even those who currently develop for both platforms.

If you listened to Jim Balsillie you'd have heard the frustration in his voice when he described the feature to analysts. I think he's right to be frustrated. Its terrible news because BB apps in my view tend to be more integrated and in general of better value.

And instead of a few tens of thousands of apps competing for a market of 55 million (when QNX hits phones), now 300,000 apps will be comnpeting for the same market.

As for the "player", surely the big question is why no JVM?

To run standard Java you need a JVM. Androids JVM breaks Oracles patents (allegedly), and RIMs JVM is licensed from Oracle and follows standard.

The fact RIM is calling this new feature a "player" suggests to me some kind of off device cross compiler and that they will not be licensing Java, because anything "playing" Java class code on the device surely has to be a JVM of some description. And any JVM must be licensed from Oracle.

Unless they come up with a new language as did Microsoft with J#.

Its an interesting development and I'll be fascinated to see how they get around the legal minefield but I don't see much good for any of us developing Java for BB.

Seems to me RIM is puishing WebWorks very hard instead and the "player" will be a poor relation.