'Issue' with Eclipse

[Tiago Espinha <ti...@espinhas.net>]

Hey guys, I'm back.

Perhaps some of you still remember me from last year. I applied to GSoC 
on the Apache Derby project and unfortunately ended up not getting 
picked. I still hanged around for a while but I ended up leaving at some 
point. This year I'm back and I'm applying for GSoC again :)

Right now I'm in a bit of a stalemate with an annoying issue that's 
bothering me. I followed all the steps to build Derby's code and to do 
the testing. I am able to build it now and I can also run derbyall with 
no issues (or close to no issues since derbyall skipped derbynetmats, 
jdbcapi and jdbc20). The problem that I am stuck with is actually 
Eclipse-related.

I have sort of imported Derby into Eclipse and I am getting 1559 errors. 
With a quick glance through some of the errors, I notice that some of 
them come from jdbc4 classes, like LogicalCallableStatement40.java . On 
this one I get for example "The method setRowId(int, RowId) is undefined 
for the type CallableStatement" and many more errors.

I remember having something like this last year and it had something to 
do with jdbc4. The problem is that I am clueless as to how to go about 
this. I believe the step-by-step build tutorial I followed last year was 
actually more complete than it is at the moment, and I'm probably 
missing something jdbc4-wise.

If any of you have a hint as to why this is happening, I'd truly 
appreciate it. It's not a complete show-stopper for me but it is 
annoying to have this enormous amount of bugs plaguing my Eclipse.

Thank you for any help,
Tiago Espinha

Re: 'Issue' with Eclipse

[Kathey Marsden <km...@sbcglobal.net>]

Tiago Espinha wrote:
> \
> The way I fixed it at this point, was by going under Java Build Path 
> -> Order and Export and move the JRE System Library item right to the 
> top and also checking it. 
This makes sense to me now.  Recently jdbc3 and jdbc4 stubs were checked 
into the codeline, under java/stubs/... and so the signatures of these 
methods are in the derby jars. So if the jdbc3 stubs were picked up 
before the java libraries, then you would see those errors.

Thanks for figuring this out. Could you update the wiki page with what 
you found?

Kathey

Re: 'Issue' with Eclipse

[Tiago Espinha <ti...@espinhas.net>]

After having picked Kathey's brains trying to find a solution for this
ultimately odd issue, I believe I have come up with a fix.

The key problem was that eclipse would not recognize the methods and
properties that are Java6 specific (stuff such as JDBC4). After having made
sure that I was indeed referencing the correct JDK (1.6) in Eclipse, and
after having even tried it on Linux, I would always get the described
behavior.

The way I fixed it at this point, was by going under Java Build Path ->
Order and Export and move the JRE System Library item right to the top and
also checking it. I tried just checking it and leaving it on the bottom of
the list (bellow Derby's folders) and it would make some errors go away, but
not all of them. Like this it just cleans my code all around, apparently
leaving no errors (at least no JDBC4 ones).

Just thought I'd share this, since with GSoC I'm guessing more people will
run into this issue...

Tiago

On Mon, Mar 16, 2009 at 4:34 PM, Tiago Espinha <ti...@espinhas.net> wrote:

> Myrna van Lunteren wrote:
>
>> On Mon, Mar 16, 2009 at 7:05 AM, Tiago Espinha <ti...@espinhas.net>
>> wrote:
>>
>>
>>> Knut Anders Hatlen wrote:
>>>
>>>
>>>> Tiago Espinha <ti...@espinhas.net> writes:
>>>>
>>>>
>>>>
>>>>
>>>>> Hey guys, I'm back.
>>>>>
>>>>>
>>>>>
>>>> Hi, and welcome back! :)
>>>>
>>>>
>>>>
>>>>
>>>>> Perhaps some of you still remember me from last year. I applied to
>>>>> GSoC on the Apache Derby project and unfortunately ended up not
>>>>> getting picked. I still hanged around for a while but I ended up
>>>>> leaving at some point. This year I'm back and I'm applying for GSoC
>>>>> again :)
>>>>>
>>>>> Right now I'm in a bit of a stalemate with an annoying issue that's
>>>>> bothering me. I followed all the steps to build Derby's code and to do
>>>>> the testing. I am able to build it now and I can also run derbyall
>>>>> with no issues (or close to no issues since derbyall skipped
>>>>> derbynetmats, jdbcapi and jdbc20). The problem that I am stuck with is
>>>>> actually Eclipse-related.
>>>>>
>>>>> I have sort of imported Derby into Eclipse and I am getting 1559
>>>>> errors. With a quick glance through some of the errors, I notice that
>>>>> some of them come from jdbc4 classes, like
>>>>> LogicalCallableStatement40.java . On this one I get for example "The
>>>>> method setRowId(int, RowId) is undefined for the type
>>>>> CallableStatement" and many more errors.
>>>>>
>>>>>
>>>>>
>>>> I don't use Eclipse myself, so I don't know how you can fix it, but my
>>>> guess is that you have configured it to use Java 5 libraries, so that it
>>>> doesn't find some of the new methods in JDBC 4.0. The warning you see in
>>>> LogicalCallableStatement40 is because it contains a line which looks
>>>> like this:
>>>>
>>>>   getPhysCs().setRowId(arg0, arg1);
>>>>
>>>> getPhysCs()'s signature says that it returns a
>>>> java.sql.CallableStatement, but in Java 5 that class didn't have a
>>>> setRowId method and therefore you see the warning.
>>>>
>>>> If you use the Java 6 libraries instead, this warning should go
>>>> away. Unfortunately, you'll probably get other warnings in the JDBC 3.0
>>>> classes instead. (Like complaints because the non-abstract class
>>>> LogicalCallableStatement implements java.sql.CallableStatement but
>>>> doesn't implement the setRowId method.)
>>>>
>>>>
>>>>
>>>>
>>> Hi,
>>>
>>> I think you are most likely correct about the Java 5 libraries, but the
>>> weird thing is that the libraries are actually set for Java 6, so that
>>> shouldn't be it. It doesn't matter anyway, I just switched over to
>>> Netbeans.
>>> it should be less messy :)
>>>
>>> Tiago
>>>
>>>
>>>
>> If you've switched to netbeans, this info may be like mustard after
>> the meal (sorry - non-English proverb, I hope it makes sense)...But
>> here is my 2 c:
>> You can actually set up eclipse to 'add' the libraries for the other
>> jdks. I have 3 jdks loaded in my eclipse source derby project.
>> However, the Derby build process is pretty complex - at least it used
>> to be - so I've configured eclipse to never build...(although I have
>> done a right click on the build.xml and built that way at some point
>> in the past). Normally I build outisde eclipse and run within.
>>
>> Myrna
>>
>> Myrna
>>
>>
> Hehe, mostard na de maaltijd, I have some dutch friends :)
>
> Anyway, I don't think it is mustard after the meal. The truth is that the
> tutorial available on the wiki is for both Eclipse and Netbeans 6.0 . At
> this point we're on Netbeans 6.5 and as so, I'm running into some issues. So
> I may ultimately give up and end up rolling back to the initial Eclipse
> plan. Either way I think I'll update the wiki with my experience since that
> page (http://wiki.apache.org/db-derby/BuildingDerby) is already somewhat
> outdated.
>
> I don't overly want to build within the IDE, but I want to have no errors,
> so Eclipse would work fine for the task.
>
> Tiago
>

Re: 'Issue' with Eclipse

[Tiago Espinha <ti...@espinhas.net>]

Myrna van Lunteren wrote:
> On Mon, Mar 16, 2009 at 7:05 AM, Tiago Espinha <ti...@espinhas.net> wrote:
>   
>> Knut Anders Hatlen wrote:
>>     
>>> Tiago Espinha <ti...@espinhas.net> writes:
>>>
>>>
>>>       
>>>> Hey guys, I'm back.
>>>>
>>>>         
>>> Hi, and welcome back! :)
>>>
>>>
>>>       
>>>> Perhaps some of you still remember me from last year. I applied to
>>>> GSoC on the Apache Derby project and unfortunately ended up not
>>>> getting picked. I still hanged around for a while but I ended up
>>>> leaving at some point. This year I'm back and I'm applying for GSoC
>>>> again :)
>>>>
>>>> Right now I'm in a bit of a stalemate with an annoying issue that's
>>>> bothering me. I followed all the steps to build Derby's code and to do
>>>> the testing. I am able to build it now and I can also run derbyall
>>>> with no issues (or close to no issues since derbyall skipped
>>>> derbynetmats, jdbcapi and jdbc20). The problem that I am stuck with is
>>>> actually Eclipse-related.
>>>>
>>>> I have sort of imported Derby into Eclipse and I am getting 1559
>>>> errors. With a quick glance through some of the errors, I notice that
>>>> some of them come from jdbc4 classes, like
>>>> LogicalCallableStatement40.java . On this one I get for example "The
>>>> method setRowId(int, RowId) is undefined for the type
>>>> CallableStatement" and many more errors.
>>>>
>>>>         
>>> I don't use Eclipse myself, so I don't know how you can fix it, but my
>>> guess is that you have configured it to use Java 5 libraries, so that it
>>> doesn't find some of the new methods in JDBC 4.0. The warning you see in
>>> LogicalCallableStatement40 is because it contains a line which looks
>>> like this:
>>>
>>>    getPhysCs().setRowId(arg0, arg1);
>>>
>>> getPhysCs()'s signature says that it returns a
>>> java.sql.CallableStatement, but in Java 5 that class didn't have a
>>> setRowId method and therefore you see the warning.
>>>
>>> If you use the Java 6 libraries instead, this warning should go
>>> away. Unfortunately, you'll probably get other warnings in the JDBC 3.0
>>> classes instead. (Like complaints because the non-abstract class
>>> LogicalCallableStatement implements java.sql.CallableStatement but
>>> doesn't implement the setRowId method.)
>>>
>>>
>>>       
>> Hi,
>>
>> I think you are most likely correct about the Java 5 libraries, but the
>> weird thing is that the libraries are actually set for Java 6, so that
>> shouldn't be it. It doesn't matter anyway, I just switched over to Netbeans.
>> it should be less messy :)
>>
>> Tiago
>>
>>     
> If you've switched to netbeans, this info may be like mustard after
> the meal (sorry - non-English proverb, I hope it makes sense)...But
> here is my 2 c:
> You can actually set up eclipse to 'add' the libraries for the other
> jdks. I have 3 jdks loaded in my eclipse source derby project.
> However, the Derby build process is pretty complex - at least it used
> to be - so I've configured eclipse to never build...(although I have
> done a right click on the build.xml and built that way at some point
> in the past). Normally I build outisde eclipse and run within.
>
> Myrna
>
> Myrna
>   
Hehe, mostard na de maaltijd, I have some dutch friends :)

Anyway, I don't think it is mustard after the meal. The truth is that 
the tutorial available on the wiki is for both Eclipse and Netbeans 6.0 
. At this point we're on Netbeans 6.5 and as so, I'm running into some 
issues. So I may ultimately give up and end up rolling back to the 
initial Eclipse plan. Either way I think I'll update the wiki with my 
experience since that page 
(http://wiki.apache.org/db-derby/BuildingDerby) is already somewhat 
outdated.

I don't overly want to build within the IDE, but I want to have no 
errors, so Eclipse would work fine for the task.

Tiago

Re: 'Issue' with Eclipse

[Myrna van Lunteren <m....@gmail.com>]

On Mon, Mar 16, 2009 at 7:05 AM, Tiago Espinha <ti...@espinhas.net> wrote:
> Knut Anders Hatlen wrote:
>>
>> Tiago Espinha <ti...@espinhas.net> writes:
>>
>>
>>>
>>> Hey guys, I'm back.
>>>
>>
>> Hi, and welcome back! :)
>>
>>
>>>
>>> Perhaps some of you still remember me from last year. I applied to
>>> GSoC on the Apache Derby project and unfortunately ended up not
>>> getting picked. I still hanged around for a while but I ended up
>>> leaving at some point. This year I'm back and I'm applying for GSoC
>>> again :)
>>>
>>> Right now I'm in a bit of a stalemate with an annoying issue that's
>>> bothering me. I followed all the steps to build Derby's code and to do
>>> the testing. I am able to build it now and I can also run derbyall
>>> with no issues (or close to no issues since derbyall skipped
>>> derbynetmats, jdbcapi and jdbc20). The problem that I am stuck with is
>>> actually Eclipse-related.
>>>
>>> I have sort of imported Derby into Eclipse and I am getting 1559
>>> errors. With a quick glance through some of the errors, I notice that
>>> some of them come from jdbc4 classes, like
>>> LogicalCallableStatement40.java . On this one I get for example "The
>>> method setRowId(int, RowId) is undefined for the type
>>> CallableStatement" and many more errors.
>>>
>>
>> I don't use Eclipse myself, so I don't know how you can fix it, but my
>> guess is that you have configured it to use Java 5 libraries, so that it
>> doesn't find some of the new methods in JDBC 4.0. The warning you see in
>> LogicalCallableStatement40 is because it contains a line which looks
>> like this:
>>
>>    getPhysCs().setRowId(arg0, arg1);
>>
>> getPhysCs()'s signature says that it returns a
>> java.sql.CallableStatement, but in Java 5 that class didn't have a
>> setRowId method and therefore you see the warning.
>>
>> If you use the Java 6 libraries instead, this warning should go
>> away. Unfortunately, you'll probably get other warnings in the JDBC 3.0
>> classes instead. (Like complaints because the non-abstract class
>> LogicalCallableStatement implements java.sql.CallableStatement but
>> doesn't implement the setRowId method.)
>>
>>
>
> Hi,
>
> I think you are most likely correct about the Java 5 libraries, but the
> weird thing is that the libraries are actually set for Java 6, so that
> shouldn't be it. It doesn't matter anyway, I just switched over to Netbeans.
> it should be less messy :)
>
> Tiago
>
If you've switched to netbeans, this info may be like mustard after
the meal (sorry - non-English proverb, I hope it makes sense)...But
here is my 2 c:
You can actually set up eclipse to 'add' the libraries for the other
jdks. I have 3 jdks loaded in my eclipse source derby project.
However, the Derby build process is pretty complex - at least it used
to be - so I've configured eclipse to never build...(although I have
done a right click on the build.xml and built that way at some point
in the past). Normally I build outisde eclipse and run within.

