Trusted Status from Java Verified – what do you think?

Read this Trusted Status FAQ and then post your comments

Updated on September 7 2010: Many thanks for your many suggestions and comments on our new, proposed Trusted Status.    We’ll be considering all of the input and announcing at JavaOne exactly how it’ll work,   plus opening it up for people to apply.  Thanks again.

We’ve just announced Trusted Status: a privileged status (to be made available from JavaOne in September 2010) to be granted to developers who will have proven that the quality of their Java ME apps is of a consistently high standard. These are developers who will have earned the trust of Java Verified by demonstrating unfailingly that testing to the UTC standard is a crucial part of their product development activity.

But before we go any further, we want to consult with you.
Please read the pdf .  The areas we’re really keen on hearing from you about are highlighted in yellow.

Basically, Java Verified developers who are awarded Trusted Status will no longer need to use one of the three accredited test houses to test their applications, and will no longer need to declare the test results. They will have gained the trust of Java Verified that their apps will consistently pass the criteria.

So please let us know what you think by having a dialogue with Java Verified and other developers, carriers and OEMs using this blog.

We’ll be closing off this post for comments on September 6 so we can take in all of your input and then open up Trusted Status for developers to apply on September 20.

Thanks in advance for your thoughts.  We look forward to the discussions!

This entry was posted in Trusted Status. Bookmark the permalink.

