[Java DB - testing] Failure continuous trunk (rev 1754588)

[ingemar . aberg]

Java DB testing and reporting infrastructure.

Failure continuous trunk (rev 1754588)

There were 16 failures.

[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10

[Danoja Dias (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15400432#comment-15400432
 ] 

Danoja Dias commented on DERBY-6391:


Thanks for the suggestion to find exception calls in an easy way.

> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>Assignee: Danoja Dias
>  Labels: derby_backport_reject_10_10
> Attachments: Derby-6391.diff
>
>
> In releases after 10.10 the code has been converted to use new 
> java language features.  One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects.  I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call.  I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10

[Danoja Dias (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Danoja Dias reassigned DERBY-6391:
--

Assignee: Danoja Dias

> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>Assignee: Danoja Dias
>  Labels: derby_backport_reject_10_10
> Attachments: Derby-6391.diff
>
>
> In releases after 10.10 the code has been converted to use new 
> java language features.  One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects.  I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call.  I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10

[Danoja Dias (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Danoja Dias updated DERBY-6391:
---
Attachment: Derby-6391.diff

> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>  Labels: derby_backport_reject_10_10
> Attachments: Derby-6391.diff
>
>
> In releases after 10.10 the code has been converted to use new 
> java language features.  One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects.  I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call.  I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10

[Danoja Dias (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15400430#comment-15400430
 ] 

Danoja Dias commented on DERBY-6391:


I should have commented this before as I spent a considerable time on this 
without knowing this has been already done. :)
I went through many classes and didn't find many such object creations.
I found one so far and I'll attach it.

I looked at diffs. But can we be sure that all such unneeded object creations 
are removed?

> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>  Labels: derby_backport_reject_10_10
>
> In releases after 10.10 the code has been converted to use new 
> java language features.  One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects.  I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call.  I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15400374#comment-15400374
 ] 

Bryan Pendleton commented on DERBY-6391:


I'm not certain of such an easy way. I tried this:
{code}
find java/engine -name '*.java' -exec grep -n -A 5 -e 'throw ' {} \; -print > 
/tmp/t
{code}
which gave me a nice file with a lot of examples of exception throwing to
look at, but I didn't immediately see any that fit the problematic pattern.

I think it's quite possible that this particular bug was fixed
by revision 1742858, for example, look at the diffs for StoredPage.java in:

http://svn.apache.org/viewvc?view=revision=1742858

We may be able to close this bug as fixed by 1742858.

> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>  Labels: derby_backport_reject_10_10
>
> In releases after 10.10 the code has been converted to use new 
> java language features.  One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects.  I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call.  I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type

[Bryan Pendleton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Pendleton resolved DERBY-5585.

Resolution: Fixed

With your latest patch, my test runs are clean, too. Thanks! Committed.

> Improve error messages used when Derby can't find the class or method backing 
> up a SQL routine or type
> --
>
> Key: DERBY-5585
> URL: https://issues.apache.org/jira/browse/DERBY-5585
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.9.1.0
>Reporter: Rick Hillegas
>Assignee: Danoja Dias
>Priority: Minor
>  Labels: derby_triage10_10
> Fix For: 10.13.0.0
>
> Attachments: Derby-5585.diff, Derby-5585_2.diff, Derby5585_3.diff, 
> errors.zip
>
>
> When the code supporting user-written routines and types is put into jar 
> files in the database, the user also needs to wire the jar files together by 
> setting the derby.database.classpath  property. People often neglect to do 
> this and Derby documentation in this area could be improved. It would be good 
> to at least improve the error messages which Derby raises in this situation: 
> 42X50 and 42X51. Those messages should tell the user that one of the reasons 
> for the failure might be an un/misconfigured derby.database.classpath  
> property. The following script shows the error messages:
> connect 
> 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword';
> create function foo( a int ) returns int
> language java parameter style java no sql
> external name 'Bop.doowop';
> create function bar( a int ) returns int
> language java parameter style java no sql
> external name 'java.lang.Integer.doowop';
> values ( foo( 1 ) );
> values ( bar( 1 ) );



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15400367#comment-15400367
 ] 

ASF subversion and git services commented on DERBY-5585:


Commit 1754588 from [~bryanpendleton] in branch 'code/trunk'
[ https://svn.apache.org/r1754588 ]

DERBY-5585: Improve error message when user function can't find class.

This patch was contributed by Danoja Dias (danojadias at gmail dot com)

Several test output files are adjusted to reflect the new error message text.

> Improve error messages used when Derby can't find the class or method backing 
> up a SQL routine or type
> --
>
> Key: DERBY-5585
> URL: https://issues.apache.org/jira/browse/DERBY-5585
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.9.1.0
>Reporter: Rick Hillegas
>Assignee: Danoja Dias
>Priority: Minor
>  Labels: derby_triage10_10
> Fix For: 10.13.0.0
>
> Attachments: Derby-5585.diff, Derby-5585_2.diff, Derby5585_3.diff, 
> errors.zip
>
>
> When the code supporting user-written routines and types is put into jar 
> files in the database, the user also needs to wire the jar files together by 
> setting the derby.database.classpath  property. People often neglect to do 
> this and Derby documentation in this area could be improved. It would be good 
> to at least improve the error messages which Derby raises in this situation: 
> 42X50 and 42X51. Those messages should tell the user that one of the reasons 
> for the failure might be an un/misconfigured derby.database.classpath  
> property. The following script shows the error messages:
> connect 
> 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword';
> create function foo( a int ) returns int
> language java parameter style java no sql
> external name 'Bop.doowop';
> create function bar( a int ) returns int
> language java parameter style java no sql
> external name 'java.lang.Integer.doowop';
> values ( foo( 1 ) );
> values ( bar( 1 ) );



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6870) Google Summer of Code 2016: Derby bug fixing

[Bryan Pendleton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Pendleton updated DERBY-6870:
---
Assignee: Danoja Dias

> Google Summer of Code 2016: Derby bug fixing
> 
>
> Key: DERBY-6870
> URL: https://issues.apache.org/jira/browse/DERBY-6870
> Project: Derby
>  Issue Type: Improvement
>Reporter: Bryan Pendleton
>Assignee: Danoja Dias
>  Labels: database, gsoc2016, java, jdbc
>
> For the 2016 Google Summer of Code, I am offering to mentor a
> student for general bug fixing of the Derby database.
> The Derby JIRA has collected the community's knowledge about
> known bugs in Derby, and there are plenty of bugs for us to work on.
> If you take on this project, with assistance from me, you'll:
> - select Derby issues from the Derby bug tracker to fix
> - reproduce those problems by writing and running tests
> - develop patches to address the problems
> - work with the community to get the patches reviewed
> - have your reviewed and accepted contributions committed to the next Derby 
> release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build became unstable: Derby-JaCoCo #246

[Apache Jenkins Server]

See 

[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10

[Danoja Dias (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399511#comment-15399511
 ] 

Danoja Dias commented on DERBY-6391:


In DERBY-5873 this is already done for client and server. 
So I started doing this for the classes in engine folder.

Now what I do is, finding the Exception keyword and 
check whether there is a object creation. 
Most times, There is no creation of objects. 

I find it bit hard to find where these object creations happens. 
Is there a simple and easy way to find out where these object 
creation happens.

> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>  Labels: derby_backport_reject_10_10
>
> In releases after 10.10 the code has been converted to use new 
> java language features.  One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects.  I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call.  I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type

[Danoja Dias (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Danoja Dias updated DERBY-5585:
---
Attachment: Derby5585_3.diff

With Derby5585_3.diff patch tests were fine.

> Improve error messages used when Derby can't find the class or method backing 
> up a SQL routine or type
> --
>
> Key: DERBY-5585
> URL: https://issues.apache.org/jira/browse/DERBY-5585
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.9.1.0
>Reporter: Rick Hillegas
>Assignee: Danoja Dias
>Priority: Minor
>  Labels: derby_triage10_10
> Fix For: 10.13.0.0
>
> Attachments: Derby-5585.diff, Derby-5585_2.diff, Derby5585_3.diff, 
> errors.zip
>
>
> When the code supporting user-written routines and types is put into jar 
> files in the database, the user also needs to wire the jar files together by 
> setting the derby.database.classpath  property. People often neglect to do 
> this and Derby documentation in this area could be improved. It would be good 
> to at least improve the error messages which Derby raises in this situation: 
> 42X50 and 42X51. Those messages should tell the user that one of the reasons 
> for the failure might be an un/misconfigured derby.database.classpath  
> property. The following script shows the error messages:
> connect 
> 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword';
> create function foo( a int ) returns int
> language java parameter style java no sql
> external name 'Bop.doowop';
> create function bar( a int ) returns int
> language java parameter style java no sql
> external name 'java.lang.Integer.doowop';
> values ( foo( 1 ) );
> values ( bar( 1 ) );



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)