Should we be so strict on maintaining backwards compatibility?

[Daniel Zwolenski]

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
>