32 Responses to Trusted Status from Java Verified – what do you think?

  1. Vishwanathan says:

    Hi,

    You cannot accept the development teams to be passing UTC @100% for the 1st time every time. You need to leave room for errors. In my opinion, about 95% should really be the threshold except if there are serious issues (e.g calls and app crashes)

  2. Andrei says:

    Hi ,

    I think 100% is way to tough. Now all the developers are moving to Iphone/Android/WP7 .You are not expecting them to still develop J2me applications with this conditions?

    Cheers

  3. Eneko says:

    User experience in unsigned advanced Java ME applications is terrible because of phone asking permission for every “advanced” functionality. Cost of signing apps with Java Verified is absurdly high because the required testing. These are among the main reasons why no customer ask for more Java developments and ask for iPhone/Android, having 90% of Java enabled phones and less than 10% of iPhone/Android.

    This new way for signing apps must be as easy and cheap as you can get, nowadays no one is investing a lot of time or money in Java.

    • Hi. It will cost a Trusted Status developer *1 dollar* to get each of 20 apps signed as long as those apps are part of the same title. (See the costs section (Content IDs) of the pdf).
      It’ll cost the same developer whatever it costs to test them against the Unified Testing Criteria. What we care about is that the apps pass the UTC, and we’ll audit a percentage to make sure all is in line. Does this make sense?

  4. This might encourage us to send our apps through the Java Verified process again, but I still doubt it will happen. We did that a few times in the past, but we get about the same results (trusted security domain on handsets) by signing the applications ourselves (with Thawte and Verisign certificates).

    One of the problems in the past was that the process slowed down the publishing process, as we needed to wait for the test results. Trusted status would help here. Another thing was the cost. Here, even if the trusted status would lower the costs, just the cost of obtaining that status seems too high compared to the benefits.

    We’d favor a way where we could start off from the Trusted status and then get some penalty if our apps won’t meet the required criteria. Now even getting the status in the first place seems expensive compared to what you get for it.

    As background info, we only have a limited number of apps, but those are complex enough not to fall within the Simple App criteria.

    • Thanks. An app with Java Verified status shows the industry that it has met certain quality criteria. It shows that it works. It’s difficult perhaps to ‘trust’ that a developer’s consistently meeting a high quality if there’s no way of proving it which is really why we’re suggesting that developers go through the Qualification Stage to enable them to gain that trust in the first place. And, if you aren’t already getting your apps Java Verified (and therefore don’t have a history with Java Verified), but only have a limited number of apps, perhaps the benefits would out-weigh the initial cost?

  5. Does it help to get the Trusted Status if I can demonstrate my apps being deployed on hundreds of device models and being used by tens of thousands of users regularly, or do you only look at the UTC test results?

    • The quantity of apps being deployed by a developer is not important. Someone developing 2 apps is just as valid for Trusted Status as someone developing and deploying tens of thousand of apps. What is important is that a developer has proven that quality is important to them. And they will have done this through consistently showing that their apps pass the relevant tests in the UTC. The aim of Trusted Status is to keep the quality of Java Verified-approved Java ME apps as high as they are now, and to make it as inexpensive as possible for you to achieve it.

  6. Sebastián says:

    Hi,

    I honestly do not understand that is the most complicated, whether to continue as now or implement this new methodology proposed …

    Since last time I sent an application to one of the three test houses, clear to me that my freedom of expression as a developer is limited by the UTC, because not only did I have corrected errors, but I have changed or remove features from my application that worked well but they did not like because “the screen was not as before, for example. The worst thing is that for this I have had to pay the necessary costs, which in my country are multiplied by 5, since here the local currency is not the dollar or the euro.

    As much as I still use javaverified necessary for some of my applications, I think that compared to the rest of the current market platforms, the signature or certification procedure only creates disadvantages.

    The market has changed, and every day, new and better mobile applications for different platforms. Javaverified must change and adapt to current market.

    The only thing they are making is that the new generation of developers choose other platforms to meet all this.

    Thank you and sorry for my writing in English, I did the best I could remember that I am Argentine.

    • Thanks for your input here. We’ll contact you separately about the app report you refer to here, as the UTC is certainly not supposed to limit ‘freedom of expression’.
      The UTC was developed to assure the best user experience and assuring that the application runs in the device without causing trouble to the user or the device.
      Does anyone else have anything to say about this, or the UTC in general? We’d value your thoughts. Should we set up another blog post to gather your input? This is exactly the kind of thing we’d like to look into, to make sure the UTC does what it’s supposed to do. If it doesn’t, we’re certainly open to look at it again.

  7. Nuno says:

    Hi,

    From our side, this is great news, since we would be able to get a faster time to market on our new versions.

    I would just recommend on allowing a certain flexibility, so that the rules will not be too strict (100% first time is hard to get). Using our case as an example: at least one of our first submissions was not accepted at 1st time, due to a small bug with connection timeouts, which we fixed. After this, we fixed it and will never fail to meet these ‘base’ requirements for UTC (fixed forever).

    Thanks!

  8. Dave says:

    Sure, for companies that routinely use JavaVerified, simplifying the process in any way will be a good thing. However, IMO, the real problem is that even after signing an app it is still only “3rd Party Trusted” status.

    The #1 reason we get our apps signed is to open APIs we need and eliminate those pesky security alerts. Why use get JavaVerified, when we just need to use the carrier’s cert to sign our app with preferred or trusted status anyway?

    JV must negotiate with carriers and get more cert levels that can be offered to developers. We want (need) to sign with “preferred” or “trusted (operator)” status, to eliminate all the security alerts. We want to be TRUSTED and not sort-of trusted.

    App distribution is a big problem when you must sign your app differently for all the manufacturers and operators.

  9. Selahaddin says:

    When I first saw the email from Java Verified my first response was “Java Verified is dead, Long live Java Verified!!”
    But after reading the pdf, it quickly dawned on me that old anti-developer ethos of java verified is here to stay. We have done java verified in the past and it is a laborious process full of bureaucracy and cost. You try to support multiple devices with a cost process that scales as you try to address more devices. Now to be a Trusted Partner, you have to go through the same process again.

    The other platforms ranging from Apple to Android to Blackberry are extremely developer friendly. And they have got the mindshare despite Java ME’s market share dominance globally. So I think Java Verified would have to take much more drastic changes to have a chance of staying in the game. Otherwise, it will be condemned to the fate of Nokia and Symbian who also thought it was a privilege and an honor (and a real cost as Nokia Pro Forum cost 5300 Euros a year + a whole host of other costs like symbian signing that were not included) for developers to be associated with them.

    Android costs 25 bucks and it offers a marketplace for apps.
    Apple costs 99 bucks and it offers a marketplace for apps.
    Blackberry is free (there are also paid memberships where they help sell and market your products to enterprise customers)and it offers a marketplace for apps.

    That’s the competition for java verified, and there’s no Java ME marketplace. There are of course app stores that have a hodgepodge of apps that also contain Java ME, but that is a fragmented market.

    So maybe Java Verified should offer Trusted Status to companies who meet the following criteria:

    1) Have previously already been through the java verified process and got one java verified app
    2) Pay a nominal yearly Trusted Status partner fee, say 99 or 199 or 299 or 399 dollars which includes unlimited signing (it should not be more than 20 times the Android price)
    3) Who list Java ME on their website

    And that’s it. More requirements could of course be added but that would diminish the competitiveness of Java ME.

    We have been building Java ME apps since 2004 or so, and I am convinced that java verified helped kill the Java ME apps potential. It took Steve Jobs to show the world that there is a market for apps (despite having an amazing browser) and then others followed suit.

    Two takeaways from Apples success:
    1) App marketplace
    2) Developer friendly

    So for Java ME to stay in the game, they should give Trusted Status automatically (and revoke it immediately if there is abuse) to developers who have invested in the Java ME platform and know a thing or two about it.

    Oracle should also build a Java ME marketplace as well that is preloaded on any Java ME handset.

    Only then may Java ME have a real chance of staying in the game. Otherwise, it may be too little too late.

    But what would I know. I am just a unTrusted developer.

    • Thanks for your comment, we value your feedback. Java Verified is about maintaining a high level of quality for Java ME apps. That’s it. The criteria we have lists the things which any mobile application must consider in order to have some success in the market. Developers who constantly deliver high quality apps from a user perspective are about to be rewarded for that.

      The Java Powered logo marks those applications which are up to the criteria, adding customer confidence in the application. We cannot lower the bar, but we are very interested in understanding of how else than through testing can we be assured that a developer can create applications which are up to the criteria?

      So, developers develop their apps with the UTC in mind (which a lot are doing anyway) will do the testing themselves, and it could cost them 1 dollar per app to get their app signed by Java Verified. Isn’t that a good thing? What do others think?

  10. This is another step to be better Java Velified.
    It’s the best, quality consideration and the contiuous quality improvement.
    Ok, on the way to quality assurance.

  11. Antony says:

    We develop mobile banking, security and payment applications primarily for banks. For security and flexibility reasons we insert information into the Jar file when it is downloaded from our server. This means that we can not provide a single application and have it signed as it dynamically changes depending on the customer. What would be useful, in our case, is if we can be given Trusted Status such that we can sign applications on the fly as they are downloaded. Is there any possibility of this happening in the future?

  12. Andrei Lascu says:

    As one of the top JV submitters, we really welcome this initiative. We will support Java Verified throughout the process.

    We also suggest to set the first time pass rate at 80-90%. Most apps are too complex to be completely bug free and i am sure that the test houses will “shoot first and ask questions later” (i.e. report issues which may not in fact be issues). They will probably not be supporting us in our endeavor to become Trusted providers since this hurts their business.

    However, from our point of view, the initiative has one major flaw: it does not concern the Nokia Test Criteria at all.
    99% of the apps we submit target Nokia devices because these are apps for embedding on the devices before they reach the market. Right now, Nokia is the only manufacturer that consistently requires JV certification for embedding apps on their devices.

    Do any other of you find themselves in this situation?

    Nokia added an extra checklist which extends the UTC by 5 simple test criteria. These 5 criteria cost more to test than the ~36 criteria found in the UTC, which is simply ridiculous.

    In short, it doesn’t really help us to gain the Trusted Status if it cannot be extended to the Nokia Test Criteria. Moreover as the test houses say they are not able to test Nokia TC separately from UTC checklist.

    So isn’t this an obvious reason to extend the Trusted status to this checklist as well?
    Since Nokia is a part of UTI and they are one of the major manufacturers to still produce a large amount of Java phones, they should really consider this aspect.

    Our aim is to provide TRUSTED quality apps for Nokia users. For that we need your help.We’ve proven over the years that we are fit to assure the UTC quality standards and the Nokia values without having to externalize testing.

    Thanks in advance for your feedback!

  13. Felipe Pontes says:

    Hi all. My two cents…

    I’m glad to know that Java Verified signing is turning into a more agile process.
    I also think 100% free errors applications is impracticable. Maybe an ideal rate will just be achieved in practice but 95% seems to be acceptable. A good practice would be to classify each JV test as critical or non-critical. A critical test that isn’t ok is capable of reject an application. A non-critical test just reduces in 1% the accuracy of application.
    However, I have a doubt. If a test house is taken away from the process who will verify that an application is ok?

    Best regards.
    Felipe Pontes

    • Interesting suggestions. Thanks. The feedback so far from a lot of people seems to be pointing to the possible need to look at the UTC tests. The idea of dividing them into ‘critical’ and ‘non-critical’ is certainly something worth considering. We’ll open another post on this as it would be good to get some ideas of specifics from you all, based on your experience. To answer your question about who will verifiy that an application is OK, apps from Trusted Developers will be audited via Java Verified – see FAQ sheet. We’ve yet to work out how many should be audited from each developer but have some thoughts on this. The objective is to maintain the high quality level of Java ME (Java Verified-approved) apps out there but make it cheaper for developers to achieve the Java Verified status. The auditing of apps is a really important part of the whole process. Any specific thoughts on this would be gratefully received.

  14. Anthony says:

    Hmm. I can’t see many people really biting on this. Seems like yet another scam to extort money from developers for a broken and dying platform.

    Java is not really the application development platform of the future anymore – that ship has sailed. With Java now in Oracle’s hands, the impetus to continue to with the language will fade faster than it is now.

    I’ve worked a lot in J2EE, and don’t get me wrong, it’s a great platform but JME is and will remain broken and craptacular for a long time, it certainly isn’t destined to return to relevance any time soon. Perhaps that’s why Oracle felt the need to sue Google over Dalvik, hmm?

    What I find pretentious is simply stating “maintaining the high quality of Java ME apps out there” as a goal. First, you need a high quality Java ME platform – and you don’t have one.

    • Thanks for your input. Firstly, the Java Verified programme (and the independently-run Unified Testing Initiative in which it sits) doesn’t get involved in the platform. It’s simply interested in maintaining the quality of Java ME apps. And now we’re going to be rewarding developers who constantly meet this quality bar.

      So I’m not sure why you’re saying it “Seems like yet another scam to extort money from developers”. It’ll cost them around 1 dollar per app plus the cost of taking the agreed number of audited apps through audited testing through an approved test house. Java Verified is about getting Java ME apps out there that reach a certain quality level. If they reach that level they get the Java Verified approval. That’s it. We’d like to hear more thoughts on this.

      We acknowledge that there are issues and that the Java platform is fragmented. It is however still a high volume platform out there in customers’ hands and quality applications are in demand. The core issues are complex, and other groups are looking into that. However we at Java Verified are doing as much as we can to maintain a level of quality for applications at an affordable cost.

  15. Stuart Scott says:

    Feedback on the requested comments
    ====================================
    1) Have a declaration that the Developer will code applications that comply to the UTC. This is analogous to the processes used for other platforms whereby developers agree to ‘play to the rules’.

    2) Don’t base Developer selection off previous submission experience, as you will bias selection to those who are best funded/experienced. That isn’t conducive to level playing fields.

    3) Keep the application price the same for all companies. Build the audit cost into the pricing here and be really transparent about this. Consider re-audit fees which are payable if the pass rate (or similar) is too low – just a little bit of ‘stick’ here. Have re-audits assess only the areas of previous fail to keep the costs down for all.

    4) Don’t audit test to 100% pass on the UTC: there are grey areas in all subjective testing (e.g. FN13, CO4 are classic areas). Consider grading Developers based on how good they are.

    5) Publish the audit results: try to be open about who is good and who is bad. That will incentivise Developers to run good test processes.

    6) Put a timed re-submit into failure cases. Bear in mind that some Developers need to seek approvals from customers, people have holidays and so on, so don’t make the window too small.

    7) Build the ability to upgrade applications into the entire submission process – do this as an option initially but mandate it later. Application software is a journey, not a destination – and should be treated as such. Everyone has access to server infrastructure that can support this – look at making Java update code freely available.

    Comment on Java machines
    ===================
    A massive problem is the lack of real-world data on Java machines. The fact that machine implementations are seemingly unregulated is an issue. When firmwares change, Java machines can change. Some of the manufacturers are good with data, and we like them – others provide data that is so far off the mark that the spec sheets are completely worthless. Almost as if they don’t care about Java machines. An authoritative database of benchmarked Java machines would be incredibly useful to the industry and completely help the ecosystem: testing applications to extremes on Java Machines that are inherently poor has never impressed me much. It would save a huge amount of time and money for developers if Java machine performance was openly recorded.

  16. Located your website via google the other day and absolutely like it. Keep up the truly amazing work.

  17. This is great news that JV starts to change something.

    Considering the following:
    Any tests don’t give 100% confidence. If an application has any errors then it’s trouble of a developer and his customer. Signed MIDlet gives an additional ease of handling for a consumer, but the consumer selects the security level. Any custom property into jad or response from the server can change any process in the application, like as change a host of server or a phone number for SMS.

    Suggest:
    A developer creates and tests his MIDlet.
    The Java Verified Portal has to check MIDlet (jar and jad) in line with the standard J2ME. Then it signs and saves all for the developer. Also it needs for the trial between consumers and the developer. The decision of the court in the future has to be considerated.
    The price depends on how much the portal needs to support services.
    The rest is additional services for an additional fee: test by any accredited Java Verified test houses; information for the curt; an Application Store with feedback; etc..

  18. Stumbled on your blog post via google the other day and absolutely like it so much. Carry on this fantastic work.

  19. Having gone through the process of developing a J2ME app (Drum Box) and marketed it on Nokia’s OVI and Sony Ericsson’s Play Now Arena. I have a few sugestions to make.

    Background Information
    —————————-

    1. App stores tend to do testing. So while UTC is certainly very useful in development and design of apps, the Java Verified testing is not very useful: there are so many handsets with varying specs, that Java Verified’s testing could not possibly have any meaning.

    2. Apps that need to access certain phone features (file API, contacts….) are only useable when signed. Failure to sign an app means that the user keeps on having to confirm a dialog. This can be extremely frustrating when browsing for a location to save a file.

    3. The current state of certificates is really poor. Firstly to support as many phones as possible it is necessary to purchase 2 certificates, one from Verisign and one from Thawte. The certificates’ lifespan is set at one or two years, and quite expensive. This is totally unsatisfactory, customers who purchase a signed app should be able to use the app for as long as they wish.

    I would really like to see Java Verified as a cheaper alternative to these expensive certificate issuers:

    - Have the developer submit an app, Java Verified checks the API access in the JAD, and signs it. It could be for a small fee for each submission. So I would pay to sign version 1.0, and pay again to sign version 1.01

    - The signed app does not time out, or if it does, ten years or so would be a good compromise.

    In essence Java Verified would allow customers to know what company developed the app (it’s in the certificate).

    Should the app be of poor quality, or not work on certain models, the app stores can, and do find this out.

    • Many thanks.
      Just to clarify a couple of things:
      Java Verified certainly addresses the issues mentioned about other certificate providers. For example Java Verified’s certificate is ten years and R&D signing is free.

      In addition we offer a transportable testing statement that is valid at Ovi and Play Now as well as many operator stores. This means that the app submitted with JV to Ovi (for example) are fast tracked and not necessarily re-tested.
      It may still need some additional tests depending on circumstances, but Java Verified is an agreed common quality level that has had the input of many of the relevant app stores.

      In addition we continue to tie the testing and identity together to aid a more efficient process for developers and app shops/ handset manufacturers / operators.

      So, when you talk about how you’d ‘really like to see Java Verified as a cheaper alternative to these expensive certificate issuers’, with the introduction of Trusted Status, we’re aiming to be just that.