Myrna

Myrna

Re: 'Issue' with Eclipse

[Tiago Espinha <ti...@espinhas.net>]

Knut Anders Hatlen wrote:
> Tiago Espinha <ti...@espinhas.net> writes:
>
>   
>> Hey guys, I'm back.
>>     
>
> Hi, and welcome back! :)
>
>   
>> Perhaps some of you still remember me from last year. I applied to
>> GSoC on the Apache Derby project and unfortunately ended up not
>> getting picked. I still hanged around for a while but I ended up
>> leaving at some point. This year I'm back and I'm applying for GSoC
>> again :)
>>
>> Right now I'm in a bit of a stalemate with an annoying issue that's
>> bothering me. I followed all the steps to build Derby's code and to do
>> the testing. I am able to build it now and I can also run derbyall
>> with no issues (or close to no issues since derbyall skipped
>> derbynetmats, jdbcapi and jdbc20). The problem that I am stuck with is
>> actually Eclipse-related.
>>
>> I have sort of imported Derby into Eclipse and I am getting 1559
>> errors. With a quick glance through some of the errors, I notice that
>> some of them come from jdbc4 classes, like
>> LogicalCallableStatement40.java . On this one I get for example "The
>> method setRowId(int, RowId) is undefined for the type
>> CallableStatement" and many more errors.
>>     
>
> I don't use Eclipse myself, so I don't know how you can fix it, but my
> guess is that you have configured it to use Java 5 libraries, so that it
> doesn't find some of the new methods in JDBC 4.0. The warning you see in
> LogicalCallableStatement40 is because it contains a line which looks
> like this:
>
>     getPhysCs().setRowId(arg0, arg1);
>
> getPhysCs()'s signature says that it returns a
> java.sql.CallableStatement, but in Java 5 that class didn't have a
> setRowId method and therefore you see the warning.
>
> If you use the Java 6 libraries instead, this warning should go
> away. Unfortunately, you'll probably get other warnings in the JDBC 3.0
> classes instead. (Like complaints because the non-abstract class
> LogicalCallableStatement implements java.sql.CallableStatement but
> doesn't implement the setRowId method.)
>
>   
Hi,

I think you are most likely correct about the Java 5 libraries, but the 
weird thing is that the libraries are actually set for Java 6, so that 
shouldn't be it. It doesn't matter anyway, I just switched over to 
Netbeans. it should be less messy :)

Tiago

Re: 'Issue' with Eclipse

[Knut Anders Hatlen <Kn...@Sun.COM>]

Tiago Espinha <ti...@espinhas.net> writes:

> Hey guys, I'm back.

Hi, and welcome back! :)

> Perhaps some of you still remember me from last year. I applied to
> GSoC on the Apache Derby project and unfortunately ended up not
> getting picked. I still hanged around for a while but I ended up
> leaving at some point. This year I'm back and I'm applying for GSoC
> again :)
>
> Right now I'm in a bit of a stalemate with an annoying issue that's
> bothering me. I followed all the steps to build Derby's code and to do
> the testing. I am able to build it now and I can also run derbyall
> with no issues (or close to no issues since derbyall skipped
> derbynetmats, jdbcapi and jdbc20). The problem that I am stuck with is
> actually Eclipse-related.
>
> I have sort of imported Derby into Eclipse and I am getting 1559
> errors. With a quick glance through some of the errors, I notice that
> some of them come from jdbc4 classes, like
> LogicalCallableStatement40.java . On this one I get for example "The
> method setRowId(int, RowId) is undefined for the type
> CallableStatement" and many more errors.

I don't use Eclipse myself, so I don't know how you can fix it, but my
guess is that you have configured it to use Java 5 libraries, so that it
doesn't find some of the new methods in JDBC 4.0. The warning you see in
LogicalCallableStatement40 is because it contains a line which looks
like this:

    getPhysCs().setRowId(arg0, arg1);

getPhysCs()'s signature says that it returns a
java.sql.CallableStatement, but in Java 5 that class didn't have a
setRowId method and therefore you see the warning.

If you use the Java 6 libraries instead, this warning should go
away. Unfortunately, you'll probably get other warnings in the JDBC 3.0
classes instead. (Like complaints because the non-abstract class
LogicalCallableStatement implements java.sql.CallableStatement but
doesn't implement the setRowId method.)

-- 
Knut Anders