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
