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@eclipse.org
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@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev