Should we be so strict on maintaining backwards compatibility?

[Richard Bair]

Ya, that's spot on. Compatibility and Security are at fundamental odds with each other in the Applet / WebStart deployment scenario.

On May 15, 2012, at 4:48 AM, Daniel Zwolenski wrote:

> As I understand it, the reason we have auto-updating as a requirement and
> (currently) no way to pin versions is because of Applet/Plugin security
> issues. Users are forced to update whether they want to or not to prevent
> security holes - this is by design.
> 
> If Java 8 Modules will allow us to pin to versions as Tom says, then what
> happens to this security requirement?
> 
> There seem to be conflicting elements to this auto-updating tale.
> 
> 
> On Tue, May 15, 2012 at 9:29 PM, Tom Schindl <tom.schindl at bestsolution.at>wrote:
> 
>> Hi,
>> 
>> I agree in general but I'd like to mention once more that with Java-8
>> this problem is much smaller because you'd define version ranges on your
>> own product which have to match.
>> 
>> As I understood the new Java module system you can have multiple version
>> of e.g. JavaFX installed next to each other:
>> * javafx 2.2.0
>> * javafx 2.2.1
>> 
>> If you specify no upper bound you'll always the get the one with the
>> highest version beside that I agree that by JavaFX joining the OpenJDK
>> the project can't act as agile as it does at the moment with preview
>> builds, ... (we've all seen the first signs of this by "No zips download
>> for 2.2 even if the mac build has no JavaDoc attached") but I once more
>> hope that this will change a bit with the use of a java module system.
>> 
>> Tom
>> 
>> Am 15.05.12 02:05, schrieb Daniel Zwolenski:
>>> With auto-updates then we have absolutely no choice in the matter. We
>> must
>>> be 100% backwards compatible at all times otherwise a perfectly
>> functioning
>>> system one day is cactus the next without anyone doing anything. I would
>>> argue this goes down to look and feel too - things like mouse click
>> dismiss
>>> behaviour, fixes to css styling, etc. Nothing must ever break.
>>> 
>>> If we had a deployment solution that allowed developers to pin their code
>>> to a certain Java/JFX version then I agree with the idea that minor
>> version
>>> changes should be backwards compatible, whereas major versions can have
>> an
>>> upgrade path. Allows for improvements over time, instead of Swing's keep
>> it
>>> stuck in the 80's until it is so dated it has to be killed and replaced.
>>> 
>>> Another (even better) alternative is a (not so popular) one I've raised
>>> earlier: decouple JFX from the JRE into a normal Java library that gets
>>> added-on. Maybe the core native window/rendering stuff (prism or glass or
>>> whatever the root building blocks are) should be part of the JRE (and so
>>> always are backwards compatible), but all the Control, CSS, Animation,
>>> Chart, etc stuff could/should all be libraries in my opinion. Still
>>> published by Oracle, still owned/worked on by the same teams - just
>>> packaged separately, and so allowing a separate release/version path and
>>> pace. Backwards compatibility issues get reduced to the normal challenges
>>> in this area and releases can happen at times that make sense to the JFX
>>> team, not dictated by the slower, more cumbersome JRE process.
>>> 
>>> 
>>> 
>>> On Tue, May 15, 2012 at 6:02 AM, Slavko Scekic <scekics at gmail.com>
>> wrote:
>>> 
>>>> And what do you think, what changes would be worth breaking the
>> backwards
>>>> compatibility for?
>>>> 
>>>> On Mon, May 14, 2012 at 9:22 PM, Pedro Duque Vieira <
>>>> pedro.duquevieira at gmail.com> wrote:
>>>> 
>>>>> Yes, that's true. Kirill was a proponent of breaking backwards
>>>>> compatibility. I used his libraries a lot: flamingo, substance, etc and
>>>> for
>>>>> each release I had to do some migration.
>>>>> My experience with Kirill's libraries tells me that breaking backwards
>>>>> compatibility is worse it. Having wrong decisions plaguing the next
>>>>> releases is far worse. It was a bit of a pain to migrate, but one worse
>>>>> enduring.
>>>>> 
>>>>> I think changes should be made as quickly as possible if we wait till
>> the
>>>>> next major release, the migration step will be worse, and the
>>>> errors/wrong
>>>>> decisions will accumulate into a worse problem each release.
>>>>> 
>>>>> 
>>>>> Kirill asked that same question a long time ago for his Substance
>> library
>>>>>> and it is a very valid one. Like then I would vote to maintain
>>>> backwards
>>>>>> compatibility in all minor release, but allow for well considered
>>>>> breaking
>>>>>> on major releases (I have a candidate already BTW ;-). This would also
>>>>>> prevent the stacking over all releases; design decisions from Java 1.0
>>>>> are
>>>>>> still plaguing 7.0.
>>>>>> Tom
>>>>> 
>>>>> --
>>>>> Pedro Duque Vieira
>>>>> 
>>>> 
>> 
>> 
>> --
>> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
>> ------------------------------------------------------------------------
>> tom schindl                 geschäftsführer/CEO
>> ------------------------------------------------------------------------
>> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
>> http://www.BestSolution.at                      phone    ++43 512 935834
>>