Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 347503 - [DOM] ASTParser.setEnvironment() ignores includeRunningVMBootclasspath parameter
Summary: [DOM] ASTParser.setEnvironment() ignores includeRunningVMBootclasspath parameter
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.7.1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-27 15:08 EDT by Tom Ball CLA
Modified: 2011-08-05 02:54 EDT (History)
4 users (show)

See Also:

Attachments
Proposed fix (849 bytes, patch)
2011-05-27 15:22 EDT, Olivier Thomann CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Ball CLA 2011-05-27 15:08:28 EDT 
Build Identifier: M20110210-1200

ASTParser.setEnvironment() has a includeRunningVMBootclasspath parameter so the running VM's bootclasspath isn't used when parsing.  However, this parameter isn't referenced, and instead this always runs:

        this.bits |= CompilationUnitResolver.INCLUDE_RUNNING_VM_BOOTCLASSPATH;

Suggested patch:

    if (includeRunningVMBootclasspath) {
        this.bits |= CompilationUnitResolver.INCLUDE_RUNNING_VM_BOOTCLASSPATH;
    }


Reproducible: Always

Steps to Reproduce:
Open org.eclipse.jdt.core.dom.ASTParser, and code-review its setEnvironment method.
Comment 1 Olivier Thomann CLA 2011-05-27 15:22:04 EDT 
Srikanth, this looks too late for RC4. Targeting 3.7.1 ?
Comment 2 Olivier Thomann CLA 2011-05-27 15:22:20 EDT 
Created attachment 196804 [details]
Proposed fix
Comment 3 Tom Ball CLA 2011-05-27 15:26:56 EDT 
(In reply to comment #2)
> Created attachment 196804 [details]
> Proposed fix

Wow, that was fast triage!  Thanks.

FWIW, I have an ugly workaround, so there's no rush:

        Field field = parser.getClass().getDeclaredField("bits");
        field.setAccessible(true);
        int bits = field.getInt(parser);
        // Turn off CompilationUnitResolver.INCLUDE_RUNNING_VM_BOOTCLASSPATH
        bits &= ~0x20;
        field.setInt(parser, bits);
Comment 4 Olivier Thomann CLA 2011-05-27 15:32:49 EDT 
> FWIW, I have an ugly workaround, so there's no rush:
> 
>         Field field = parser.getClass().getDeclaredField("bits");
>         field.setAccessible(true);
>         int bits = field.getInt(parser);
>         // Turn off CompilationUnitResolver.INCLUDE_RUNNING_VM_BOOTCLASSPATH
>         bits &= ~0x20;
>         field.setInt(parser, bits);
This is exactly why I'd like to get it fixed asap :-).
Fix is trivial and there is no risk, but the rules are pretty strict at this point.
Daniel, what is your take on this one ?
Comment 5 Dani Megert CLA 2011-05-30 04:13:39 EDT 
(In reply to comment #4)
> > FWIW, I have an ugly workaround, so there's no rush:
> > 
> >         Field field = parser.getClass().getDeclaredField("bits");
> >         field.setAccessible(true);
> >         int bits = field.getInt(parser);
> >         // Turn off CompilationUnitResolver.INCLUDE_RUNNING_VM_BOOTCLASSPATH
> >         bits &= ~0x20;
> >         field.setInt(parser, bits);
> This is exactly why I'd like to get it fixed asap :-).
> Fix is trivial and there is no risk, but the rules are pretty strict at this
> point.
> Daniel, what is your take on this one ?

Is it a regression compared to 3.6? If not -> 3.7.1.
Comment 6 Olivier Thomann CLA 2011-07-07 14:02:22 EDT 
Released in BETA_JAVA7 branch. Since this branch will be our 3.7.1 contents, this is fine.
Comment 7 Curtis Windatt CLA 2011-07-20 15:21:43 EDT 
Verified.  The fix in the BETA_JAVA7 brach is simple and correct.