Re: [cross-project-issues-dev] User-friendly Eclipse platform for evolvi

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I'm not convinced these two discussions don't have the same 'PDE' solution.

It seems to me that a Java-N-supporting Eclipse should have a list of 
legacy Java < N packages that have solutions to enable their ongoing use 
In Java-N. The new solution may be to acquire the package from a variant 
module-path, from a fragment or from Orbit. When PDE / P2 encounters a 
request for a legacy package, it activates the solution. Perhaps some 
legacy packages might need an auto-add-to-classpath or an auto-earlystart.

    Regards

        Ed Willink


On 16/12/2018 16:04, Stephan Herrmann wrote:
> I agree with Ed that there is much room for improvement, or: 
> opportunity to
> help our users.
>
> I suggest to separate 2 discussions for now:
>
> (1) How can Eclipse itself be made more stable to be runnable on more 
> versions of
> Java without hiccups like experienced by Code Recommenders, Mylyn etc?
>
> (2) Can JDT hide Java "eccentricities" from user projects, e.g., can 
> we conjure
> a "java.xml" rabbit out of the hat, even if JRE 11 doesn't provide it 
> any more?
>
>
> Discussion (1) is urgent right now, it is essential for the 2018-12 
> release.
> Some alternatives have been discussed for months. If those discussions 
> have
> not yet converged on a solution that works on Java 10- like 11+ then 
> we seem
> to need improved mechanisms of conditional installation (like: add a 
> bundle
> from Orbit IFF java.version >= 11) - not only during "install new 
> software"
> but also during installing a zipped / tarred package.
>
>
> I'm open to discussing (2) in a JDT bug, although I should add, we are 
> more than
> busy just providing support for each new Java version. Implementing 
> additional
> non-strict modes obviously requires additional efforts, just saying.
>
> best,
> Stephan
>
>
> On 16.12.18 16:19, Ed Willink wrote:
> > Hi
> >
> > The recent "Errors when running 2018-12 RC2 on Java 11" thread is 
> > just one of many 'new'-Java problems.
> >
> > The instability of Java is clearly a major PITA, so that each of Java 
> > 8, 9, 10, 11 has resulted in significant breakages that have 
> > gradually been ameliorated.
> >
> > As a user I see Eclipse as a nice platform that has for many years 
> > hidden the Windows/Linux/MacOS eccentricities. Less obviously, the 
> > platform now nodes to hide the Java 7/8/9/10/11 eccentricities, so 
> > that for the most part an Eclipse application just works. We should 
> > not depend on each project rebuilding with latest-Java workarounds.
> >
> > Currently each new Java eccentricity seems to be accommodated by 
> > dubious workarounds that do not hide the problem from the user. e.g. 
> > I now have to import javax.annotation into each of my test plugins.
> >
> > It seems that we need to offer two options.
> >
> > a) a default Eclipse that maximally hides the Java eccentricities to 
> > give a good user experience. This may require a 're-modularizer' to 
> > counteract Java's incessant migrations.
> >
> > b) -strict Eclipse for those who want to be precisely in tune with a 
> > Java eccentricity.
> >
> >      Regards
> >
> >          Ed Willink
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> > _______________________________________________
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or 
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev