Why is almost everything in the API final

[Stefan Fuchs]

Richard Bair wrote:
>> Wouldn't it be better to allow developers to override methods at 
>> their own risk.
> There's no such thing. When some big customer overrides methods, we 
> have no choice but to support their app for the foreseeable future. 
> Which is why deprecated stuff never could be removed from the JDK as 
> well. And a host of bugs won't be fixed. When the CEO of a customer 
> with a major hardware contract comes knocking -- well, at that time 
> you really wish you had designed the API differently.
So I just must make a major hardware contract, when I want to have a 
final keyword removed

Anyway... if its clearly documented in the API (by an annotation), that 
this method should not have been overwritten by the developers of  CEO 
of a customer with a major hardware contract and they did it anyway 
there is a strong hint, whose fault it was.

But I must admit, that it might not save you in cooperate politics.
>> Yet, those that are willing to take the risks, can do something to 
>> keep their business alive.
> I would strongly recommend leaving the shared JRE install world behind.
>
> Richard
Well, one of the main reasons to invest in JavaFX, was the ability to 
start the application web-like.

We develop a fotobook application for both business and consumer 
customers. (e.g.: available german only at 
http://www.lidl-druckservice.de/)

In the past like most of our competitors we had 2 applications. One was 
a very limited web application (html, javascript, php), the other a 
complex. full featured application in C#.

For our business it is critical to get customers to design their product 
as fast as possible. Many are unwilling or unable (e.g.: in a cooperate 
environment) to install software from semi-untrusted sources.

JavaFx provided us the chance to develop an application from the same 
codebase, which
- has full access to the filesystem (no lengthy picture uploads, before 
design can begin)
- can be started similar to a web-application (via webstart)
- can be installed as a native application
- works on all major desktop platforms
- in the future might run on tablets

Note that we leave our customers the choice between the webstart 
application and the installer version. Webstart gets increasingly 
unreliable due to problems with browsers (e.g.: Firefox currently blocks 
webstart, because of unpatched security problems) and the jre (e.g.: 
last security update killed Swing - luckily we found a workaround (no 
final method was involved :-)) and the problem is hopefully fixed with 
Java 7 u40).

If webstart is no longer a viable choice, we might have to reconsider 
our strategy and develop a html 5 application for the web and tablet use 
cases.

Stefan