>> None of these points are suggesting the problem is with WebStart's
>> implementation, they all hold even if WebStart were completely bug free.
>> They're just the natural side-effect of a shared install system.
> Actually, one of the best things of Java is that in like 99.9% of the cases,
> m
On 3/09/2013 20:34, Richard Bair wrote:
I would strongly recommend leaving the shared JRE install world behind.
As a suggestion, try JWrapper - we have flawless installs now, even using an
OSGI deployment procedure! Bundled JVMs are really the only dependable way to
go now it seems?
If my bus
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
When you have a new version of your app to distribute, you would repackage it
using the same tool you did before - maybe specifying a new JVM target (if you
would like to update the JVM that gets bundled with the app). Then upload your
app to the Apple App Store and voila' :) (Ok so there's the
The user has downloaded an app -- they have established and explicit trust
relationship similar to any other native app by choosing to execute it. For
apps distributed through the apple store (for desktop, the same as mobile) the
update will happen via the store instead of directly over the air.
> I would strongly recommend leaving the shared JRE install world behind.
As a suggestion, try JWrapper - we have flawless installs now, even using an
OSGI deployment procedure! Bundled JVMs are really the only dependable way to
go now it seems?
David
On Sep 3, 2013, at 1:23 PM, Richard Bair
>> I would strongly recommend leaving the shared JRE install world behind.
>
> As a suggestion, try JWrapper - we have flawless installs now, even using an
> OSGI deployment procedure! Bundled JVMs are really the only dependable way to
> go now it seems?
If my business were betting on it, I'd n
Yes you can use the -XDignore.symbol.file flag.
On Sep 3, 2013, at 11:48 AM, Tom Schindl wrote:
> Really is there not even a flag to make compiler do this? I don't get hit by
> this because i'm building with ejc but i'm accessing com.sun javafx classes
> quite frequently.
>
> Tom
>
> Von mei
By "we" I meant the place where I work… (not JWrapper Inc.)! :)
David
On Sep 3, 2013, at 1:28 PM, David Ray wrote:
>> I would strongly recommend leaving the shared JRE install world behind.
>
> As a suggestion, try JWrapper - we have flawless installs now, even using an
> OSGI deployment p
But this puts the task to update the jre in the hands of the developer, no?
This would be very insecure in my opinion then.
Cheers,
Mario
Il giorno 03/set/2013 20:36, "Richard Bair" ha
scritto:
> >> I would strongly recommend leaving the shared JRE install world behind.
> >
> > As a suggestion,
On Sep 3, 2013, at 11:23 AM, 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
>
Really is there not even a flag to make compiler do this? I don't get hit by
this because i'm building with ejc but i'm accessing com.sun javafx classes
quite frequently.
Tom
Von meinem iPhone gesendet
Am 03.09.2013 um 20:26 schrieb Richard Bair :
>
> On Sep 3, 2013, at 11:23 AM, Richard Bai
> 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.
Mario Torre wrote:
In this case, since JavaFX is Free Software! you can actually suggest
the fix, prototype and propose the patch yourself, limiting the round
trip time substantially.
This also increases the chances to get a better fix in the end, since
more eyes are focusing on it.
Cheers,
Mar
On Tue, 03 Sep 2013 17:49:10 +0200, Richard Bair
wrote:
Or, when co-bundling the JRE with your app, you can provide whatever
workaround you need to your copy of the JRE (just remove final from a
few places or whatnot). Of course the cost comes when you need to
upgrade to a newer version
>> Final methods more so take the control out of the hands of the many
>> developers, and places it in the hands of the API designers.
>> If there is an issue, and demands are high - would we rather
>>
>> A. Report the issue and wait for the original API designer's development
>> process to ack
On Tue, 2013-09-03 at 10:19 -0500, David Ray wrote:
> Final methods more so take the control out of the hands of the many
> developers, and places it in the hands of the API designers.
> If there is an issue, and demands are high - would we rather
>
> A. Report the issue and wait for the origina
Final methods more so take the control out of the hands of the many developers,
and places it in the hands of the API designers.
If there is an issue, and demands are high - would we rather
A. Report the issue and wait for the original API designer's development
process to acknowledge, repair,
On Tue, 2013-09-03 at 08:34 +0200, Fabrizio Giudici wrote:
> On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink wrote:
>
> > AFAIK there was never a framework that used final a lot, so time will
> > tell if the choice was right. Swing and the JDK made it this far. But
>
> The NetBeans Platform A
On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink wrote:
AFAIK there was never a framework that used final a lot, so time will
tell if the choice was right. Swing and the JDK made it this far. But
The NetBeans Platform API does use final a lot for the same rationale
we're discussing now.
On 2013-09-02 21:01, Richard Bair wrote:
you have to think about the combinations of all things allowed by a developer.
Since it is impossible to think of and design upfront for all possible usages,
and impossible to write error free code, I'm not sure I agree with the approach
chosen. Immut
> This applies only to the perfect (final) framework.
> In other words for a framework without bugs and a framework, where all
> possible usecases are considered by its author.
>
> I agree that there are dangers, when overwriting methods. But in my
> experience they rarely matter. Once created
Fabrizio Giudici wrote:
On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt
wrote:
I agree with that and I also recommend to have a look at "Item 17:
Design and document for inheritance or else prohibit it" from
Effective Java.
http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2n
On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt
wrote:
I agree with that and I also recommend to have a look at "Item 17:
Design and document for inheritance or else prohibit it" from Effective
Java.
http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.300
non-final design quite well.
Christian
Am 02.09.2013 um 10:36 schrieb Artem Ananiev:
>
> As Jonathan said, Richard is the best person to answer this question, but let
> me provide my own thoughts below as well.
>
> On 9/2/2013 3:55 AM, Pedro Duque Vieira wrote:
>> Hi,
>
As Jonathan said, Richard is the best person to answer this question,
but let me provide my own thoughts below as well.
On 9/2/2013 3:55 AM, Pedro Duque Vieira wrote:
Hi,
Why is almost everything in the API final? OK, I understand there is a
security problem and not making things final
athan
On 2/09/2013 11:55 a.m., Pedro Duque Vieira wrote:
> Hi,
>
> Why is almost everything in the API final? OK, I understand there is a
> security problem and not making things final could potential open security
> holes.
> What I'm puzzled about is that the rest of the
Hi,
Why is almost everything in the API final? OK, I understand there is a
security problem and not making things final could potential open security
holes.
What I'm puzzled about is that the rest of the JDK doesn't use this pattern
and so I wonder if it is still effective this way?
28 matches
Mail list logo
