Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 458005

Summary: Provide a mechanism for disabling file system natives so that Java 7 filesystem.java7 classes can be tested
Product: [Eclipse Project] Platform Reporter: Sergey Prigogin <eclipse.sprigogin>
Component: ResourcesAssignee: Sergey Prigogin <eclipse.sprigogin>
Status: VERIFIED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: daniel_megert, david_williams, sptaszkiewicz
Version: 4.5   
Target Milestone: 4.5 M6   
Hardware: All   
OS: All   
See Also: https://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=a67f4073371a55594176733673315f38b30d3b7f
https://git.eclipse.org/r/41348
Whiteboard:

Description Sergey Prigogin CLA 2015-01-20 22:58:58 EST
LocalFileNativesManager uses filesystem.java7 classes only when UnixFileNatives.isUsingNatives and LocalFileNatives.isUsingNatives() both return false. This makes testing of filesystem.java7 classes very hard.

It makes sense to provide a mechanism for disabling file system natives so that Java 7 filesystem.java7 classes can be tested.
Comment 1 Sergey Prigogin CLA 2015-01-20 23:21:13 EST
A proposed solution is in https://git.eclipse.org/r/#/c/39998/
Comment 3 Szymon Ptaszkiewicz CLA 2015-02-06 10:19:55 EST
Thanks, Sergey!
Comment 4 David Williams CLA 2015-02-07 00:34:07 EST
Caused compile error in 

http://download.eclipse.org/eclipse/downloads/drops4/N20150206-2000/

With a 1.4 BREE, I you need to use 
 Boolean.getBoolean 
instead of 
 Boolean.parseBoolean

[I'm sure you don't need me to remind you to set up your IDE to have and EE for the various versions of Java :) ]
Comment 5 Eclipse Genie CLA 2015-02-07 01:07:26 EST
New Gerrit change created: https://git.eclipse.org/r/41348
Comment 6 Dani Megert CLA 2015-02-07 03:11:28 EST
(In reply to Eclipse Genie from comment #5)
> New Gerrit change created: https://git.eclipse.org/r/41348

It's a separate discussion/request whether we would want to change the compiler compliance. Looking at the setup it looks strange that we don't use the compliance from the execution environment (BREE).


Fixed with http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=beb9b52e4671ed1d704e5b63457e483d1a556db8
Comment 7 David Williams CLA 2015-02-07 11:43:14 EST
(In reply to Dani Megert from comment #6)
> (In reply to Eclipse Genie from comment #5)

> It's a separate discussion/request whether we would want to change the
> compiler compliance. Looking at the setup it looks strange that we don't use
> the compliance from the execution environment (BREE).

I'm not sure what you mean by this. When I look at it, the BREE says 1.4. The project does not have the *default* check boxes marked, but I think that just means it still uses 1.4, though out, for source compatibility and in producing binary bits. Unless the dev. env. doesn't have a 1.4 VM associated with the 1.4 BREE -- then the "workspace default" is used. (Probably 7 or 8 for most developers?) 

Guess I'm asking to know if there is confusion over my remark. -- I just meant that committeers/contributors should to set their preferences to have a VM associated with (at least) BREE 1.4, 1.5, 1.6, 1.7, and 1.8. Then they would have seen the error in their dev. environment. 

I guess another question is why doesn't Gerrit have the "toolchains" defined, then I think Gerrit would have caught the error. Oh, looking at it just now, looks that project on Gerrit doesn't have a "build step/pass" configured for Gerrit? So, maybe it does have toolchains defined? and this patch was not "built" on Gerrit. 

Sorry to be off topic.
Comment 8 Sergey Prigogin CLA 2015-02-07 19:34:09 EST
(In reply to Dani Megert from comment #6)
> Looking at the setup it looks strange that we don't use
> the compliance from the execution environment (BREE).

Patch https://git.eclipse.org/r/#/c/41369/ for bug 459373 addresses this issue.
Comment 9 Szymon Ptaszkiewicz CLA 2015-02-11 07:52:28 EST
Verified in I20150210-0800.