HEADS UP: Switched to 1.8 source/target in build (in graphics repository).

[Danno Ferrin]

On Tue, May 7, 2013 at 9:57 AM, Richard Bair <richard.bair at oracle.com>wrote:

> > People using Eclipse as their IDE will not have fun with that I guess
> because their IDE will not compile the code anymore, so one can't use
> Eclipse anymore to provide patches - nothing you really care I guess.
>
> Steve, Felipe, or Jonathan would have to comment on what this does to them
> I guess -- they all use Eclipse for development.
>
> > I don't argue that you should not do this because Eclipse does not yet
> support it (which is a shame for Eclipse) but you are excluding other VMs
> who don't support those concepts - most notable invoke dynamic - this makes
> a community port of JavaFX to iOS fairly impossible.
>
> I think it would be fairly easy to just filter out those classes and
> replace the ObservableList with a version that doesn't have the defender
> methods. We had to do such things to make JavaFX mobile work back in the
> day. It is a short term problem because VMs and IDEs are going to move
> forward.
>

Yes, the fork could just replace it with a static method in a helper class
where the first  ar is the "this", which of course causes problems since it
cannot be overriden   Then one could make a <foo>8 interface and just do
the defender logic at the call site.  This works for a fork only if N is
small, where the value of N has a direct correlation to the determination
to make it work.