Thanks Michael. I think with this way, you need the proper JRE installed for the execution environment selected, otherwise, if you don’t map an exact version of the JRE, it will only check the “core language” features correctly but not API. Installing the exact matching JRE indeed seems safer and more natural (and doesn’t depend on PDE). Using "API Tools Execution Environment Descriptions” from PDE, you don't need each JRE to be installed but you need API Tooling enabled (and a plugin project) and you still need to configure conformance check from JDT correctly to validate core language features. Both ways work but I believe Alexander was in neither situations hence no errors (Java 8 was mapping to a Java 11 installation and no API Tooling enabled).
Marc-André > On Aug 23, 2020, at 10:07 AM, Michael Keppler <michael.kepp...@gmx.de> wrote: > > In Workspace preferences > Installed JREs add a Java 8 JRE. > In Workspace preferences > Installed JREs > Execution Environments make sure > that your wanted Java 8 JRE is mapped to Java 8 execution environment. > > Then in the project properties of each Java 8 project, use > Java Compiler > Enable project specific settings => true > Java Compiler > Use compliance from execution environment 'Java-SE 8' on the > Java Build Path => Checked > > Commit the resulting ./settings/*.prefs (eventually you want to remove all > other lines than the 3 referring to the compiler level). Side note: Don't > ever use the global workspace preferences to set the wanted Java level. That > way your bundles will compile differently when someone else checks out your > project in his/her local workspace. You may even want to configure your > workspace preferences to be Java 1.3, so you immediately get warnings/errors > for any bundle that doesn't have the "project specific settings" checkbox > checked. > > This way you can have an arbitrary mix of Java 5 to 15 bundles in the same > workspace and each of them compiles only with the selected level, and the > editor only suggests the available methods and types. Finally, you can remove > all unused (i.e. probably all different than 8 and 11) JREs from Preferences > > Installed JREs to reduce the number of duplicate types in the "Open type" > dialog (where you have one occurrence per bound execution environment). > > To my knowledge, PDE doesn't need to be configured in any way to cope with > the different Java levels, if the above settings have been done for JDT. > > Ciao, Michael > > PS: In the case of _all_ bundles of a project requiring Java 8, you could > also configure your project Oomph setup to set Java 8 in the workspace > preferences. However, you would then rely on every contributor actually using > Oomph, and my experience shows that's not the case (even though that simple > solution would be completely sufficient then, without modifying the project > settings). > > Gesendet: Sonntag, 23. August 2020 um 10:48 Uhr > Von: "Alexander Fedorov" <alexander.fedo...@arsysop.ru> > An: cross-project-issues-dev@eclipse.org > Betreff: [cross-project-issues-dev] How to identify Java 11 usages for > bundles with JavaSE-1.8 BREE? > Hello, > > Currently Eclipse Platform requires Java 11 while a lot of downstream > bundles would prefer to stay on Java 8 for a while. > This leads to a situation when workspace has Java 11 classpath and Java > 11 methods are visible for Java 8 bundles. > > What is the right way to configure JDT and PDE to not accept Java 11 > usages for Java 8 projects? > > Thanks, > AF > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>_______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To 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 unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
