Bug 375976 - Compile errors in equinox code
Summary: Compile errors in equinox code
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 4.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.2 M7   Edit
Assignee: David Williams CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 355430
  Show dependency tree
 
Reported: 2012-04-03 12:42 EDT by David Williams CLA
Modified: 2012-04-25 16:00 EDT (History)
1 user (show)

See Also:


Attachments
excerpt of log showing compile errors in equinox (2.92 KB, text/plain)
2012-04-03 12:42 EDT, David Williams CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2012-04-03 12:42:30 EDT
Created attachment 213509 [details]
excerpt of log showing compile errors in equinox

While not easy to "see" yet, the test builds on build.eclipse.org are producing compile errors in equinox code, and thought they deserved an "early look". 

I'm assuming related to how the build is being done, but ... maybe are "real" errors?
Comment 1 David Williams CLA 2012-04-03 12:51:00 EDT
Tom, early on in doing test builds  ... like 1 week ago :/ ... due to other problems I thought might be related, but which turn out not to be, I saw, and made changes to how the "bootclasspath" was set up for -DOSGi/Minimum-1.2. 

Was there a reason the "1.2 minimum" was set to "1.1"? Could that be related to these compile errors? At the time, I was assuming it was a "copy/paste error", but now its time to ask you. 

Keep in mind, the compile errors could be from many things ... such as, I am not yet sure we are "pulling in" correct/intended versions, etc. 

But, thought this deserved some "early" attention. 

= = = = 

    bootclasspath_foundation11="/shared/common/org.eclipse.sdk-feature/libs/ee.foundation.jar"
    # was there a reason this was "hard coded" to 1.1? 
    #OSGiMinimum=$bootclasspath_foundation11
    OSGiMinimum="/shared/common/org.eclipse.sdk-feature/libs/ee.minimum-1.2.0.jar"

These variables are later set when we invoke the actual antRunner build. 


        -DJ2SE-1.5=$bootclasspath_15 \
        -DJ2SE-1.4=$bootclasspath \
        -DCDC-1.0/Foundation-1.0=$bootclasspath_foundation \
        -DCDC-1.1/Foundation-1.1=$bootclasspath_foundation11 \
        -DOSGi/Minimum-1.2=$OSGiMinimum \
        -DJavaSE-1.6=$bootclasspath_16 \
Comment 2 John Arthorne CLA 2012-04-03 13:01:58 EDT
The source of those classes (PriviligedRunner and ThreadPoolManagerImpl) haven't changed in at least a year. This smells possibly related to compiler settings, or changes around use of jsr14 flag to compile equinox.

David I suggest meanwhile reverting your change to the bootclasspath. I don't fully understand what this means but maybe we should leave it alone until we understand it ;)
Comment 3 David Williams CLA 2012-04-03 13:25:10 EDT
(In reply to comment #2)

> 
> David I suggest meanwhile reverting your change to the bootclasspath. I don't
> fully understand what this means but maybe we should leave it alone until we
> understand it ;)

Good idea ... now we'll see if next build has more or less errors :)
Comment 4 David Williams CLA 2012-04-03 15:03:36 EDT
(In reply to comment #3)
> (In reply to comment #2)
> 
> 
> Good idea ... now we'll see if next build has more or less errors :)

Same errors:  

http://build.eclipse.org/eclipse/eclipse4/build/supportDir/I20120403-1322/testResults.php
Comment 5 Thomas Watson CLA 2012-04-03 16:22:32 EDT
The bundle org.eclipse.equinox.io specifies a BREE of OSGi/Minimum-1.0 and the bundle org.eclipse.equinox.util specifies a BREE of OSGi/Minimum-1.1.  What I think is happening is that during the build you are building these against a JRE library that includes generic signatures.  This is reproducible in the workspace if you don't configure in the osgi minimum ee jars as execution environments for the workspace.  I think the default is to use Java 5 or Java 6 if the execution environment specified by the bundle is not configured for the build.  I think Kim had configured all OSGi/Minumum versions to simply point to the OSGi/Minumum-1.2 jar.

So I think you need to specify these additional parameters:

-DOSGi/Minimum-1.0=$OSGiMinimum \
-DOSGi/Minimum-1.1=$OSGiMinimum \

Ideally we would use the actual jars for the 1.0 and 1.1 osgi minimum, but for now I think it is good enough to compile against the osgi minimum 1.2 jar here.
Comment 6 Thomas Watson CLA 2012-04-03 16:27:53 EDT
(In reply to comment #2)
> The source of those classes (PriviligedRunner and ThreadPoolManagerImpl)
> haven't changed in at least a year. This smells possibly related to compiler
> settings, or changes around use of jsr14 flag to compile equinox.

These two bundles (equinox.io and equinox.util) are not using the jsr14 flag so that is not the issue.  I am pretty sure it is because these two bundles are being compiled against a jre class library that includes generic signatures.
Comment 7 David Williams CLA 2012-04-03 17:06:14 EDT
(In reply to comment #5)
> I think Kim had configured all OSGi/Minumum versions to simply point to
> the OSGi/Minumum-1.2 jar.

and recall, it now points to "1.1" as of this moment (that was the way I found it). but the 1.2 jar is available. 

> 
> So I think you need to specify these additional parameters:
> 
> -DOSGi/Minimum-1.0=$OSGiMinimum \
> -DOSGi/Minimum-1.1=$OSGiMinimum \
> 

Yes, those are not specified at all, just 

        -DCDC-1.0/Foundation-1.0=$bootclasspath_foundation \
        -DCDC-1.1/Foundation-1.1=$bootclasspath_foundation11 \
        -DOSGi/Minimum-1.2=$OSGiMinimum \  

And I don't see any place buried in scripts where some equality is set ... so, 
as first step, I'll add 

 -DOSGi/Minimum-1.0=$OSGiMinimum \
 -DOSGi/Minimum-1.1=$OSGiMinimum \

and change $OSGiMinimum back to 
OSGiMinimum="/shared/common/org.eclipse.sdk-feature/libs/ee.minimum-1.2.0.jar"
Comment 8 David Williams CLA 2012-04-03 19:24:05 EDT
Thanks to Tom's expert advice the next test run had no compile errors (in equinox). 

I opened bug 376029 to track the "fine tuning" we can do, which is not so urgent as this one.