Community
Participate
Working Groups
I suggest to cover all relevant documentation for preferences and batch compiler options in this bug. One recent candidate: bug 408815
I have added the new APIs (including VERSION_1_8 related) to the documentation. I happened to look at this page and wondering if this is outdated: eclipse.platform.common/bundles/org.eclipse.jdt.doc.user/reference/preferences/java/ref-preferences-compiler.htm Esp. the default values shows compliance level at 1.4 etc. But if Eclipse must be run with a 1.7 JRE or above, the default compliance that the preference page will have is 1.7, no?
(In reply to Jay Arthanareeswaran from comment #1) > I have added the new APIs (including VERSION_1_8 related) to the > documentation. > > I happened to look at this page and wondering if this is outdated: > > eclipse.platform.common/bundles/org.eclipse.jdt.doc.user/reference/preferences/java/ref-preferences-compiler.htm > > > Esp. the default values shows compliance level at 1.4 etc. But if Eclipse > must be run with a 1.7 JRE or above, the default compliance that the > preference page will have is 1.7, no? No. The default is to match the selected default JRE. Note though, that 'Restore Defaults' only works once per session.
(In reply to Dani Megert from comment #2) > No. The default is to match the selected default JRE. Note though, that > 'Restore Defaults' only works once per session. See bug 467582.
(In reply to Dani Megert from comment #2) > No. The default is to match the selected default JRE. Note though, that > 'Restore Defaults' only works once per session. I understand that. I wasn't clear enough in my previous post. Considering that 1) Eclipse needs 1.7 or above JRE to run (and) 2) The compliance matches the JRE that eclipse is running with We can never have default compliance levels mentioned (like 1.4), can we? I know this page reflects what we have in JavaCore#COMPILER_COMPLIANCE and such, but the question arises because the page mentions "Java compiler preference page".
(In reply to Jay Arthanareeswaran from comment #4) > (In reply to Dani Megert from comment #2) > > No. The default is to match the selected default JRE. Note though, that > > 'Restore Defaults' only works once per session. > > I understand that. I wasn't clear enough in my previous post. Considering > that > > 1) Eclipse needs 1.7 or above JRE to run (and) > 2) The compliance matches the JRE that eclipse is running with > > We can never have default compliance levels mentioned (like 1.4), can we? Yes, we can! Just set a 1.4 JRE as default JRE and then press 'Restore Defaults' on the 'Compiler' preference page.
Was this fixed for RC2? Or should target be changed?
I still need to document two new options of the batch compiler.
Via http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=2bd6646bf3c3ba77fd1bdaf335edf3117b4bd542 I added -syntacticAnalysis -annotationpath I noticed two remaining issues, though: (1) Option -genericsignature is not yet documented. When looking for the right place to add this I got confused by finding -parameters under debug options, not "advanced" like it says from "ecj -help". (2) In messages.properties (batch), the "+" in switchDefault + switch statement lacking a default case looks wrong to me. Help says "-". See that - CompilerOptions.MissingDefaultCase is not in IrritantSet.COMPILER_DEFAULT_WARNINGS - JavaCore.COMPILER_PB_SWITCH_MISSING_DEFAULT_CASE says "ignore" Back to you, Jay.
(In reply to Stephan Herrmann from comment #8) > I noticed two remaining issues, though: Released these via: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=07f3553d1e9689a574bc4693e9815d797bfedcbd and http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=bd3799a3dab4c0b3668799478be6f3a2e32ded2f > (1) Option -genericsignature is not yet documented. When looking for the > right place to add this I got confused by finding -parameters under debug > options, not "advanced" like it says from "ecj -help". I have decided to leave -parameters untouched but put -genericsignature under advanced section.
And I think this can be closed now.
(In reply to Jay Arthanareeswaran from comment #9) > (In reply to Stephan Herrmann from comment #8) > > I noticed two remaining issues, though: > > Released these via: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=07f3553d1e9689a574bc4693e9815d797bfedcbd This change is causing a test failure: http://download.eclipse.org/eclipse/downloads/drops4/I20150602-2000/testresults/html/org.eclipse.jdt.core.tests.compiler_win32.win32.x86_7.0.html
(In reply to Jay Arthanareeswaran from comment #11) > This change is causing a test failure: > > http://download.eclipse.org/eclipse/downloads/drops4/I20150602-2000/ > testresults/html/org.eclipse.jdt.core.tests.compiler_win32.win32.x86_7.0.html Of course, the fix is a test-only fix. Will keep it handy and release if we have any rebuild requests.
(In reply to Jay Arthanareeswaran from comment #12) > Of course, the fix is a test-only fix. Will keep it handy and release if we > have any rebuild requests. Released now: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=66a32f13ddaba4c17740acde6cdc3c8efe41bd5a
For the records, this file should also have been updated for new options: /org.eclipse.jdt.core/scripts/ecj.1
(In reply to Markus Keller from comment #14) > For the records, this file should also have been updated for new options: > /org.eclipse.jdt.core/scripts/ecj.1 Is there a bug to do this for master and SR1?
(In reply to Dani Megert from comment #15) > (In reply to Markus Keller from comment #14) > > For the records, this file should also have been updated for new options: > > /org.eclipse.jdt.core/scripts/ecj.1 > > Is there a bug to do this for master and SR1? Raised follow up bug 470930
