Re: [VOTE] 10.17.1.0 release

[Knut Anders Hatlen]

Rick Hillegas  writes:

> Please test-drive the 10.17.1.0 candidate, then vote on whether to
> accept it as a Derby release.

+1

I've run the regression tests with Java 21 on Debian 12. I've also
verified the signatures of the tarballs and zip files, and done some ad
hoc testing. No problems were found.

Thanks,

-- 
Knut Anders

[jira] [Commented] (DERBY-7157) Tasks for releasing Derby 10.17.1

[Knut Anders Hatlen (Jira)]

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

Knut Anders Hatlen commented on DERBY-7157:
---

> For future release notes, to reduce confusion, should we explicitly state 
> what Java versions the release won't run on?

If the release drops support for some Java versions, I think it's good to 
highlight that, since that's something users need to take into consideration 
before upgrading. Since the release notes start by saying "These notes describe 
the difference between Apache Derby release 10.17.1.0 and the preceding release 
10.16.1.1.", and not supporting JDK 17 is one of the differences, I think it 
deserves a separate mentioning.

In releases that don't drop support for any versions, I think it's sufficient 
to state which versions are supported.

> How can we make this clearer?

I think we can add a sentence to the paragraph which currently says: "The major 
feature of this release is support for Java SE 21." For example: "Versions 
prior to Java SE 21 are no longer supported." Or maybe it's a bit unnatural to 
list this under "New Features", and we should have another section "Removed 
Features"?

(By the way, it seems to run fine with Java SE 19 and 20 too. Haven't tried 18. 
But it's probably fine to state that only 21 is supported, even if it appears 
to work on some older versions.)

> I like Bryan's suggestion about adding some verbiage concerning Modules and 
> the deprecated SecurityManager. This would help users understand why we 
> introduced lower bounds on platform support.

I agree.

> Tasks for releasing Derby 10.17.1
> -
>
> Key: DERBY-7157
> URL: https://issues.apache.org/jira/browse/DERBY-7157
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7157-01-aa-draftReleaseNotes.diff, 
> derby-7157-02-aa-initialSTATUSupdate.diff, 
> derby-7157-03-aa-updateDocConstants.diff, 
> derby-7157-04-aa-updateReleaseProperties.diff, 
> derby-7157-05-aa-bumpReleaseNumberOnTrunk.diff, 
> derby-7157-06-aa-newDataDictionaryVersion.diff, 
> derby-7157-07-aa-recordBranchesOnWebsite.diff, 
> derby-7157-08-aa-updateAntVersion.diff, 
> derby-7157-09-aa-goofProofBranchName.diff
>
>
> Placeholder for activity related to producing a 10.17.1 release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7157) Tasks for releasing Derby 10.17.1

[Knut Anders Hatlen (Jira)]

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

Knut Anders Hatlen commented on DERBY-7157:
---

We could probably have added a sentence to the release notes stating explicitly 
that we drop support for JDK versions prior to JDK 21. Just to avoid surprises. 
(I was caught by this myself, when I first tried to use the release candidate 
with JDK 17, and realized I had to install a newer JDK to get it working.) I 
suppose the download page will say "For Java 21 and Higher" when we make the 
new version available there, similar to what it says for other versions, so 
it's probably not a big issue in practice.

(I assume dropping support for JDK 17 was intentional, and not just that we 
have forgotten to set the correct target version in the build scripts.)

> Tasks for releasing Derby 10.17.1
> -
>
> Key: DERBY-7157
> URL: https://issues.apache.org/jira/browse/DERBY-7157
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7157-01-aa-draftReleaseNotes.diff, 
> derby-7157-02-aa-initialSTATUSupdate.diff, 
> derby-7157-03-aa-updateDocConstants.diff, 
> derby-7157-04-aa-updateReleaseProperties.diff, 
> derby-7157-05-aa-bumpReleaseNumberOnTrunk.diff, 
> derby-7157-06-aa-newDataDictionaryVersion.diff, 
> derby-7157-07-aa-recordBranchesOnWebsite.diff, 
> derby-7157-08-aa-updateAntVersion.diff
>
>
> Placeholder for activity related to producing a 10.17.1 release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7157) Tasks for releasing Derby 10.17.1

[Knut Anders Hatlen (Jira)]

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

Knut Anders Hatlen commented on DERBY-7157:
---

Hi Rick,

This part of the 08-aa patch should probably not have been backported to the 
10.17 branch:
{code:java}
--- RELEASE-NOTES.html  (revision 1913211)
+++ RELEASE-NOTES.html  (working copy)
@@ -177,11 +177,11 @@
 Derby release 10.17.1.0 was built using the following environment:
 
 
-Branch - Source code came from the 10.17 branch.
+Branch - Source code came from the 10.18 branch.
 
{code}
It's not important enough to spin a new relase candidate, I think, but it would 
be good to have it fixed in the branch in any case.

> Tasks for releasing Derby 10.17.1
> -
>
> Key: DERBY-7157
> URL: https://issues.apache.org/jira/browse/DERBY-7157
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7157-01-aa-draftReleaseNotes.diff, 
> derby-7157-02-aa-initialSTATUSupdate.diff, 
> derby-7157-03-aa-updateDocConstants.diff, 
> derby-7157-04-aa-updateReleaseProperties.diff, 
> derby-7157-05-aa-bumpReleaseNumberOnTrunk.diff, 
> derby-7157-06-aa-newDataDictionaryVersion.diff, 
> derby-7157-07-aa-recordBranchesOnWebsite.diff, 
> derby-7157-08-aa-updateAntVersion.diff
>
>
> Placeholder for activity related to producing a 10.17.1 release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Sunsetting support for Java 9 and 10

[Knut Anders Hatlen]

Rick Hillegas  writes:

> Please vote on the following proposed policy for supported platforms.
> The polls close at 5:00 pm San Francisco time on Sunday May 24.
>
> A) The 10.16 release will support Java 11 on up, but will not support
> older versions of Java.
>
> B) All releases in the 10.16 family will follow this policy.
>
> Adopting this policy would result in the following changes to the
> 10.16 trunk:
>
> I) Removing build support for Java 9 and 10.
>
> II) Purging user doc references to Java 9 and 10.
>
> We do not anticipate that this policy will require any changes to user code.

+1

[jira] [Commented] (DERBY-7056) Make Derby modules usable by OSGi-aware applications

[Knut Anders Hatlen (Jira)]

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

Knut Anders Hatlen commented on DERBY-7056:
---

It looks like the mirror on github lags behind the svn repository. Head of 
trunk on github corresponds to svn revision 1865408 from August 19. The patches 
seem to apply cleanly on top of svn revision 1865408, but they have some 
conflicts with the more recent commits in the svn repository.

> Make Derby modules usable by OSGi-aware applications
> 
>
> Key: DERBY-7056
> URL: https://issues.apache.org/jira/browse/DERBY-7056
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: 0001-Initial-production-of-OSGi-manifests.patch, 
> 0002-Initial-production-of-OSGi-manifests-for-locales.patch, 
> 0003-Produce-working-locales-fragments-and-refactor.patch, 
> 0004-Reintroduce-Class-Path-attributes.patch, 
> 0005-Clear-BundleActivator.patch, derby.txt
>
>
> OSGi R7 introduced support for JPMS modules in 2018 according to 
> https://blog.osgi.org/2018/02/osgi-r7-highlights-java-9-support.html. This 
> includes additional information which goes into jar file manifests. Support 
> for this OSGi information was requested by an email thread on the user list: 
> http://apache-database.10148.n7.nabble.com/OSGi-manifest-headers-td150560.html.
>  We need advice from OSGi experts on how to make Derby modules usable by 
> OSGi-aware applications. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DERBY-6809) Java 1.8 feature use

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6809:
---

Some examples:

DERBY-2150 Reduce use of synchronized collections in 
GenericLanguageConnectionContext
DERBY-2493 Use unsynchronized collections in BackingStoreHashtable
DERBY-2911 Implement a buffer manager using java.util.concurrent classes
DERBY-3092 Use java.util.concurrent in TransactionTable to improve scalability
DERBY-6075 Use modern collections in impl/sql/compile

> Java 1.8 feature use
> 
>
> Key: DERBY-6809
> URL: https://issues.apache.org/jira/browse/DERBY-6809
> Project: Derby
>  Issue Type: Improvement
>  Components: Network Server
>Affects Versions: 11.0.0.0
>Reporter: sagar
> Attachments: 2017-12-04-143613_1366x768_scrot.png
>
>
> Suggestion ...
> Is it possible to auto modify the existing source code using tools like 
> Netbeans, and take advantage of the new features in JDK 1.8 for better 
> multiuser performance and better utilization of current day multicore 
> processors?
> Plainly put, can we have from 11.0 onwards a version of derby which takes 
> advantage of the advancements and new features in java 1.8 ... 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6809) Java 1.8 feature use

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6809:
---

I haven't studied all the details of MergeInserter, but it looks like an 
ArrayList might be safe to use there. This code probably predates the 
introduction of ArrayList in Java, so Vector was the only alternative at the 
time. We replaced some Vectors with more modern collections a while ago, but 
that work focused on the synchronized collections that were performance 
bottlenecks. I doubt that it will be possible to measure any performance impact 
of a couple of synchronized operations per temporary file in a merge sort, but 
it still might be good to change it. If nothing else, readers of the code won't 
need to spend time figuring out why a synchronized collection is used.

> Java 1.8 feature use
> 
>
> Key: DERBY-6809
> URL: https://issues.apache.org/jira/browse/DERBY-6809
> Project: Derby
>  Issue Type: Improvement
>  Components: Network Server
>Affects Versions: 11.0.0.0
>Reporter: sagar
> Attachments: 2017-12-04-143613_1366x768_scrot.png
>
>
> Suggestion ...
> Is it possible to auto modify the existing source code using tools like 
> Netbeans, and take advantage of the new features in JDK 1.8 for better 
> multiuser performance and better utilization of current day multicore 
> processors?
> Plainly put, can we have from 11.0 onwards a version of derby which takes 
> advantage of the advancements and new features in java 1.8 ... 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: fiixing JaCoCo, was: need help configuring Jenkins

[Knut Anders Hatlen]

Rick Hillegas  writes:

> On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
>> Knut Anders Hatlen  writes:
>>
>>> Rick Hillegas  writes:
>>>
>>>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>>>> Rick Hillegas  writes:
>>>>>
>>>>>> I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
>>>>>> JaCoCo jars at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.apache.org_-7Erhillegas_derby_jacoco-2Djars_&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=ZhaPG5oM4BGrJfVvjLS03y6iz4nvtBip_vUHOgTHkhI&e=.
>>>>>> Let's see if that helps.
>>>>>>
>>>>>> Does anyone know why we also have a Derby-JaCoCo job (also broken)?
>>>>>> Why are we running JaCoCo twice and with different scripts?
>>>>> Hi Rick,
>>>>>
>>>>> I did some maintenance on the Derby-JaCoCo job some years ago, after it
>>>>> had broken when we had moved to a newer Java version which was not
>>>>> supported by the JaCoCo version we were using.
>>>>>
>>>>> I remember that we had two jobs at that time too. Don't know why we had
>>>>> two, though. I left the Derby-trunk-JaCoCo job alone, because it
>>>>> appeared to be abandoned (it was disabled, I think), and also because it
>>>>> fetched jar files from a committer's home directory. The Derby-JaCoCo
>>>>> job fetched the jar files from Maven, which sounded more maintainable as
>>>>> it allowed others than that one committer to make updates, if required.
>>>>>
>>>>> I was actually planning to delete the Derby-trunk-JaCoCo job after a
>>>>> while if the Derby-JaCoCo proved to be stable. But apparently I forgot.
>>>> Thanks, Knut. Sounds like we should retire Derby-trunk-JaCoCo and
>>>> figure out how to get Derby-JaCoCo to fetch the correct version of the
>>>> JaCoCo jars.
>>> As a first step, I've updated Derby-JaCoCo to use the latest version of
>>> JaCoCo (0.7.9). I did this by updating the following variables in the
>>> build section of the configuration:
>>>
>>> jacoco_version=0.7.9
>>> jacoco_zip_sha1=1d56a66be0f4a6b529d8f983ab65cc77a52cccb6
>>> jacocoant_sha1=87aa22de3854fd5a43e37a17c4b245b01a46de93
>>> jacocoagent_sha1=a6ac9cca89d889222a40dab9dd5039bfd22a4cff
>>>
>>> I had to download the JaCoCo zip file locally and extract it to
>>> calculate the SHA1 checksums of the zip file and the two jar files we
>>> need from it. The checksums are used by the build script to check if we
>>> already have the right version, or if we have to download it from Maven.
>>>
>>> I've kicked off a build, and it has already passed the point where it
>>> failed before, so maybe that's all that was needed. Let's see what
>>> happens...
>> The build job completed and produced a coverage report, so there is
>> improvement. 10 tests failed, though, so the job is still marked as
>> "unstable".
> Thanks, Knut. The failures all result from a missing FilePermission
> under DropDatabaseSetup while checking for the existence of a
> directory before deleting it. The tests work standalone on my machine.
> Do you remember if the JaCoCo test runs have their own security
> policy, which might need to be updated?

Hi Rick,

I think they use the ordinary policy files, but the extra permissions
needed for JaCoCo are guarded by the jacoco.active system property. For
example:

permission java.io.FilePermission "${jacoco.active}${user.dir}${/}*", "read, 
write";

When JaCoCo is active, the jacoco.active property is set to the empty
string, so that the above rule becomes equivalent to

permission java.io.FilePermission "${user.dir}${/}*", "read, write";

and thereby becomes active.

The code that sets the jacoco.active property seems to be located in
BaseTestCase and SecurityManagerSetup.

-- 
Knut Anders

Re: fiixing JaCoCo, was: need help configuring Jenkins

[Knut Anders Hatlen]

Knut Anders Hatlen  writes:

> Rick Hillegas  writes:
>
>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas  writes:
>>>
>>>> I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
>>>> JaCoCo jars at
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.apache.org_-7Erhillegas_derby_jacoco-2Djars_&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=ZhaPG5oM4BGrJfVvjLS03y6iz4nvtBip_vUHOgTHkhI&e=.
>>>> Let's see if that helps.
>>>>
>>>> Does anyone know why we also have a Derby-JaCoCo job (also broken)?
>>>> Why are we running JaCoCo twice and with different scripts?
>>> Hi Rick,
>>>
>>> I did some maintenance on the Derby-JaCoCo job some years ago, after it
>>> had broken when we had moved to a newer Java version which was not
>>> supported by the JaCoCo version we were using.
>>>
>>> I remember that we had two jobs at that time too. Don't know why we had
>>> two, though. I left the Derby-trunk-JaCoCo job alone, because it
>>> appeared to be abandoned (it was disabled, I think), and also because it
>>> fetched jar files from a committer's home directory. The Derby-JaCoCo
>>> job fetched the jar files from Maven, which sounded more maintainable as
>>> it allowed others than that one committer to make updates, if required.
>>>
>>> I was actually planning to delete the Derby-trunk-JaCoCo job after a
>>> while if the Derby-JaCoCo proved to be stable. But apparently I forgot.
>> Thanks, Knut. Sounds like we should retire Derby-trunk-JaCoCo and
>> figure out how to get Derby-JaCoCo to fetch the correct version of the
>> JaCoCo jars.
>
> As a first step, I've updated Derby-JaCoCo to use the latest version of
> JaCoCo (0.7.9). I did this by updating the following variables in the
> build section of the configuration:
>
> jacoco_version=0.7.9
> jacoco_zip_sha1=1d56a66be0f4a6b529d8f983ab65cc77a52cccb6
> jacocoant_sha1=87aa22de3854fd5a43e37a17c4b245b01a46de93
> jacocoagent_sha1=a6ac9cca89d889222a40dab9dd5039bfd22a4cff
>
> I had to download the JaCoCo zip file locally and extract it to
> calculate the SHA1 checksums of the zip file and the two jar files we
> need from it. The checksums are used by the build script to check if we
> already have the right version, or if we have to download it from Maven.
>
> I've kicked off a build, and it has already passed the point where it
> failed before, so maybe that's all that was needed. Let's see what
> happens...

The build job completed and produced a coverage report, so there is
improvement. 10 tests failed, though, so the job is still marked as
"unstable".

-- 
Knut Anders

Re: fiixing JaCoCo, was: need help configuring Jenkins

[Knut Anders Hatlen]

Rick Hillegas  writes:

> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>> Rick Hillegas  writes:
>>
>>> I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
>>> JaCoCo jars at
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.apache.org_-7Erhillegas_derby_jacoco-2Djars_&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=ZhaPG5oM4BGrJfVvjLS03y6iz4nvtBip_vUHOgTHkhI&e=.
>>> Let's see if that helps.
>>>
>>> Does anyone know why we also have a Derby-JaCoCo job (also broken)?
>>> Why are we running JaCoCo twice and with different scripts?
>> Hi Rick,
>>
>> I did some maintenance on the Derby-JaCoCo job some years ago, after it
>> had broken when we had moved to a newer Java version which was not
>> supported by the JaCoCo version we were using.
>>
>> I remember that we had two jobs at that time too. Don't know why we had
>> two, though. I left the Derby-trunk-JaCoCo job alone, because it
>> appeared to be abandoned (it was disabled, I think), and also because it
>> fetched jar files from a committer's home directory. The Derby-JaCoCo
>> job fetched the jar files from Maven, which sounded more maintainable as
>> it allowed others than that one committer to make updates, if required.
>>
>> I was actually planning to delete the Derby-trunk-JaCoCo job after a
>> while if the Derby-JaCoCo proved to be stable. But apparently I forgot.
> Thanks, Knut. Sounds like we should retire Derby-trunk-JaCoCo and
> figure out how to get Derby-JaCoCo to fetch the correct version of the
> JaCoCo jars.

As a first step, I've updated Derby-JaCoCo to use the latest version of
JaCoCo (0.7.9). I did this by updating the following variables in the
build section of the configuration:

jacoco_version=0.7.9
jacoco_zip_sha1=1d56a66be0f4a6b529d8f983ab65cc77a52cccb6
jacocoant_sha1=87aa22de3854fd5a43e37a17c4b245b01a46de93
jacocoagent_sha1=a6ac9cca89d889222a40dab9dd5039bfd22a4cff

I had to download the JaCoCo zip file locally and extract it to
calculate the SHA1 checksums of the zip file and the two jar files we
need from it. The checksums are used by the build script to check if we
already have the right version, or if we have to download it from Maven.

I've kicked off a build, and it has already passed the point where it
failed before, so maybe that's all that was needed. Let's see what
happens...

-- 
Knut Anders

Re: fiixing JaCoCo, was: need help configuring Jenkins

[Knut Anders Hatlen]

Rick Hillegas  writes:

> I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
> JaCoCo jars at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.apache.org_-7Erhillegas_derby_jacoco-2Djars_&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=ZhaPG5oM4BGrJfVvjLS03y6iz4nvtBip_vUHOgTHkhI&e=.
> Let's see if that helps.
>
> Does anyone know why we also have a Derby-JaCoCo job (also broken)?
> Why are we running JaCoCo twice and with different scripts?

Hi Rick,

I did some maintenance on the Derby-JaCoCo job some years ago, after it
had broken when we had moved to a newer Java version which was not
supported by the JaCoCo version we were using.

I remember that we had two jobs at that time too. Don't know why we had
two, though. I left the Derby-trunk-JaCoCo job alone, because it
appeared to be abandoned (it was disabled, I think), and also because it
fetched jar files from a committer's home directory. The Derby-JaCoCo
job fetched the jar files from Maven, which sounded more maintainable as
it allowed others than that one committer to make updates, if required.

I was actually planning to delete the Derby-trunk-JaCoCo job after a
while if the Derby-JaCoCo proved to be stable. But apparently I forgot.

> See
>
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=wulacnvwG-OWc5lbUU9q382NzVuIur7Z7LVngjcHYPU&e=
>
> and
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2Dtrunk-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=YOFIV1NAlpMLVIwmKggAqSvt93XoNP1PMcQU_jPbBgo&e=
>
> Thanks,
> -Rick

-- 
Knut Anders

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6445:
---

I cannot recall what I said about setNull(), and I don't think anything is 
needed there. As to getObject(), even if this conversion is only mentioned in 
the conversion tables for setObject(), [the spec for 
getObject()|http://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getObject-int-java.lang.Class-]
 says:

"At a minimum, an implementation must support the conversions defined in 
Appendix B, Table B-3 and conversion of appropriate user defined SQL types to a 
Java type which implements SQLData, or Struct. Additional conversions may be 
supported and are vendor defined."

So it sounds like we're free to add more conversions, and I think these ones 
make sense.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
> Attachments: Derby-6445.html, Derby-6445.html
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6865:
---

The problem reported here has been fixed. Closing the issue.

> RestrictiveFilePermissionsTest fails on Windows
> ---
>
> Key: DERBY-6865
> URL: https://issues.apache.org/jira/browse/DERBY-6865
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.1.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728459
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.1.0
>
>
> {noformat}
> .F.F.F.F.F.F.F.F.F.F.F.F.F..
> Time: 48,93
> There were 13 failures:
> 1) 
> testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
>  unexpected uid \OPPRETTER EIER can access file 
> C:\cygwin64\tmp\derbytst\system\RFPT_backup
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
> {noformat}



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

[jira] [Closed] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6865.
-
   Resolution: Fixed
Fix Version/s: 10.13.1.0

> RestrictiveFilePermissionsTest fails on Windows
> ---
>
> Key: DERBY-6865
> URL: https://issues.apache.org/jira/browse/DERBY-6865
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.1.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728459
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.1.0
>
>
> {noformat}
> .F.F.F.F.F.F.F.F.F.F.F.F.F..
> Time: 48,93
> There were 13 failures:
> 1) 
> testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
>  unexpected uid \OPPRETTER EIER can access file 
> C:\cygwin64\tmp\derbytst\system\RFPT_backup
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
> {noformat}



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

Re: How to add a new Jenkins build job for the 10.13 branch?

[Knut Anders Hatlen]

Bryan Pendleton  writes:

> Hi all,
>
> In https://wiki.apache.org/db-derby/CreatingDerbyBranch, I see:
>
>   "Post a message to derby-dev requesting creation of a Jenkins
>   build job for the new branch."
>
> Can anybody tell me the steps so I can do that? I went to
> https://builds.apache.org/view/A-D/view/Derby and clicked around
> for a while but I didn't see anything obvious about how I could
> copy the 10.12 build job and tweak it to become a 10.13 build job.

Hi Bryan,

At https://builds.apache.org/view/A-D/view/Derby there is a link "New
Item" in the upper left corner if you are logged in. If you click that
link, you'll get to the page where you create new build jobs. Type the
name of the new build job in the text box near the top of the page, and
then go to the bottom of the page, where you'll find a text box where
you can type the name of the job you want to copy.

After you have copied it, you should go to the configuration panel of
the new build job and change the Subversion URL to point to 10.13
instead of 10.12. That's it, I think.

-- 
Knut Anders

[jira] [Commented] (DERBY-6891) Investigate concurrency improvements to DerbyObservable and DerbyObserver

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6891:
---

The patch looks good to me. Now that all the methods synchronize on the 
DerbyObservable instance, it should be safe to replace the Vector with an 
unsynchronized ArrayList.

> Investigate concurrency improvements to DerbyObservable and DerbyObserver
> -
>
> Key: DERBY-6891
> URL: https://issues.apache.org/jira/browse/DERBY-6891
> Project: Derby
>  Issue Type: Improvement
>  Components: Store
>Reporter: Rick Hillegas
> Attachments: derby-6891-01-aa-synchronizeMethods.diff
>
>
> As part of derby-6856, we introduced a pair of classes which manage callbacks 
> between classes in the Store layer. The classes are DerbyObservable and 
> DerbyObserver. They replace the deprecated Observer and Observable classes in 
> the JVM and allow Derby to build without deprecation warnings. Right now, 
> callbacks are managed by a Vector. It is quite likely that the concurrency of 
> these classes (and therefore of the Store layer) could be boosted by using 
> some mechanism from java.util.concurrent.



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

[jira] [Commented] (DERBY-6891) Investigate concurrency improvements to DerbyObservable and DerbyObserver

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6891:
---

I'm wondering if the synchronization in DerbyObservable is quite right. Most of 
the methods synchronize implicitly on the Vector. But the notifyObservers() 
method synchronizes on "this" instead, which is the DerbyObservable instance. 
And setChanged() has no synchronization, even though it manipulates a flag 
which notifyObservers() checks inside a synchronized block.

> Investigate concurrency improvements to DerbyObservable and DerbyObserver
> -
>
> Key: DERBY-6891
> URL: https://issues.apache.org/jira/browse/DERBY-6891
> Project: Derby
>  Issue Type: Improvement
>  Components: Store
>Reporter: Rick Hillegas
>
> As part of derby-6856, we introduced a pair of classes which manage callbacks 
> between classes in the Store layer. The classes are DerbyObservable and 
> DerbyObserver. They replace the deprecated Observer and Observable classes in 
> the JVM and allow Derby to build without deprecation warnings. Right now, 
> callbacks are managed by a Vector. It is quite likely that the concurrency of 
> these classes (and therefore of the Store layer) could be boosted by using 
> some mechanism from java.util.concurrent.



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

[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6856:
---

Hi Rick,

If you use getDeclaredConstructor() instead of getConstructor(), you might not 
have to make the constructors public. getConstructor() only finds public 
constructors, whereas getDeclaredConstructor() also finds non-public 
constructors.

> Make it possible to build Derby using JDK 9
> ---
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff, 
> derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff, 
> derby-6856-03-aa-autoboxingDeprecationWarnings.diff, 
> derby-6856-03-ab-autoboxingDeprecationWarnings.diff, 
> derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff, 
> derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff, 
> derby-6856-05-ac-roundingMode-Class.newInstance.diff
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like 
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see 
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool 
> which we use so that old JVMs can compile Derby and so that Derby can be 
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the 
> development cycle of Java 9.



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

[jira] [Commented] (DERBY-6854) Make it possible to run Derby tests on early access versions of JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6854:
---

Hi Bryan,

I don't think this will have any effect on how JDBC drivers are loaded. The 
platform class loader is an ancestor of the system class loader (aka 
application class loader), so the JDBC classes will still be visible to the 
application, even though they are no longer in the bootstrap class loader.

The platform class loader is a new concept in JDK 9, related to the 
modularization of the Java platform libraries, so I'm not sure if there are any 
good introductions yet. But at least the JDK 9 javadocs mention the various 
class loaders, see 
[http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders]:

{quote}
The Java run-time has the following built-in class loaders:

- Bootstrap class loader. It is the virtual machine's built-in class 
loader, typically represented as null, and does not have a parent.
- Platform class loader. All platform classes are visible to the platform 
class loader that can be used as the parent of a ClassLoader instance. Platform 
classes include Java SE platform APIs, their implementation classes and 
JDK-specific run-time classes that are defined by the platform class loader or 
its ancestors.
- System class loader. It is also known as application class loader and is 
distinct from the platform class loader. The system class loader is typically 
used to define classes on the application class path, module path, and 
JDK-specific tools. The platform class loader is a parent or an ancestor of the 
system class loader that all platform classes are visible to it.
{quote}

So it seems like the classes made available by the bootstrap class loader in 
JDK 8 have been split between a smaller bootstrap class loader and a platform 
class loader in JDK 9. Presumably in order to have a smaller set of highly 
privileged core classes. Classes in the bootstrap class loader implicitly have 
all privileges, I think, whereas classes outside of the bootstrap loader can be 
granted a more limited set of privileges.

> Make it possible to run Derby tests on early access versions of JDK 9
> -
>
> Key: DERBY-6854
> URL: https://issues.apache.org/jira/browse/DERBY-6854
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: d6854-classloader.diff, derby-6854-01-aa-fixFor9-ea.diff
>
>
> Early access versions of JDK 9 (build 100) have "9-ea" as the java.version 
> and "9" as the java.specification.version. This confuses the 
> JavaVersionHolder class which the regression tests use in order to determine 
> the vm level. At a minimum, we need to make JavaVersionHolder recognize these 
> early access strings.
> This issue can be left open even after a fix is applied because we have no 
> idea how java.version and java.specification.version are going to evolve over 
> the remaining development cycle for JDK 9.



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

[jira] [Updated] (DERBY-6854) Make it possible to run Derby tests on early access versions of JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6854:
--
Attachment: d6854-classloader.diff

The JDBC classes are about to be moved out of the boot class loader and into 
the platform class loader in JDK 9. See 
[JDK-8154189|https://bugs.openjdk.java.net/browse/JDK-8154189] in the OpenJDK 
bug tracker for details.

I ran the regression tests with JDK 9 patched up with the changes suggested in 
the OpenJDK bug report to see if it would break anything. With sane jars, most 
of the tests that ran under a security manager failed with 
AccessControlExceptions. It looked better with insane jars, but there were 
still failures (NoClassDefFoundErrors) in the upgrade tests and 
SysinfoLocaleTest.

The reason is that Derby has some test and debug code that assumes that the 
JDBC classes live in the boot class loader:

1) Some tests create a new class loader in order to make the test load the 
Derby classes afresh (SysinfoLocaleTest), or to test against a different 
version of Derby (the upgrade tests). To achieve this, they create a 
URLClassLoader which contains the Derby jar files they want to test against, 
and set the parent of the URLClassLoader to null, which means that the boot 
class loader is the parent.

Now that the JDBC classes are not on the boot class loader, this URLClassLoader 
is not able to find the JDBC classes, and the tests fail with 
NoClassDefFoundErrors when trying to load them.

This is fixed by setting the parent of the created URLClassLoader to what 
java.sql.Connection.class.getClassLoader() returns. On JDK 8 and earlier it 
returns null, so nothing changes there. On JDK 9 it returns the platform class 
loader, which is capable of loading the JDBC classes.

2) The org.apache.derby.impl.services.bytecode.d_BCValidate class contains some 
debug code (only included in the sane jars) which runs some sanity checks on 
the generated byte code. To do this, it accesses the class loader of all the 
classes in the method signatures.

When getClassLoader() is called on JDBC classes, a RuntimePermission is needed 
now. This was not the case before when the JDBC classes were in the boot class 
loader, since Class.getClassLoader() does not check for permissions if the 
class loader is null. Now this causes an AccessControlException in tests that 
run with a security manager. The tests actually grant the required permission 
to derby.jar, but the call is not wrapped in AccessController.doPrivileged(), 
so it fails because the permission is not granted to the test code.

The fix is to wrap the call to getClassLoader() in a doPrivileged() block. 
Additionally, because RuntimePermission("getClassLoader") is not a mandatory 
permission for derby.jar, we need to check if it raises a security exception. 
d_BCValidate only needs the class loader in order to check if it is the same 
class loader as d_BCValidate's own class loader. Since Class.getClassLoader() 
does not require any permissions if the class has the same class loader as the 
calling class, we can conclude that the class loaders are different if a 
security exception is raised.

The attached patch [^d6854-classloader.diff] makes those changes. With this 
patch, the tests run cleanly both with JDK 8 and with JDK 9 in my environment.

> Make it possible to run Derby tests on early access versions of JDK 9
> -
>
> Key: DERBY-6854
> URL: https://issues.apache.org/jira/browse/DERBY-6854
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: d6854-classloader.diff, derby-6854-01-aa-fixFor9-ea.diff
>
>
> Early access versions of JDK 9 (build 100) have "9-ea" as the java.version 
> and "9" as the java.specification.version. This confuses the 
> JavaVersionHolder class which the regression tests use in order to determine 
> the vm level. At a minimum, we need to make JavaVersionHolder recognize these 
> early access strings.
> This issue can be left open even after a fix is applied because we have no 
> idea how java.version and java.specification.version are going to evolve over 
> the remaining development cycle for JDK 9.



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

Re: svn commit: r1742756 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java

[Knut Anders Hatlen]

bpendle...@apache.org writes:

> Author: bpendleton
> Date: Sat May  7 21:20:42 2016
> New Revision: 1742756
>
> URL: http://svn.apache.org/viewvc?rev=1742756&view=rev
> Log:
> DERBY-6856: Make it possible to build Derby using JDK 9
>
> This change reverts one particular change from revision 1742289.
>
> The java.util.List class supports two remove methods:
> remove(Object o) and remove(int i). In the DatabaseMetaDataTest's
> testGetTypeInfo test, there is a List, and changing
> the autoboxing code to call remove(Types.BOOLEAN) rather than
> remove(new Integer(Types.BOOLEAN)) caused the JDK 8 compiler to
> choose remove(int i) rather than remove(Object o), thus
> causing failures in the upgrade test suite.
>
> This change returns the test code to using the explicit
> object creation in order to ensure we call remove(Object o).
>
>
> Modified:
> 
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
>
> Modified: 
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
> URL: 
> http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java?rev=1742756&r1=1742755&r2=1742756&view=diff
> ==
> --- 
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
>  (original)
> +++ 
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
>  Sat May  7 21:20:42 2016
> @@ -2325,7 +2325,7 @@ public class DatabaseMetaDataTest extend
>  // DERBY-4946: Boolean isn't supported if DB is soft-upgraded from
>  // pre-10.7 version
>  if (!booleanSupported) {
> -supportedTypes.remove(Types.BOOLEAN);
> +supportedTypes.remove(new Integer(Types.BOOLEAN));

Good catch!

I think

   supportedTypes.remove(Integer.valueOf(Types.BOOLEAN));

would have the additional benefits of removing the warning on JDK 9 and
using the internal cache of Integer objects to avoid allocation, while
still picking the correct overload of List.remove().

>  }
>  
>  // Rows are returned from getTypeInfo in order of

-- 
Knut Anders

Re: [Java DB - testing] Failure continuous trunk (rev 1742057)

[Knut Anders Hatlen]

ingemar.ab...@oracle.com writes:

> Java DB testing and reporting infrastructure.
>
> Failure continuous trunk (rev 1742057)
>
> There were 2 failures.

The two failures were in derbyall. The test report is included below.
Both tests failed when attempting to rename a file. Looks very similar
to a failure that was previously reported as DERBY-1418 (closed as not
reproducible), so probably not a new problem with the latest commits.

Generating report for RunSuite derbyall  null null null true 
-- Java Information --
Java Version:1.8.0_92
Java Vendor: Oracle Corporation
Java home:   
c:\tendril4\work\install\sun-jdk-8u92-promoted-latest\jdk\jdk1.8.0_92\jre
Java classpath:  
c:\tendril4\work\run\28718531\jars\sane\derbyTesting.jar;c:\tendril4\work\run\28718531\jars\sane\derbyrun.jar;c:\tendril4\work\run\28718531\tools\java\junit.jar;c:\tendril4\work\install\jakarta-oro-2.0.8\jakarta-oro-2.0.8.jar
OS name: Windows 8.1
OS architecture: amd64
OS version:  6.3
Java user name:  jrockitqa
Java user home:  C:\Users\jrockitqa
Java user dir:   c:\tendril4\work\run\28718531\output
java.specification.name: Java Platform API Specification
java.specification.version: 1.8
java.runtime.version: 1.8.0_92-b14
- Derby Information 
[C:\tendril4\work\run\28718531\jars\sane\derby.jar] 10.13.0.0 alpha - (1742057)
[C:\tendril4\work\run\28718531\jars\sane\derbytools.jar] 10.13.0.0 alpha - 
(1742057)
[C:\tendril4\work\run\28718531\jars\sane\derbynet.jar] 10.13.0.0 alpha - 
(1742057)
[C:\tendril4\work\run\28718531\jars\sane\derbyclient.jar] 10.13.0.0 alpha - 
(1742057)
[C:\tendril4\work\run\28718531\jars\sane\derbyoptionaltools.jar] 10.13.0.0 
alpha - (1742057)
--
- Locale Information -
Current Locale :  [English/United States [en_US]]
Found support for locale: [cs]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [de_DE]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [es]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [fr]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [hu]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [it]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [ja_JP]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [ko_KR]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [pl]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [pt_BR]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [ru]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [zh_CN]
 version: 10.13.0.0 alpha - (1742057)
Found support for locale: [zh_TW]
 version: 10.13.0.0 alpha - (1742057)
--
org.apache.derbyTesting.*:
 [C:\tendril4\work\run\28718531\jars\sane\derbyTesting.jar]
 version: 10.13.0.0 alpha - (1742057)
--
Test environment information:
COMMAND LINE STYLE: jdk13
TEST CANONS: master
--
--
Summary results:

Test Run Started: 2016-05-03 05:26:08.0
Test Run Duration: 00:26:32

115 Tests Run
98% Pass (113 tests passed)
 2% Fail (2 tests failed)
0 Suites skipped
--
Failed tests in: derbyall_fail.txt
--
Passed tests in: derbyall_pass.txt
--
System properties in: derbyall_prop.txt
--
--
Failure Details:
* Diff file 
derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff
*** Start: TestEnc jdk1.8.0_92 DerbyNetClient derbynetclientmats:encodingTests 
2016-05-03 05:37:19 ***
derbyTesting.encoding can only be used with jdk15, skipping test
*** End:   TestEnc jdk1.8.0_92 DerbyNetClient derbynetclientmats:encodingTests 
2016-05-03 05:37:19 ***
* Diff file 
derbyall/encryptionAll/encryptionAll/encryptDatabaseTest3.diff
*** Start: encryptDatabaseTest3 jdk1.8.0_92 encryptionAll:encryptionAll 
2016-05-03 05:38:38 ***
245 del
< 0 rows inserted/updated/deleted
245a245
> ERROR XSRS4: Error renaming file (during backup) from 
> extinout\mybackup2\wombat to extinout\mybackup2\wombat.OLD.
255a256,274
> ij> -- reboot the db and disable the log archive mode
> connect 'jdbc:derby:wombat;encryptionKey=6162636465666768';
> ij(CONNECTION1)> select * from t1;
> A  
> ---
> 1  
> 2  
> 3  
> 3 rows selected
> ij(CONNECTION1)> call SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(1);
> 0 rows inserted/updated/deleted
> i

[jira] [Commented] (DERBY-6884) SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE bytes of blob data

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6884:
---

JustChangeOffset.diff looks good to me. Except that jardriftcheck fails when 
building the jar files, because of the new class in derbyTesting.jar. +1 to 
commit when that's fixed.

A couple of nits:

{noformat}
--- java/engine/org/apache/derby/impl/load/ImportLobFile.java   (revision 
1741376)
+++ java/engine/org/apache/derby/impl/load/ImportLobFile.java   (working copy)
@@ -128,7 +128,7 @@
  * @param length  length of the the data.
  * @exception  IOException  on any I/O error. 
  */
-public String getString(int offset, int length) throws IOException {
+public String getString(long offset, int length) throws IOException {
 lobInputStream.seek(offset);
 lobLimitIn.clearLimit();
 lobLimitIn.setLimit((int) length);
{noformat}

While you're at it, maybe also remove the redundant cast of length to int in 
the above call to setLimit(), so that readers don't have to spend cycles 
figuring out what the purpose of the cast is?

You might also want to clean up the indentation in the test case. It uses a mix 
of tabs and spaces, and it doesn't always seem to agree with itself if tabs are 
4 or 8 characters wide.

{noformat}
+PreparedStatement ps = getConnection().prepareStatement(
+ "insert into DERBY_6884_TESTCLOB values(? , ?)" );
{noformat}

BaseJDBCTestCase has a helper method for preparing statments, so the above 
could have been replaced with the slightly simpler

{code}
PreparedStatement ps = prepareStatement(
 "insert into DERBY_6884_TESTCLOB values(? , ?)" );
{code}

Then you don't have to close the prepared statement manually in the test case.

> SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE 
> bytes of blob data
> 
>
> Key: DERBY-6884
> URL: https://issues.apache.org/jira/browse/DERBY-6884
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Edward Howe
> Attachments: DerbyIssue.java, JustChangeOffset.diff, 
> firstTryAtTest.diff, testForLargeDataSuite.diff, trivial.diff
>
>
> Using SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE to export a table containing a blob 
> column, SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE  will fail with a 
> NumberFormatException if the offset for a blob record is > Integer.MAX_VALUE. 
>  This is because ImportReadData.initExternalLobFile() is parsing the offset 
> as an Integer.
> The stack trace and a program to reproduce are below.
> java.lang.NumberFormatException: For input string: "2147483770"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:583) ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_45]
>   at 
> org.apache.derby.impl.load.ImportReadData.initExternalLobFile(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.load.ImportReadData.getBlobColumnFromExtFile(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.ImportAbstract.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.Import.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.iapi.types.SQLBlob.setValueFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.d

[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6856:
---

Looks like a good cleanup. +1 to commit.

Some nits:

{noformat}
--- 
java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
(revision 1737511)
+++ 
java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
(working copy)
@@ -1835,7 +1835,7 @@
" y char(100))");
 s.execute("create table assocout(x char(10))");
 ps = prepareStatement("insert into assoc values (?, 'hello')");
-ps.setString(1, new Integer(10).toString());
+ps.setString(1, Integer.toString(10));
 ps.executeUpdate(); 
{noformat}

Maybe just {{ps.setString(1, "10");}} here?

{noformat}
--- 
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/StatementTest.java
   (revision 1737511)
+++ 
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/StatementTest.java
   (working copy)
@@ -703,7 +703,7 @@
 (
  "setLargeMaxRows",
  new Class[] { Long.TYPE },
- new Object[] { new Long( max ) }
+ new Object[] { (long) max }
  );
{noformat}

max is already a long, so the cast is redundant.

> Make it possible to build Derby using JDK 9
> ---
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff, 
> derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff, 
> derby-6856-03-aa-autoboxingDeprecationWarnings.diff
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like 
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see 
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool 
> which we use so that old JVMs can compile Derby and so that Derby can be 
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the 
> development cycle of Java 9.



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

[jira] [Updated] (DERBY-6827) Errors in LocalizedDisplayScriptTest on jdk 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6827:
--
Fix Version/s: 10.11.1.3

> Errors in LocalizedDisplayScriptTest on jdk 9
> -
>
> Key: DERBY-6827
> URL: https://issues.apache.org/jira/browse/DERBY-6827
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Reporter: Rick Hillegas
> Fix For: 10.11.1.3, 10.12.1.1
>
> Attachments: derby-6827-01-aa-addProperty.diff, 
> derby-6827-01-ab-omitColumn.diff, z.out
>
>
> LocalizedDisplayScriptTest raises errors when run with the latest early 
> access build of JDK 9. This is due to a backward incompatibility introduced 
> into JDK 9 by this issue: https://bugs.openjdk.java.net/browse/JDK-8008577. 
> The fix may be simply to set the following java property when running this 
> test:
> java.locale.providers=JRE,SPI



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

[jira] [Updated] (DERBY-6827) Errors in LocalizedDisplayScriptTest on jdk 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6827:
--
Fix Version/s: (was: 10.13.0.0)
   10.12.1.1

Adjusting the fixed version. The fix went into 10.12.1.1.

> Errors in LocalizedDisplayScriptTest on jdk 9
> -
>
> Key: DERBY-6827
> URL: https://issues.apache.org/jira/browse/DERBY-6827
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Reporter: Rick Hillegas
> Fix For: 10.12.1.1
>
> Attachments: derby-6827-01-aa-addProperty.diff, 
> derby-6827-01-ab-omitColumn.diff, z.out
>
>
> LocalizedDisplayScriptTest raises errors when run with the latest early 
> access build of JDK 9. This is due to a backward incompatibility introduced 
> into JDK 9 by this issue: https://bugs.openjdk.java.net/browse/JDK-8008577. 
> The fix may be simply to set the following java property when running this 
> test:
> java.locale.providers=JRE,SPI



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

[jira] [Updated] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6881:
--
Fix Version/s: 10.11.1.3

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.11.1.3, 10.12.1.2, 10.13.0.0
>
> Attachments: d6881-classloader.diff, d6881-sed.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
>   at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
> Method)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
> {noformat}
> CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
> LocalizedDisplayScriptTest have failures, for example:
> {noformat}
> junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', 
> row 1:
> Expected: >4<
> Found:>6<
> ID,NAME
> -- 
>[6, aacorn]
>[4, Acorn]
>[2, Ącorn]
>[0, Smith]
>[5, Śmith]
>[1, Zebra]
>[3, Żebra]
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
>   at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: junit.framework.AssertionFailedError: Column value mismatch @ 
> column 'ID', row 1:
> Expected: >4<
> Found:>6<
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1492)
> {noformat}
> And the stack trace deletion patterns in the Sed class seem to be missing out 
> on some stack frames now, causing failures like this one in dblook_test and 
> dblook_test_territory:
> {noformat}
> * Diff file derbyall/derbytools/dblook_test.diff
> *** Start: dblook_test jdk9-ea derbyall:derbytools 2016-03-29 14:16:38 ***
> 6511a6512
> > at java.io.FileInputStream.open0(java.base@9-ea/Native Method)
> Test Failed.
> {noformat}



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

[jira] [Updated] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6881:
--
Fix Version/s: 10.12.1.2

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.12.1.2, 10.13.0.0
>
> Attachments: d6881-classloader.diff, d6881-sed.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
>   at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
> Method)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
> {noformat}
> CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
> LocalizedDisplayScriptTest have failures, for example:
> {noformat}
> junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', 
> row 1:
> Expected: >4<
> Found:>6<
> ID,NAME
> -- 
>[6, aacorn]
>[4, Acorn]
>[2, Ącorn]
>[0, Smith]
>[5, Śmith]
>[1, Zebra]
>[3, Żebra]
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
>   at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: junit.framework.AssertionFailedError: Column value mismatch @ 
> column 'ID', row 1:
> Expected: >4<
> Found:>6<
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1492)
> {noformat}
> And the stack trace deletion patterns in the Sed class seem to be missing out 
> on some stack frames now, causing failures like this one in dblook_test and 
> dblook_test_territory:
> {noformat}
> * Diff file derbyall/derbytools/dblook_test.diff
> *** Start: dblook_test jdk9-ea derbyall:derbytools 2016-03-29 14:16:38 ***
> 6511a6512
> > at java.io.FileInputStream.open0(java.base@9-ea/Native Method)
> Test Failed.
> {noformat}



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

[jira] [Closed] (DERBY-6885) Remove ReuseFactory

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6885.
-
  Resolution: Fixed
   Fix Version/s: 10.13.0.0
Issue & fix info:   (was: Patch Available)

> Remove ReuseFactory
> ---
>
> Key: DERBY-6885
> URL: https://issues.apache.org/jira/browse/DERBY-6885
> Project: Derby
>  Issue Type: Improvement
>  Components: Services
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
>Priority: Minor
> Fix For: 10.13.0.0
>
> Attachments: d6885.diff
>
>
> ReuseFactory used to help reduce object allocations when converting 
> numbers/booleans from primitive types to object types. After DERBY-2383 and 
> DERBY-6230, the ReuseFactory methods are just wrappers around standard 
> library methods such as Integer.valueOf() and Long.valueOf().
> Callers could just as easily call the corresponding valueOf() method 
> directly, or rely on auto-boxing. Both ways use the same cache as 
> ReuseFactory currently does, so ReuseFactory has no purpose anymore.
> One exception: ReuseFactory.getZeroLenByteArray() is still used and provides 
> value, as it avoids the allocation cost when an empty byte array is needed. 
> The ArrayUtil class is probably just as good a home for it, so I propose we 
> move it there and remove the ReuseFactory class.



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

[jira] [Commented] (DERBY-6885) Remove ReuseFactory

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6885:
---

Thanks for reviewing the patch, Bryan.

The PrivilegedAction must still be declared as PrivilegedAction 
because Java doesn't allow primitive types as type parameters in generic types.

The success variable doesn't really have to be a boolean, it could just as well 
have continued to be a Boolean. The only difference is whether the implicit 
conversion from Boolean to boolean happens in the assignment or in the if 
statement. The two alternatives are essentially equivalent. I don't see any 
particular benefits one way or the other.

It is possible to eliminate the success variable. The compiler accepts the last 
code snippet in your comment, and will generate a call to booleanValue() on the 
Boolean returned by doPrivileged(). We can even eliminate the pa variable, like 
this:

{code}
if (!AccessController.doPrivileged((PrivilegedAction)
() -> FileUtil.copyFile(dataFactory.getStorageFactory(),
from, to))) {
// 
}
{code}

I can make this change if you prefer the shorter version.

> Remove ReuseFactory
> ---
>
> Key: DERBY-6885
> URL: https://issues.apache.org/jira/browse/DERBY-6885
> Project: Derby
>  Issue Type: Improvement
>  Components: Services
>Affects Versions: 10.13.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Attachments: d6885.diff
>
>
> ReuseFactory used to help reduce object allocations when converting 
> numbers/booleans from primitive types to object types. After DERBY-2383 and 
> DERBY-6230, the ReuseFactory methods are just wrappers around standard 
> library methods such as Integer.valueOf() and Long.valueOf().
> Callers could just as easily call the corresponding valueOf() method 
> directly, or rely on auto-boxing. Both ways use the same cache as 
> ReuseFactory currently does, so ReuseFactory has no purpose anymore.
> One exception: ReuseFactory.getZeroLenByteArray() is still used and provides 
> value, as it avoids the allocation cost when an empty byte array is needed. 
> The ArrayUtil class is probably just as good a home for it, so I propose we 
> move it there and remove the ReuseFactory class.



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

[jira] [Updated] (DERBY-6885) Remove ReuseFactory

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6885:
--
Attachment: d6885.diff

The attached patch ([^d6885.diff]) replaces all calls to 
ReuseFactory.getInteger() and friends with auto-boxing. This simplifies the 
calling code a little. The changes are for the most part automatic (using 
Refactor->Inline in NetBeans), with a little bit of polishing to revert some 
formatting changes.

The patch also replaces ReuseFactory.getZeroLenByteArray() with a static 
constant ArrayUtil.EMPTY_BYTE_ARRAY. And it removes the now unused ReuseFactory 
class.

> Remove ReuseFactory
> ---
>
> Key: DERBY-6885
> URL: https://issues.apache.org/jira/browse/DERBY-6885
> Project: Derby
>  Issue Type: Improvement
>  Components: Services
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Attachments: d6885.diff
>
>
> ReuseFactory used to help reduce object allocations when converting 
> numbers/booleans from primitive types to object types. After DERBY-2383 and 
> DERBY-6230, the ReuseFactory methods are just wrappers around standard 
> library methods such as Integer.valueOf() and Long.valueOf().
> Callers could just as easily call the corresponding valueOf() method 
> directly, or rely on auto-boxing. Both ways use the same cache as 
> ReuseFactory currently does, so ReuseFactory has no purpose anymore.
> One exception: ReuseFactory.getZeroLenByteArray() is still used and provides 
> value, as it avoids the allocation cost when an empty byte array is needed. 
> The ArrayUtil class is probably just as good a home for it, so I propose we 
> move it there and remove the ReuseFactory class.



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

[jira] [Updated] (DERBY-6885) Remove ReuseFactory

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6885:
--
Issue & fix info: Patch Available

> Remove ReuseFactory
> ---
>
> Key: DERBY-6885
> URL: https://issues.apache.org/jira/browse/DERBY-6885
> Project: Derby
>  Issue Type: Improvement
>  Components: Services
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
>Priority: Minor
> Attachments: d6885.diff
>
>
> ReuseFactory used to help reduce object allocations when converting 
> numbers/booleans from primitive types to object types. After DERBY-2383 and 
> DERBY-6230, the ReuseFactory methods are just wrappers around standard 
> library methods such as Integer.valueOf() and Long.valueOf().
> Callers could just as easily call the corresponding valueOf() method 
> directly, or rely on auto-boxing. Both ways use the same cache as 
> ReuseFactory currently does, so ReuseFactory has no purpose anymore.
> One exception: ReuseFactory.getZeroLenByteArray() is still used and provides 
> value, as it avoids the allocation cost when an empty byte array is needed. 
> The ArrayUtil class is probably just as good a home for it, so I propose we 
> move it there and remove the ReuseFactory class.



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

[jira] [Created] (DERBY-6885) Remove ReuseFactory

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6885:
-

 Summary: Remove ReuseFactory
 Key: DERBY-6885
 URL: https://issues.apache.org/jira/browse/DERBY-6885
 Project: Derby
  Issue Type: Improvement
  Components: Services
Affects Versions: 10.13.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor


ReuseFactory used to help reduce object allocations when converting 
numbers/booleans from primitive types to object types. After DERBY-2383 and 
DERBY-6230, the ReuseFactory methods are just wrappers around standard library 
methods such as Integer.valueOf() and Long.valueOf().

Callers could just as easily call the corresponding valueOf() method directly, 
or rely on auto-boxing. Both ways use the same cache as ReuseFactory currently 
does, so ReuseFactory has no purpose anymore.

One exception: ReuseFactory.getZeroLenByteArray() is still used and provides 
value, as it avoids the allocation cost when an empty byte array is needed. The 
ArrayUtil class is probably just as good a home for it, so I propose we move it 
there and remove the ReuseFactory class.



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

[jira] [Commented] (DERBY-6884) SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE bytes of blob data

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6884:
---

I agree that the casts from long to int look a bit suspicious. Wouldn't they 
end up as negative values? The test case doesn't seem to exercise that part of 
the code, so it's difficult to verify that it works correctly. (I replaced the 
modified lines in getClobColumnFromExtFileAsString() with "throw new 
RuntimeException()", and the test case still passed.)

> SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE 
> bytes of blob data
> 
>
> Key: DERBY-6884
> URL: https://issues.apache.org/jira/browse/DERBY-6884
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Edward Howe
> Attachments: DerbyIssue.java, trivial.diff
>
>
> Using SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE to export a table containing a blob 
> column, SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE  will fail with a 
> NumberFormatException if the offset for a blob record is > Integer.MAX_VALUE. 
>  This is because ImportReadData.initExternalLobFile() is parsing the offset 
> as an Integer.
> The stack trace and a program to reproduce are below.
> java.lang.NumberFormatException: For input string: "2147483770"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:583) ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_45]
>   at 
> org.apache.derby.impl.load.ImportReadData.initExternalLobFile(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.load.ImportReadData.getBlobColumnFromExtFile(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.ImportAbstract.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.Import.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.iapi.types.SQLBlob.setValueFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   ... 36 common frames omitted
> ==
> package blob;
> import java.io.BufferedInputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.sql.*;
> public final class DerbyIssue {
> // derby url
> public static final String DBURL = "jdbc:derby:testdb;create=true";
> // any random binary file such as a large image or document
> public static final String BLOB_DATA_FILE = "...";
> public static final String EXPORT_TABLE_FILE = "table-data";
> public static final String EXPORT_BLOB_FILE = "blob-data";
>  

[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6856:
---

Similar failures have been seen in NetworkServerControlClientCommandTest with 
older versions of the JDK. See for example DERBY-5942 and DERBY-4762 (both 
closed as "cannot reproduce").

> Make it possible to build Derby using JDK 9
> ---
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff, 
> derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like 
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see 
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool 
> which we use so that old JVMs can compile Derby and so that Derby can be 
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the 
> development cycle of Java 9.



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

[jira] [Closed] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6881.
-
   Resolution: Fixed
 Assignee: Knut Anders Hatlen
Fix Version/s: 10.13.0.0

The remaining test failures were fixed in JDK 9-ea b113. Closing the issue.

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6881-classloader.diff, d6881-sed.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
>   at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
> Method)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
> {noformat}
> CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
> LocalizedDisplayScriptTest have failures, for example:
> {noformat}
> junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', 
> row 1:
> Expected: >4<
> Found:>6<
> ID,NAME
> -- 
>[6, aacorn]
>[4, Acorn]
>[2, Ącorn]
>[0, Smith]
>[5, Śmith]
>[1, Zebra]
>[3, Żebra]
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
>   at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: junit.framework.AssertionFailedError: Column value mismatch @ 
> column 'ID', row 1:
> Expected: >4<
> Found:>6<
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1492)
> {noformat}
> And the stack trace deletion patterns in the Sed class see

[jira] [Commented] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6881:
---

CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
LocalizedDisplayScriptTest are still failing. Likely because of the following 
JDK bug: https://bugs.openjdk.java.net/browse/JDK-8152817

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
> Attachments: d6881-classloader.diff, d6881-sed.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
>   at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
> Method)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
> {noformat}
> CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
> LocalizedDisplayScriptTest have failures, for example:
> {noformat}
> junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', 
> row 1:
> Expected: >4<
> Found:>6<
> ID,NAME
> -- 
>[6, aacorn]
>[4, Acorn]
>[2, Ącorn]
>[0, Smith]
>[5, Śmith]
>[1, Zebra]
>[3, Żebra]
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
>   at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: junit.framework.AssertionFailedError: Column value mismatch @ 
> column 'ID', row 1:
> Expected: >4<
> Found:>6<
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1492)
> {noformat}
> And the stack trace deletion patterns in the Sed

[jira] [Commented] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6881:
---

Hi Bryan. Thanks for reviewing the patches.

Regarding the following line:
{code}
PrivilegedAction pa = () -> new URLClassLoader(new URL[0]);
{code}
Everything up to the equals sign is as before. That is, we're declaring a 
variable pa of type PrivilegedAction and assigning a value to it.

What comes after the equals sign, is a so-called lambda expression. A lambda 
expression can be used where an instance of an interface with a single abstract 
method is expected. PrivilegedAction is such an interface (it has one method: 
run()).

The lambda expression specifies how that method is implemented. It consists of 
an argument list, an arrow (->) and then the function body. In this case, the 
argument list is empty, so it's just a pair of parentheses (). Also, since the 
method body consists of a single statement, we can use the shorthand syntax 
where the method body has no curly braces around it and the "return" keyword is 
left out. We could have chosen not to use the shorthand syntax and written this 
instead:
{code}
PrivilegedAction pa = () -> {
return new URLClassLoader(new URL[0]);
});
{code}

One would often inline the lambda expression, rather than creating a helper 
variable like I did in the patch. However, the obvious code
{code}
AccessController.doPrivileged(() -> new URLClassLoader(new URL[0]));
{code}
does not get accepted by the compiler. The reason is that there are two 
variants of AccessController.doPrivileged(); one that takes a PrivilegedAction, 
and one that takes a PrivilegedExceptionAction. The compiler cannot tell which 
one we want to call without a little help. One way is to create a helper 
variable of the desired type, like I did. Another way is to add a cast to give 
the compiler more context:
{code}
AccessController.doPrivileged((PrivilegedAction) () -> new URLClassLoader(new 
URL[0]));
{code}
If lambda expressions had been supported when the AccessController class was 
added, I'm sure this clash and the resulting inconvenience would have been 
avoided.

Lambda expressions can in many cases be used as a replacement for anonymous 
inner classes. The most obvious advantage is that lambda expressions have much 
less boilerplate than anonymous inner classes. It also slightly reduces the 
footprint of the jar files. If you inspect the contents of derbyTesting.jar, 
you'll see that the file 
{{org/apache/derbyTesting/junit/ClassLoaderTestSetup$3.class}} has disappeared, 
and no new class has been added to it.

This suggests that lambda expressions are not simply translated to a 
corresponding anonymous inner class by the compiler. In fact, the JVM can 
optimize this for us and produce code that performs better than the 
corresponding anonymous inner class. For example, in this case, it can probably 
see that the lambda expression is stateless, and produce a single instance that 
is reused every time this code is executed. In contrast, the corresponding 
anonymous class would have been instantiated every time, unless we added even 
more boilerplate to cache a singleton instance manually. Not that we care much 
about performance in the test code, but it's nice that the JVM can do this for 
us automatically so that we don't have to do anything special in the places 
where we do care about performance.

I haven't used these new features much myself, so everything above is probably 
better and more correctly explained by the Java tutorial on lambda expressions: 
https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>      Components: Test
>Affects Versions: 10.13.0.0
>Reporter: Knut Anders Hatlen
> Attachments: d6881-classloader.diff, d6881-sed.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestS

[jira] [Updated] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6881:
--
Attachment: d6881-sed.diff

Attaching another patch, d6881-sed.diff, which fixes the failures in the dblook 
tests. It updates the Sed class to recognize both the old format and the new 
format of stack traces.

Specifically, the stack traces used to contain a line that looked like this:

  at java.io.FileInputStream.open0(Native Method)

With the latest build of JDK 9-ea, it has changed to this:

  at java.io.FileInputStream.open0(java.base@9-ea/Native Method)

The regular expression that recognized the former, has been updated to also 
recognize the latter.

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
> Attachments: d6881-classloader.diff, d6881-sed.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
>   at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
> Method)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
> {noformat}
> CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
> LocalizedDisplayScriptTest have failures, for example:
> {noformat}
> junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', 
> row 1:
> Expected: >4<
> Found:>6<
> ID,NAME
> -- 
>[6, aacorn]
>[4, Acorn]
>[2, Ącorn]
>[0, Smith]
>[5, Śmith]
>[1, Zebra]
>[3, Żebra]
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
>   at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: junit.fram

[jira] [Updated] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6881:
--
Attachment: d6881-classloader.diff

The attached patch, d6881-classloader.diff, seems to fix the problem with 
ClassLoaderTestSetup.

The purpose of ClassLoaderTestSetup is to make a test case run with a 
non-default context class loader. It is only used by one test case, in 
SecureServerTest to test the fix for the class loader leak in DERBY-6619. The 
way it does this currently, is by cloning the original context class loader, 
which happens to be the application class loader. As 
http://openjdk.java.net/jeps/261 explains, the application class loader is a 
URLClassLoader from Java 1.2 to Java 8, but it is some internal class in Java 
9. When ClassLoaderTestSetup casts it to URLClassLoader, it consequently throws 
a ClassCastException with Java 9.

It turns out that the new context class loader does not need to be a clone of 
the original class loader for the purpose of this test. It seems to be 
sufficient that it is some other class loader than the system class loader in 
order to exercise the code path we want to test. The patch therefore changes 
ClassLoaderTestSetup to create an empty URLClassLoader that wraps the system 
class loader. This way we avoid the unreliable cast that causes problems on 
Java 9. SecureServerTest passes both on Java 8 and Java 9-ea b111 with this 
patch.

> Test failures with JDK 9-ea b111
> 
>
> Key: DERBY-6881
> URL: https://issues.apache.org/jira/browse/DERBY-6881
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
> Attachments: d6881-classloader.diff
>
>
> With JDK 9-ea b111 there are a number of test failures.
> Tests that use ClassLoaderTestSetup fail because the context class loader no 
> longer is a URLClassLoader, which causes a ClassCastException in the class 
> loader magic performed by the test setup:
> {noformat}
> java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
> (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
> java.base)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
>   at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
> Method)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
>   at 
> org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
> {noformat}
> CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
> LocalizedDisplayScriptTest have failures, for example:
> {noformat}
> junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', 
> row 1:
> Expected: >4<
> Found:>6<
> ID,NAME
> -- 
>[6, aacorn]
>[4, Acorn]
>[2, Ącorn]
>[0, Smith]
>[5, Śmith]
>[1, Zebra]
>[3, Żebra]
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
>   at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
>   at 
> org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.e

[jira] [Created] (DERBY-6881) Test failures with JDK 9-ea b111

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6881:
-

 Summary: Test failures with JDK 9-ea b111
 Key: DERBY-6881
 URL: https://issues.apache.org/jira/browse/DERBY-6881
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.13.0.0
Reporter: Knut Anders Hatlen


With JDK 9-ea b111 there are a number of test failures.

Tests that use ClassLoaderTestSetup fail because the context class loader no 
longer is a URLClassLoader, which causes a ClassCastException in the class 
loader magic performed by the test setup:

{noformat}
java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader 
(in module: java.base) cannot be cast to java.net.URLClassLoader (in module: 
java.base)
at 
org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:53)
at 
org.apache.derbyTesting.junit.ClassLoaderTestSetup$1.run(ClassLoaderTestSetup.java:50)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
Method)
at 
org.apache.derbyTesting.junit.ClassLoaderTestSetup.makeClassLoader(ClassLoaderTestSetup.java:49)
at 
org.apache.derbyTesting.junit.ClassLoaderTestSetup.setUp(ClassLoaderTestSetup.java:64)
at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
{noformat}

CollationTest, CollationTest2, LocalizedAttributeScriptTest and 
LocalizedDisplayScriptTest have failures, for example:

{noformat}
junit.framework.AssertionFailedError: Column value mismatch @ column 'ID', row 
1:
Expected: >4<
Found:>6<

ID,NAME
-- 
   [6, aacorn]
   [4, Acorn]
   [2, Ącorn]
   [0, Smith]
   [5, Śmith]
   [1, Zebra]
   [3, Żebra]

at 
org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1177)
at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1998)
at 
org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1497)
at 
org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1395)
at 
org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1257)
at 
org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1168)
at 
org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1125)
at 
org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1083)
at 
org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:2055)
at 
org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testNorwayCollation(CollationTest.java:482)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: junit.framework.AssertionFailedError: Column value mismatch @ column 
'ID', row 1:
Expected: >4<
Found:>6<
at 
org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1492)
{noformat}

And the stack trace deletion patterns in the Sed class seem to be missing out 
on some stack frames now, causing failures like this one in dblook_test and 
dblook_test_territory:

{noformat}
* Diff file derbyall/derbytools/dblook_test.diff
*** Start: dblook_test jdk9-ea derbyall:derbytools 2016-03-29 14:16:38 ***
6511a6512
>   at java.io.FileInputStream.open0(java.base@9-ea/Native Method)
Test Failed.
{noformat}



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

[jira] [Commented] (DERBY-6828) Network Server don't start in czech localized enviroment due missing key DRDA_MissingNetworkJar.S

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6828:
---

Thanks for testing the approach, Bryan. +1 to commit.

(Later, we may consider doing something similar for the servlet messages and 
the engine messages, and delete the code that manually falls back to English 
messages. But not as part of this bug, I think. The servlet messages use 
LocalizedResource and probably suffer from the same problems as the drda 
messages. I'm not so worried about the servlet messages, though, as we document 
that it's only for testing - DERBY-5653.)

> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S
> -
>
> Key: DERBY-6828
> URL: https://issues.apache.org/jira/browse/DERBY-6828
> Project: Derby
>  Issue Type: Bug
>  Components: Localization, Network Server
>Affects Versions: 10.11.1.1
> Environment: Windows 7 Profesional SP1 64bit (localized CS),
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>Reporter: David Ježek
>Priority: Minor
>  Labels: easyfix
> Attachments: nullGuard.diff
>
>
> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S in file 
> org/apache/derby/loc/drda/messages_cs.properties
> Exception:
> Thu Jul 23 15:56:24 CEST 2015 : null
> java.lang.NullPointerException
> at 
> org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.drda.NetworkServerControl.installSecurityManager(Unknown 
> Source)
> at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
> Missing key is called in file org.apache.derby.drda.NetworkServerControl.java 
> at line 818.
> Reproduce under windows in console run:
> set DERBY_OPTS=-Duser.language=cs
> startNetworkServer.bat
> Workaround:
> Run derby server under en localization.
> Windows consola run:
> set DERBY_OPTS=-Duser.language=en
> startNetworkServer.bat



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

[jira] [Commented] (DERBY-6828) Network Server don't start in czech localized enviroment due missing key DRDA_MissingNetworkJar.S

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6828:
---

As to the missing fallback to English for the messages that lack translation, 
issuing {{svn rename java/drda/org/apache/derby/loc/drda/messages_en.properties 
java/drda/org/apache/derby/loc/drda/messages.properties}} and rebuilding seems 
to fix it for me:

{noformat}
$ java -Dderby.ui.locale=cs -jar /code/derby/trunk/jars/sane/derbynet.jar start 
Mon Feb 15 20:41:17 CET 2016 : Security manager installed using the Basic 
server security policy.
Mon Feb 15 20:41:17 CET 2016 : Síťový server Apache Derby - 10.13.0.0 alpha - 
(Unversioned directory): spuštěn a připraven přijímat připojení na portu 1527 v 
{3} 
{noformat}

If your locale is cs_CZ, ResourceBundle will look for the message in 
messages_cs_CZ.properties. If it is not found there, it will try with a less 
specific locale and look for it in messages_cs.properties. If it is not found 
there either, it will try with an even less specific locale and look for it in 
messages.properties. If we move the English messages from 
messages_en.properties to messages.properties, they will become fallback for 
messages that lack translation to the requested locale.

The tools messages are already structured like this. There is a 
toolsmessages.properties, but not a toolsmessages_en.properties. Since both the 
tools messages and the drda messages are localized using LocalizedResource, I 
think it makes sense if the message files are structured the same way.

The engine messages don't go through LocalizedResource, so they have a 
different mechanism for falling back to English (using MessageService). We 
could probably copy that logic into LocalizedResource. But since we can get 
this functionality for free from java.util.ResourceBundle by renaming a file, I 
don't see much value in copying the code.

> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S
> -
>
> Key: DERBY-6828
> URL: https://issues.apache.org/jira/browse/DERBY-6828
> Project: Derby
>  Issue Type: Bug
>  Components: Localization, Network Server
>Affects Versions: 10.11.1.1
> Environment: Windows 7 Profesional SP1 64bit (localized CS),
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>Reporter: David Ježek
>Priority: Minor
>  Labels: easyfix
> Attachments: nullGuard.diff
>
>
> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S in file 
> org/apache/derby/loc/drda/messages_cs.properties
> Exception:
> Thu Jul 23 15:56:24 CEST 2015 : null
> java.lang.NullPointerException
> at 
> org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.drda.NetworkServerControl.installSecurityManager(Unknown 
> Source)
> at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
> Missing key is called in file org.apache.derby.drda.NetworkServerControl.java 
> at line 818.
> Reproduce under windows in console run:
> set DERBY_OPTS=-Duser.language=cs
> startNetworkServer.bat
> Workaround:
> Run derby server under en localization.
> Windows consola run:
> set DERBY_OPTS=-Duser.language=en
> startNetworkServer.bat



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

[jira] [Commented] (DERBY-6828) Network Server don't start in czech localized enviroment due missing key DRDA_MissingNetworkJar.S

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6828:
---

Jaroslav, I wouldn't count on it...
https://blogs.oracle.com/java-platform-group/entry/deferring_to_derby_in_jdk

> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S
> -
>
> Key: DERBY-6828
> URL: https://issues.apache.org/jira/browse/DERBY-6828
> Project: Derby
>  Issue Type: Bug
>  Components: Localization, Network Server
>Affects Versions: 10.11.1.1
> Environment: Windows 7 Profesional SP1 64bit (localized CS),
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>Reporter: David Ježek
>Priority: Minor
>  Labels: easyfix
> Attachments: nullGuard.diff
>
>
> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S in file 
> org/apache/derby/loc/drda/messages_cs.properties
> Exception:
> Thu Jul 23 15:56:24 CEST 2015 : null
> java.lang.NullPointerException
> at 
> org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.drda.NetworkServerControl.installSecurityManager(Unknown 
> Source)
> at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
> Missing key is called in file org.apache.derby.drda.NetworkServerControl.java 
> at line 818.
> Reproduce under windows in console run:
> set DERBY_OPTS=-Duser.language=cs
> startNetworkServer.bat
> Workaround:
> Run derby server under en localization.
> Windows consola run:
> set DERBY_OPTS=-Duser.language=en
> startNetworkServer.bat



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

[jira] [Commented] (DERBY-6828) Network Server don't start in czech localized enviroment due missing key DRDA_MissingNetworkJar.S

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6828:
---

Agreed. Allowing the server to start is a good step forward. Thanks for fixing 
this.

> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S
> -
>
> Key: DERBY-6828
> URL: https://issues.apache.org/jira/browse/DERBY-6828
> Project: Derby
>  Issue Type: Bug
>  Components: Localization, Network Server
>Affects Versions: 10.11.1.1
> Environment: Windows 7 Profesional SP1 64bit (localized CS),
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>Reporter: David Ježek
>Priority: Minor
>  Labels: easyfix
> Attachments: nullGuard.diff
>
>
> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S in file 
> org/apache/derby/loc/drda/messages_cs.properties
> Exception:
> Thu Jul 23 15:56:24 CEST 2015 : null
> java.lang.NullPointerException
> at 
> org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.drda.NetworkServerControl.installSecurityManager(Unknown 
> Source)
> at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
> Missing key is called in file org.apache.derby.drda.NetworkServerControl.java 
> at line 818.
> Reproduce under windows in console run:
> set DERBY_OPTS=-Duser.language=cs
> startNetworkServer.bat
> Workaround:
> Run derby server under en localization.
> Windows consola run:
> set DERBY_OPTS=-Duser.language=en
> startNetworkServer.bat



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

[jira] [Commented] (DERBY-6828) Network Server don't start in czech localized enviroment due missing key DRDA_MissingNetworkJar.S

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6828:
---

Hi Bryan,

Your patch fixes the immediate problem. Before your patch:

{noformat}
$ java -Duser.language=cs -Dderby.drda.debug=true -jar 
/code/derby/trunk/jars/sane/derbynet.jar start
Fri Feb 12 16:03:52 CET 2016 : null
java.lang.NullPointerException
at 
org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(LocalizedResource.java:293)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(NetworkServerControlImpl.java:3625)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(NetworkServerControlImpl.java:3597)
at 
org.apache.derby.drda.NetworkServerControl.installSecurityManager(NetworkServerControl.java:706)
at 
org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:344)
{noformat}

After your patch:

{noformat}
$ java -Duser.language=cs -Dderby.drda.debug=true -jar 
/code/derby/trunk/jars/sane/derbynet.jar start
Fri Feb 12 16:04:39 CET 2016 : DRDA_SecurityInstalled.I
total memory: 502792192 free: 495416760 Fri Feb 12 16:04:39 CET 2016
total memory: 502792192 free: 494413880 Fri Feb 12 16:04:39 CET 2016
Fri Feb 12 16:04:39 CET 2016 : Síťový server Apache Derby - 10.13.0.0 alpha - 
(Unversioned directory): spuštěn a připraven přijímat připojení na portu 1527 v 
{3} 
{noformat}

I think there are more problems, though:

# Why did the server crash silently if the derby.drda.debug flag wasn't set? I 
think it should have printed the NPE in that case too.
# When a localized message is not available, shouldn't it have printed the 
English message, rather than the key?

> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S
> -
>
> Key: DERBY-6828
> URL: https://issues.apache.org/jira/browse/DERBY-6828
> Project: Derby
>  Issue Type: Bug
>  Components: Localization, Network Server
>Affects Versions: 10.11.1.1
> Environment: Windows 7 Profesional SP1 64bit (localized CS),
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>Reporter: David Ježek
>Priority: Minor
>  Labels: easyfix
> Attachments: nullGuard.diff
>
>
> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S in file 
> org/apache/derby/loc/drda/messages_cs.properties
> Exception:
> Thu Jul 23 15:56:24 CEST 2015 : null
> java.lang.NullPointerException
> at 
> org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.drda.NetworkServerControl.installSecurityManager(Unknown 
> Source)
> at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
> Missing key is called in file org.apache.derby.drda.NetworkServerControl.java 
> at line 818.
> Reproduce under windows in console run:
> set DERBY_OPTS=-Duser.language=cs
> startNetworkServer.bat
> Workaround:
> Run derby server under en localization.
> Windows consola run:
> set DERBY_OPTS=-Duser.language=en
> startNetworkServer.bat



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

[jira] [Commented] (DERBY-6828) Network Server don't start in czech localized enviroment due missing key DRDA_MissingNetworkJar.S

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6828:
---

Looks like it's the message printed when the security manager is successfully 
installed. Here:

{code}
// Report success.
if (securityManager.equals(System.getSecurityManager())) {
String successMessage = server.localizeMessage(
"DRDA_SecurityInstalled.I", null);
{code}

Notice that the second argument to localizeMessage() is {{null}}. It is passed 
further down to LocalizedResource.getTextMessage():

{code}
public String getTextMessage(String key, Object... objectArr) {
if (res == null){
setResource();
}
try{
return MessageFormat.format(res.getString(key), 
objectArr);
} catch (Exception e) {
String tmpFormat = key;
for (int i=0; i";
return MessageFormat.format(tmpFormat, 
objectArr);
}
}
{code}

Here, an exception is raised because it cannot find the key in the Czech 
translation. However, the exception handler does not expect {{objectArr}} to be 
{{null}}, and a {{NullPointerException}} is raised.

> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S
> -
>
> Key: DERBY-6828
> URL: https://issues.apache.org/jira/browse/DERBY-6828
> Project: Derby
>  Issue Type: Bug
>  Components: Localization, Network Server
>Affects Versions: 10.11.1.1
> Environment: Windows 7 Profesional SP1 64bit (localized CS),
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>Reporter: David Ježek
>Priority: Minor
>  Labels: easyfix
>
> Network Server don't start in czech localized enviroment due missing key 
> DRDA_MissingNetworkJar.S in file 
> org/apache/derby/loc/drda/messages_cs.properties
> Exception:
> Thu Jul 23 15:56:24 CEST 2015 : null
> java.lang.NullPointerException
> at 
> org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(Unknown 
> Source)
> at 
> org.apache.derby.drda.NetworkServerControl.installSecurityManager(Unknown 
> Source)
> at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
> Missing key is called in file org.apache.derby.drda.NetworkServerControl.java 
> at line 818.
> Reproduce under windows in console run:
> set DERBY_OPTS=-Duser.language=cs
> startNetworkServer.bat
> Workaround:
> Run derby server under en localization.
> Windows consola run:
> set DERBY_OPTS=-Duser.language=en
> startNetworkServer.bat



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

[jira] [Closed] (DERBY-6869) XMLXXETest fails in non-English locales

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6869.
-
  Resolution: Fixed
   Fix Version/s: 10.13.0.0
Issue & fix info:   (was: Patch Available)

Thanks, Bryan. Committed the patch. And closing.

> XMLXXETest fails in non-English locales
> ---
>
> Key: DERBY-6869
> URL: https://issues.apache.org/jira/browse/DERBY-6869
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6869.diff
>
>
> I noticed that XMLXXETest failed on a machine with Swedish locale:
> {noformat}
> 1) 
> testDerby6807BillionLaughsVTI(org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest)junit.framework.AssertionFailedError
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest.testDerby6807BillionLaughsVTI(XMLXXETest.java:253)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> {noformat}
> derby.log shows that the following exception was raised:
> {noformat}
> ERROR 2200M: Invalid XML Document: JAXP00010001: Parsern har påträffat fler 
> än "64000" enhetstillägg i dokumentet - gränsvärdet för JDK har uppnåtts.
> {noformat}
> It is the expected exception, but the test searches for the substring "entity 
> expansions" in the error message. It doesn't find the substring since the 
> error message has been translated from English to Swedish.
> One way to fix it is to make the test case use assertStatementError() and 
> check the SQLState instead of the error message text.



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

[jira] [Closed] (DERBY-6868) Remove the dependency on Jakarta ORO

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6868.
-
  Resolution: Fixed
   Fix Version/s: 10.13.0.0
Issue & fix info:   (was: Patch Available)

> Remove the dependency on Jakarta ORO
> 
>
> Key: DERBY-6868
> URL: https://issues.apache.org/jira/browse/DERBY-6868
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools, Test
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6868.diff
>
>
> The Derby source code repository contains jakarta-oro-2.0.8.jar in the 
> tools/java directory. This jar file provides regex functionality used by the 
> Sed class in the old test harness.
> Modern JDK versions include the java.util.regex package, which provides 
> similar functionality. The Jakarta ORO project is retired and has been moved 
> to the Apache Attic.
> We should change the implementation of the Sed class to use java.util.regex 
> instead of Jakarta ORO because:
> - it reduces the number of binaries in the source code repository
> - java.util.regex is a maintained library, ORO is not



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

[jira] [Updated] (DERBY-6869) XMLXXETest fails in non-English locales

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6869:
--
Assignee: Knut Anders Hatlen
Issue & fix info: Patch Available

> XMLXXETest fails in non-English locales
> ---
>
> Key: DERBY-6869
> URL: https://issues.apache.org/jira/browse/DERBY-6869
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Attachments: d6869.diff
>
>
> I noticed that XMLXXETest failed on a machine with Swedish locale:
> {noformat}
> 1) 
> testDerby6807BillionLaughsVTI(org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest)junit.framework.AssertionFailedError
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest.testDerby6807BillionLaughsVTI(XMLXXETest.java:253)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> {noformat}
> derby.log shows that the following exception was raised:
> {noformat}
> ERROR 2200M: Invalid XML Document: JAXP00010001: Parsern har påträffat fler 
> än "64000" enhetstillägg i dokumentet - gränsvärdet för JDK har uppnåtts.
> {noformat}
> It is the expected exception, but the test searches for the substring "entity 
> expansions" in the error message. It doesn't find the substring since the 
> error message has been translated from English to Swedish.
> One way to fix it is to make the test case use assertStatementError() and 
> check the SQLState instead of the error message text.



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

[jira] [Updated] (DERBY-6869) XMLXXETest fails in non-English locales

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6869:
--
Attachment: d6869.diff

Using assertStatementError() doesn't work since the SQLExceptions raised by 
XmlVTI don't have SQLStates. Attaching d6869.diff which instead decorates the 
test with a LocaleTestSetup that forces it to run under US locale, so that the 
error message will always be in English. The patch also updates the failing 
assertion so that it reports the original exception if it doesn't get the 
expected exception. This makes it easier to see what went wrong when the test 
fails.

> XMLXXETest fails in non-English locales
> ---
>
> Key: DERBY-6869
> URL: https://issues.apache.org/jira/browse/DERBY-6869
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
>Reporter: Knut Anders Hatlen
> Attachments: d6869.diff
>
>
> I noticed that XMLXXETest failed on a machine with Swedish locale:
> {noformat}
> 1) 
> testDerby6807BillionLaughsVTI(org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest)junit.framework.AssertionFailedError
>   at 
> org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest.testDerby6807BillionLaughsVTI(XMLXXETest.java:253)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>   at junit.extensions.TestSetup.run(TestSetup.java:25)
> {noformat}
> derby.log shows that the following exception was raised:
> {noformat}
> ERROR 2200M: Invalid XML Document: JAXP00010001: Parsern har påträffat fler 
> än "64000" enhetstillägg i dokumentet - gränsvärdet för JDK har uppnåtts.
> {noformat}
> It is the expected exception, but the test searches for the substring "entity 
> expansions" in the error message. It doesn't find the substring since the 
> error message has been translated from English to Swedish.
> One way to fix it is to make the test case use assertStatementError() and 
> check the SQLState instead of the error message text.



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

[jira] [Created] (DERBY-6869) XMLXXETest fails in non-English locales

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6869:
-

 Summary: XMLXXETest fails in non-English locales
 Key: DERBY-6869
 URL: https://issues.apache.org/jira/browse/DERBY-6869
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.13.0.0
Reporter: Knut Anders Hatlen


I noticed that XMLXXETest failed on a machine with Swedish locale:

{noformat}
1) 
testDerby6807BillionLaughsVTI(org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest)junit.framework.AssertionFailedError
at 
org.apache.derbyTesting.functionTests.tests.lang.XMLXXETest.testDerby6807BillionLaughsVTI(XMLXXETest.java:253)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
{noformat}

derby.log shows that the following exception was raised:

{noformat}
ERROR 2200M: Invalid XML Document: JAXP00010001: Parsern har påträffat fler än 
"64000" enhetstillägg i dokumentet - gränsvärdet för JDK har uppnåtts.
{noformat}

It is the expected exception, but the test searches for the substring "entity 
expansions" in the error message. It doesn't find the substring since the error 
message has been translated from English to Swedish.

One way to fix it is to make the test case use assertStatementError() and check 
the SQLState instead of the error message text.



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

[jira] [Commented] (DERBY-1418) derbyall/storeall/storemore/OnlineBackupTest3 failed, unable to reproduce

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-1418:
---

Happened again in the nightly testing:

{noformat}
Begin Online Backup Test3
Initial Setup Complete
Begin Install Jar Test
ERROR XSRSA: Cannot backup the database when unlogged operations are 
uncommitted. Please commit the transactions with backup blocking operations. 
Backup-1 Started
The transaction that was blocking the backup has ended
Backup-1 Completed
Backup-2 Started
Started obtest_customer.jar addition in seperate thread
The transaction that was blocking the backup has ended
ERROR XSRS4: Error renaming file (during backup) from 
extinout\onlinebackuptest3\wombat to extinout\onlinebackuptest3\wombat.OLD.
java.sql.SQLException: Error renaming file (during backup) from 
extinout\onlinebackuptest3\wombat to extinout\onlinebackuptest3\wombat.OLD.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:230)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at 
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
at 
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1433)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.Exception
 in thread "main" java.lang.Exception: BACKUP FAILED:Error renaming file 
(during backup) from extinout\onlinebackuptest3\wombat to 
extinout\onlinebackuptest3\wombat.OLD.
at 
org.apache.derbyTesting.functionTests.tests.store.OnlineBackup.waitForBackupToEnd(OnlineBackup.java:137)
at 
org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest3.installJarTest(OnlineBackupTest3.java:256)
at 
org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest3.runTest(OnlineBackupTest3.java:90)
at 
org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest3.main(OnlineBackupTest3.java:49)
java:1709)
at 
org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:134)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1394)
at 
org.apache.derbyTesting.functionTests.tests.store.OnlineBackup.performBackup(OnlineBackup.java:89)
at 
org.apache.derbyTesting.functionTests.tests.store.OnlineBackup.run(OnlineBackup.java:60)
at java.lang.Thread.run(Thread.java:804)
Caused by: ERROR XSRS4: Error renaming file (during backup) from 
extinout\onlinebackuptest3\wombat to extinout\onlinebackuptest3\wombat.OLD.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:285)
at org.apache.derby.impl.store.raw.RawStore.backup(RawStore.java:790)
at org.apache.derby.impl.store.raw.RawStore.backup(RawStore.java:686)
at 
org.apache.derby.impl.store.access.RAMAccessManager.backup(RAMAccessManager.java:968)
at org.apache.derby.impl.db.BasicDatabase.backup(BasicDatabase.java:439)
at 
org.apache.derby.catalog.SystemProcedures.SYSCS_BACKUP_DATABASE(SystemProcedures.java:1002)
at 
org.apache.derby.exe.acf67740d7x0152xc519x5fd8x9d2c97140.g0(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
at 
org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:75)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:473)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:352)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1341)
... 6 more
{noformat}

{noformat}
-- Java Information --
Java Version:9-ea
Java Vendor: Oracle Corporation
Java home:   c:\tendril4\work\install\sun-jdk-9-ea-promoted-latest\jdk\jdk-9
Java classpath:  
c:\tendril4\work\run\28680469\jars\sane\derbyTesting.j

[jira] [Updated] (DERBY-6868) Remove the dependency on Jakarta ORO

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6868:
--
Attachment: d6868.diff

Attaching the patch d6868.diff which makes the Sed class use java.util.regex 
instead of Jakarta ORO for regular expressions. It also removes all references 
to Jakarta ORO from the source. Need to {{svn rm 
tools/java/jakarta-oro-2.0.8.jar}} in addition to applying the patch.

One substitution pattern had to be changed because the java.util.regex dialect 
is slightly different from ORO's dialect. Specifically, java.util.regex treats 
'\{' and '\}' as special characters, and they need to be escaped with a 
backslashes.

derbyall and suites.All ran cleanly. (Jakarta ORO was only used by derbyall.)

> Remove the dependency on Jakarta ORO
> 
>
> Key: DERBY-6868
> URL: https://issues.apache.org/jira/browse/DERBY-6868
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools, Test
>    Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Attachments: d6868.diff
>
>
> The Derby source code repository contains jakarta-oro-2.0.8.jar in the 
> tools/java directory. This jar file provides regex functionality used by the 
> Sed class in the old test harness.
> Modern JDK versions include the java.util.regex package, which provides 
> similar functionality. The Jakarta ORO project is retired and has been moved 
> to the Apache Attic.
> We should change the implementation of the Sed class to use java.util.regex 
> instead of Jakarta ORO because:
> - it reduces the number of binaries in the source code repository
> - java.util.regex is a maintained library, ORO is not



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

[jira] [Updated] (DERBY-6868) Remove the dependency on Jakarta ORO

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6868:
--
Issue & fix info: Patch Available

> Remove the dependency on Jakarta ORO
> 
>
> Key: DERBY-6868
> URL: https://issues.apache.org/jira/browse/DERBY-6868
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools, Test
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Attachments: d6868.diff
>
>
> The Derby source code repository contains jakarta-oro-2.0.8.jar in the 
> tools/java directory. This jar file provides regex functionality used by the 
> Sed class in the old test harness.
> Modern JDK versions include the java.util.regex package, which provides 
> similar functionality. The Jakarta ORO project is retired and has been moved 
> to the Apache Attic.
> We should change the implementation of the Sed class to use java.util.regex 
> instead of Jakarta ORO because:
> - it reduces the number of binaries in the source code repository
> - java.util.regex is a maintained library, ORO is not



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

[jira] [Commented] (DERBY-6867) Include index.html page at db.apache.org/derby/releases/index.html

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6867:
---

The redirection works for me too. Thanks, Bryan.

> Include index.html page at db.apache.org/derby/releases/index.html
> --
>
> Key: DERBY-6867
> URL: https://issues.apache.org/jira/browse/DERBY-6867
> Project: Derby
>  Issue Type: Improvement
>  Components: Web Site
>Reporter: Bryan Pendleton
>Assignee: Bryan Pendleton
>Priority: Minor
> Attachments: index-page.diff
>
>
> The folder at http://db.apache.org/derby/releases is not intended
> to be navigated directly; the releases available for download are
> managed via http://db.apache.org/derby/derby_downloads.html
> We should include an index.html page at the raw releases directory
> so that if a user accidentally visits that page they don't get an
> auto-generated listing page from the underlying web server.
> See: 
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/201602.mbox/%3C56B028F5.5040701%40gmail.com%3E
> for additional discussion



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

[jira] [Created] (DERBY-6868) Remove the dependency on Jakarta ORO

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6868:
-

 Summary: Remove the dependency on Jakarta ORO
 Key: DERBY-6868
 URL: https://issues.apache.org/jira/browse/DERBY-6868
 Project: Derby
  Issue Type: Improvement
  Components: Build tools, Test
Affects Versions: 10.13.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen


The Derby source code repository contains jakarta-oro-2.0.8.jar in the 
tools/java directory. This jar file provides regex functionality used by the 
Sed class in the old test harness.

Modern JDK versions include the java.util.regex package, which provides similar 
functionality. The Jakarta ORO project is retired and has been moved to the 
Apache Attic.

We should change the implementation of the Sed class to use java.util.regex 
instead of Jakarta ORO because:
- it reduces the number of binaries in the source code repository
- java.util.regex is a maintained library, ORO is not



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

[jira] [Commented] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6865:
---

It looks like the JarDriftTest class only looks for classes that drift into the 
jar files, not classes that drift out of it.

> RestrictiveFilePermissionsTest fails on Windows
> ---
>
> Key: DERBY-6865
> URL: https://issues.apache.org/jira/browse/DERBY-6865
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728459
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>
> {noformat}
> .F.F.F.F.F.F.F.F.F.F.F.F.F..
> Time: 48,93
> There were 13 failures:
> 1) 
> testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
>  unexpected uid \OPPRETTER EIER can access file 
> C:\cygwin64\tmp\derbytst\system\RFPT_backup
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
> {noformat}



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

[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6856:
---

Hopefully, Ant's javac task gets support for the new -release option before or 
around the time JDK 9 gets out. If not, I suppose we can always add 
{{}} to the javac targets 
in our build scripts. (The "javac1.9" compiler alias is only recognized by Ant 
1.9.5 or newer.) I agree that reviving PropertySetter is not a good idea now 
that the JDK is about to add a new and better mechanism for cross-compilation.

> Make it possible to build Derby using JDK 9
> ---
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff, 
> derby-6856-01-ac-cleanup.diff
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like 
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see 
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool 
> which we use so that old JVMs can compile Derby and so that Derby can be 
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the 
> development cycle of Java 9.



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

[jira] [Updated] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6857:
--
Attachment: jvminfo-constants.diff

Attaching jvminfo-constants.diff which removes the constants for Java 6 and 7 
from the JVMInfo class, since those Java versions are no longer supported.

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> jvminfo-constants.diff, mac-derby-jar-verbose.txt, mac-sane-TypeId.class, 
> new-byte-codes.diff, windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

[jira] [Commented] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6857:
---

The new constants added to the VMDescriptor interface are described in more 
detail here: 
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> mac-derby-jar-verbose.txt, mac-sane-TypeId.class, new-byte-codes.diff, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

[jira] [Updated] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6857:
--
Attachment: new-byte-codes.diff

I noticed that the build failed (classlister raised a ClassFormatError) if I 
added a lambda expression to the code. It happens because some new byte codes 
have been added to the Java class format in the latest releases. 
ClassInvestigator doesn't understand those byte codes and raises an error which 
makes classlister fail.

The attached patch teaches ClassInvestigator how to handle the new byte codes, 
and it transforms an inner class into a lambda expression to verify that it 
works.

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> mac-derby-jar-verbose.txt, mac-sane-TypeId.class, new-byte-codes.diff, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

[jira] [Commented] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6865:
---

The problem seems to be that the FilePermissionServiceImpl class is not 
included in derby.jar anymore. It is only included if the vmLevelIsAtLeast1.7 
property is true, but that property is not set anymore.

> RestrictiveFilePermissionsTest fails on Windows
> ---
>
> Key: DERBY-6865
> URL: https://issues.apache.org/jira/browse/DERBY-6865
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728459
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>
> {noformat}
> .F.F.F.F.F.F.F.F.F.F.F.F.F..
> Time: 48,93
> There were 13 failures:
> 1) 
> testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
>  unexpected uid \OPPRETTER EIER can access file 
> C:\cygwin64\tmp\derbytst\system\RFPT_backup
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
> {noformat}



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

[jira] [Assigned] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen reassigned DERBY-6865:
-

Assignee: Knut Anders Hatlen

> RestrictiveFilePermissionsTest fails on Windows
> ---
>
> Key: DERBY-6865
> URL: https://issues.apache.org/jira/browse/DERBY-6865
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728459
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>
> {noformat}
> .F.F.F.F.F.F.F.F.F.F.F.F.F..
> Time: 48,93
> There were 13 failures:
> 1) 
> testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
>  unexpected uid \OPPRETTER EIER can access file 
> C:\cygwin64\tmp\derbytst\system\RFPT_backup
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
> {noformat}



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

[jira] [Commented] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6865:
---

git bisect says:

579dc9f4698f42e153325223d93f2c81ef3dbd72 is the first bad commit
commit 579dc9f4698f42e153325223d93f2c81ef3dbd72
Author: Richard N. Hillegas 
Date:   Sun Jan 24 14:43:28 2016 +

DERBY-6857: Remove support for java 6 and 7; compile Derby completely into 
java 8 byte code; commit derby-6857-01-aa-remove6and7.diff.

git-svn-id: https://svn.apache.org/repos/asf/db/derby/code/trunk@1726495 
13f79535-47bb-0310-9956-ffa450edef68

:100644 100644 f13561041f7e02e7ff36e4336c9febab623a9f97 
ba6e9d8f2f3f26bfa6fe2c1d7072861adc2a963f M  BUILDING.html
:100644 100644 e32ceb937321ab55b2cd2aae60f960aebe3ca0b1 
2e429aa2888ae72ed89fd0f98263d5def7c07aaa M  build.xml
:04 04 d13f6159759e4bbf550d8067a5aaf044aa4dcd7d 
967a3bdd7cc59ba36f29c695a3e7d12c764d958a M  java

> RestrictiveFilePermissionsTest fails on Windows
> ---
>
> Key: DERBY-6865
> URL: https://issues.apache.org/jira/browse/DERBY-6865
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728459
>Reporter: Knut Anders Hatlen
>
> {noformat}
> .F.F.F.F.F.F.F.F.F.F.F.F.F..
> Time: 48,93
> There were 13 failures:
> 1) 
> testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
>  unexpected uid \OPPRETTER EIER can access file 
> C:\cygwin64\tmp\derbytst\system\RFPT_backup
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
>   at 
> org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
>   at 
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>   at junit.extensions.TestSetup.run(TestSetup.java:27)
> {noformat}



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

[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6856:
---

We used to cross-compile the way Dalibor suggested, by setting up a compile 
classpath that pointed to the old version of the standard libraries, using 
properties such as j18lib and java18compile.classpath. This mechanism seems to 
have been removed from trunk, though.

We could work around these issues by adding up-casts to force the compiler to 
create byte code for calling the methods in the Buffer class instead of the new 
overrides in the ByteBuffer class. That is, we could change {{buffer.clear();}} 
to {{((Buffer) buffer).clear();}}. And similar for position(), limit(), 
mark()... It gets a bit messy after a while. I remember we have added similar 
casts earlier to get cross-compilation to work without a correct compile 
classpath, but those changes were more limited. I don't remember the specifics 
of those problems anymore...

> Make it possible to build Derby using JDK 9
> ---
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff, 
> derby-6856-01-ac-cleanup.diff
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like 
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see 
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool 
> which we use so that old JVMs can compile Derby and so that Derby can be 
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the 
> development cycle of Java 9.



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

[jira] [Closed] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6864.
-
Resolution: Fixed

The test seems to pass now. Closing.

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6864-2.diff, d6864.diff
>
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
> canRead=true, canWrite=true, size=0)
> at 
> org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
> at 
> org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> FAILURES!!!
> Tests run: 1,  Failures: 1,  Errors: 0
> {noformat}



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

[jira] [Created] (DERBY-6865) RestrictiveFilePermissionsTest fails on Windows

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6865:
-

 Summary: RestrictiveFilePermissionsTest fails on Windows
 Key: DERBY-6865
 URL: https://issues.apache.org/jira/browse/DERBY-6865
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.13.0.0
 Environment: Windows 10
JDK 8u71
Derby trunk revision 1728459
Reporter: Knut Anders Hatlen


{noformat}
.F.F.F.F.F.F.F.F.F.F.F.F.F..
Time: 48,93
There were 13 failures:
1) 
testBackupRestoreFiles(org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest)junit.framework.AssertionFailedError:
 unexpected uid \OPPRETTER EIER can access file 
C:\cygwin64\tmp\derbytst\system\RFPT_backup
at 
org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:758)
at 
org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest$2.run(RestrictiveFilePermissionsTest.java:597)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:597)
at 
org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.checkAccessToOwner(RestrictiveFilePermissionsTest.java:582)
at 
org.apache.derbyTesting.functionTests.tests.engine.RestrictiveFilePermissionsTest.testBackupRestoreFiles(RestrictiveFilePermissionsTest.java:372)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
{noformat}



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

[jira] [Updated] (DERBY-6863) NPE when multiple values are contained in an IN statement within a CASE statement used in a GROUP BY

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6863:
--
Bug behavior facts: Crash,Seen in production,Wrong query result  (was: 
Crash,Deviation from standard,Seen in production,Wrong query result)

Removed the "Deviation from standard" flag. The standard only allows column 
references in the GROUP BY clause, so the failing query is non-standard. 
Allowing expressions is an extension added in DERBY-883. With many fallouts 
similar to this bug, unfortunately...

> NPE when multiple values are contained in an IN statement within a CASE 
> statement used in a GROUP BY
> 
>
> Key: DERBY-6863
> URL: https://issues.apache.org/jira/browse/DERBY-6863
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.12.1.1
> Environment: Java 8, Mint Linux, 24G, Used within an in-memory table
>Reporter: Peter Damen
> Attachments: ac_86.decomp, derby.log
>
>
> An IN statement within a CASE statement within a GROUP BY, that contains more 
> than one element will cause a NPE.
> Reproduction Steps:
>  DATA 
> CREATE TABLE Test (
>Region VARCHAR(20),
>Cost INTEGER
> );
> INSERT INTO Test VALUES ('Australia', 45);
> INSERT INTO Test VALUES ('Asia', 22);
> INSERT INTO Test VALUES ('North America', 33);
> INSERT INTO Test VALUES ('South America', 55);
> INSERT INTO Test VALUES ('Europe', 44);
> === SQL WORKS ===
> SELECT DISTINCT
>CASE
>   WHEN 1 = 0 THEN "REGION"
>   WHEN "REGION" IN ('Asia') THEN 'A'
>   ELSE "REGION"
>END,
>SUM("COST")
> FROM TEST
> GROUP BY 
>CASE
>   WHEN 1 = 0 THEN "REGION"
>   WHEN "REGION" IN ('Asia') THEN 'A'
>   ELSE "REGION"
>END
>  FAILS ===
>SELECT DISTINCT
>   CASE
>  WHEN 1 = 0 THEN "REGION"
>  WHEN "REGION" IN ('Asia', 'Australia') THEN 'A'
>  ELSE "REGION"
>   END,
>   SUM("COST")
>FROM TEST
>GROUP BY 
>   CASE
>  WHEN 1 = 0 THEN "REGION"
>  WHEN "REGION" IN ('Asia','Australia') THEN 'A'
>  ELSE "REGION"
>   END
> == NPE ===
> java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
>   at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
>   at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
>   at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
>   at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
>   at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
>   at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
>   at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:622)
>   at com.onseven.dbvis.b.B.B.ā(Z:2256)
>   at com.onseven.dbvis.b.B.F$A.call(Z:2838)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:701)
> Caused by: ERROR XJ001: Java exception

[jira] [Updated] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6864:
--
Attachment: d6864-2.diff

Attaching d6864-2.diff which makes DataFileVTI close the stream it uses for 
reading from service.properties. Hopefully this is sufficient to get the test 
to pass again.

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6864-2.diff, d6864.diff
>
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
> canRead=true, canWrite=true, size=0)
> at 
> org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
> at 
> org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> FAILURES!!!
> Tests run: 1,  Failures: 1,  Errors: 0
> {noformat}



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

[jira] [Commented] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6864:
---

After making the tearDown() method use assertDirectoryDeleted(), the test fails 
with the following error message:

{noformat}
junit.framework.AssertionFailedError: Failed to delete 2 files 
(root=d:\tendril4\work\run\28679745\junit\system\dbsqlauth): 
d:\tendril4\work\run\28679745\junit\system\dbsqlauth\service.properties 
(isDir=false, canRead=true, canWrite=true, size=1218), 
d:\tendril4\work\run\28679745\junit\system\dbsqlauth (isDir=true, canRead=true, 
canWrite=true, size=4096)
at 
org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
at 
org.apache.derbyTesting.functionTests.tests.lang.RawDBReaderTest.tearDown(RawDBReaderTest.java:156)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
...
{noformat}

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6864.diff
>
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
> canRead=true, canWrite=true, size=0)
> at 
> org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
> at 
> org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> FAILURES!!!
> Tests run: 1,  Failures: 1,  Errors: 0
> {noformat}



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

[jira] [Closed] (DERBY-6860) Automatic download of junit.jar broken

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6860.
-
   Resolution: Fixed
Fix Version/s: 10.13.0.0

> Automatic download of junit.jar broken
> --
>
> Key: DERBY-6860
> URL: https://issues.apache.org/jira/browse/DERBY-6860
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
>
> Automatic download of junit.jar seems to be broken. If you don't already have 
> a copy in tools/java, "ant all" fails like this:
> {noformat}
> junit_check:
> BUILD FAILED
> /code/derby/trunk/build.xml:66: The following error occurred while executing 
> this line:
> /code/derby/trunk/build.xml:177: junit property is set to 
> /code/derby/trunk/tools/java/junit.jar, but there is no junit.jar there.
> {noformat}
> The problem seems to be that junit_check refuses to continue if the junit 
> property is set, but does not point to an existing file. This property is set 
> when the setCompilerProperties target, which runs before junit_check, loads 
> tools/ant/properties/extrapath.properties, as extrapath.properties contains 
> the following line:
> {noformat}
> junit=${javatools.dir}/junit.jar
> {noformat}
> Since the install_junit target depends on the check_junit target, this 
> prevents the build script from downloading junit.jar automatically.
> Workaround: run "ant install_junit" before "ant all"



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

[jira] [Assigned] (DERBY-6860) Automatic download of junit.jar broken

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen reassigned DERBY-6860:
-

Assignee: Knut Anders Hatlen

> Automatic download of junit.jar broken
> --
>
> Key: DERBY-6860
> URL: https://issues.apache.org/jira/browse/DERBY-6860
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>        Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
>
> Automatic download of junit.jar seems to be broken. If you don't already have 
> a copy in tools/java, "ant all" fails like this:
> {noformat}
> junit_check:
> BUILD FAILED
> /code/derby/trunk/build.xml:66: The following error occurred while executing 
> this line:
> /code/derby/trunk/build.xml:177: junit property is set to 
> /code/derby/trunk/tools/java/junit.jar, but there is no junit.jar there.
> {noformat}
> The problem seems to be that junit_check refuses to continue if the junit 
> property is set, but does not point to an existing file. This property is set 
> when the setCompilerProperties target, which runs before junit_check, loads 
> tools/ant/properties/extrapath.properties, as extrapath.properties contains 
> the following line:
> {noformat}
> junit=${javatools.dir}/junit.jar
> {noformat}
> Since the install_junit target depends on the check_junit target, this 
> prevents the build script from downloading junit.jar automatically.
> Workaround: run "ant install_junit" before "ant all"



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

[jira] [Commented] (DERBY-6860) Automatic download of junit.jar broken

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6860:
---

git bisect says:

5d1f9f03c2741809d15ef482ac2a7989607970dc is the first bad commit
commit 5d1f9f03c2741809d15ef482ac2a7989607970dc
Author: Richard N. Hillegas 
Date:   Tue Jan 26 02:42:00 2016 +

DERBY-6857: Replace hardcoded references to 1.8 in the build scripts with a 
min.version constant; commit derby-6857-03-aa-minimumVersion.diff.

git-svn-id: https://svn.apache.org/repos/asf/db/derby/code/trunk@1726721 
13f79535-47bb-0310-9956-ffa450edef68

> Automatic download of junit.jar broken
> --
>
> Key: DERBY-6860
> URL: https://issues.apache.org/jira/browse/DERBY-6860
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>    Reporter: Knut Anders Hatlen
>
> Automatic download of junit.jar seems to be broken. If you don't already have 
> a copy in tools/java, "ant all" fails like this:
> {noformat}
> junit_check:
> BUILD FAILED
> /code/derby/trunk/build.xml:66: The following error occurred while executing 
> this line:
> /code/derby/trunk/build.xml:177: junit property is set to 
> /code/derby/trunk/tools/java/junit.jar, but there is no junit.jar there.
> {noformat}
> The problem seems to be that junit_check refuses to continue if the junit 
> property is set, but does not point to an existing file. This property is set 
> when the setCompilerProperties target, which runs before junit_check, loads 
> tools/ant/properties/extrapath.properties, as extrapath.properties contains 
> the following line:
> {noformat}
> junit=${javatools.dir}/junit.jar
> {noformat}
> Since the install_junit target depends on the check_junit target, this 
> prevents the build script from downloading junit.jar automatically.
> Workaround: run "ant install_junit" before "ant all"



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

[jira] [Reopened] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen reopened DERBY-6864:
---

Hmm... This fixed the issue in my environment, but it still fails in continuous 
integration tests on Windows:

{noformat}
junit.framework.AssertionFailedError
at 
org.apache.derbyTesting.functionTests.tests.lang.RawDBReaderTest.tearDown(RawDBReaderTest.java:156)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
{noformat}

It's still a problem with deleting files, but there's no information about 
which files, because the tearDown() method of the test is simply asserting on 
the return value of File.delete().

I'll change it so that it uses BaseTestCase.assertDirectoryDeleted() instead. 
It provides some extra debug information when it fails.

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6864.diff
>
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> ca

[jira] [Closed] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6864.
-
   Resolution: Fixed
Fix Version/s: 10.13.0.0

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Fix For: 10.13.0.0
>
> Attachments: d6864.diff
>
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
> canRead=true, canWrite=true, size=0)
> at 
> org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
> at 
> org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> FAILURES!!!
> Tests run: 1,  Failures: 1,  Errors: 0
> {noformat}



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

[jira] [Updated] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-6864:
--
Attachment: d6864.diff

The problem is that RawDBReaderTest.runRecoveryScript() opens a FileReader that 
reads the recovery.sql script, but it doesn't close it. Windows doesn't allow 
deletion of open files, so tearDown() fails when trying to clean up the test 
directory.

Attaching a patch which fixes the problem by opening the FileReader in a 
try-with-resources statement, which automatically closes the reader when it 
goes out of scope. The patch also removes the use of LineNumberReader in the 
method and instead makes it use a plain BufferedReader, since it didn't use any 
of the extra functionality provided by LineNumberReader.

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
> Attachments: d6864.diff
>
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
> canRead=true, canWrite=true, size=0)
> at 
> org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
> at 
> org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> FAILURES!!!
> Tests run: 1,  Failures: 1,  Errors: 0
> {noformat}



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

[jira] [Assigned] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen reassigned DERBY-6864:
-

Assignee: Knut Anders Hatlen

> RawDBReaderTest fails on Windows
> 
>
> Key: DERBY-6864
> URL: https://issues.apache.org/jira/browse/DERBY-6864
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.13.0.0
> Environment: Windows 10
> JDK 8u71
> Derby trunk revision 1728254
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>
> RawDBReaderTest fails on Windows with the following output:
> {noformat}
> . attempt 1 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 2 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 3 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
>  attempt 4 left 2 files/dirs behind: 
> 0=extinout\recovery.sql 1=extinout
> F
> Time: 39,498
> There was 1 failure:
> 1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
> delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
> C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
> canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
> canRead=true, canWrite=true, size=0)
> at 
> org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
> at 
> org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
> at 
> org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> FAILURES!!!
> Tests run: 1,  Failures: 1,  Errors: 0
> {noformat}



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

[jira] [Created] (DERBY-6864) RawDBReaderTest fails on Windows

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6864:
-

 Summary: RawDBReaderTest fails on Windows
 Key: DERBY-6864
 URL: https://issues.apache.org/jira/browse/DERBY-6864
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.13.0.0
 Environment: Windows 10
JDK 8u71
Derby trunk revision 1728254
Reporter: Knut Anders Hatlen


RawDBReaderTest fails on Windows with the following output:

{noformat}
. attempt 1 left 2 files/dirs behind: 
0=extinout\recovery.sql 1=extinout
 attempt 2 left 2 files/dirs behind: 
0=extinout\recovery.sql 1=extinout
 attempt 3 left 2 files/dirs behind: 
0=extinout\recovery.sql 1=extinout
 attempt 4 left 2 files/dirs behind: 
0=extinout\recovery.sql 1=extinout
F
Time: 39,498
There was 1 failure:
1) RawDBReaderTest:embeddedjunit.framework.AssertionFailedError: Failed to 
delete 2 files (root=C:\cygwin64\tmp\derbytst\extinout): 
C:\cygwin64\tmp\derbytst\extinout\recovery.sql (isDir=false, canRead=true, 
canWrite=true, size=801), C:\cygwin64\tmp\derbytst\extinout (isDir=true, 
canRead=true, canWrite=true, size=0)
at 
org.apache.derbyTesting.junit.BaseTestCase.assertDirectoryDeleted(BaseTestCase.java:1125)
at 
org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:128)
at 
org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:118)
at 
org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:130)
at junit.extensions.TestSetup$1.protect(TestSetup.java:24)
at junit.extensions.TestSetup.run(TestSetup.java:27)

FAILURES!!!
Tests run: 1,  Failures: 1,  Errors: 0
{noformat}



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

[jira] [Commented] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6857:
---

For the record, the build failure is not limited to Windows. I'm seeing it 
consistently on Debian with JDK >= 8u60. And the failing Jenkins jobs run on 
Ubuntu.

It looks like it's an intentional change: 
[JDK-8073372|https://bugs.openjdk.java.net/browse/JDK-8073372] - Redundant 
CONSTANT_Class entry not generated for inlined constant.

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> mac-derby-jar-verbose.txt, mac-sane-TypeId.class, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

Re: Build failed in Jenkins: Derby-trunk #2428

[Knut Anders Hatlen]

Apache Jenkins Server   writes:

> [trunk] $ /home/jenkins/tools/ant/latest/bin/ant clobber all buildjars
> Buildfile: 
>
> clean:
>
> cleangenerated:
>
> cleanstate:
>
> cleanreleasefiles:
>
> clobber:
>
> checkCompilerLevel:
>
> checkVMLevel:
>
> prebuild:
> [mkdir] Created dir: 
> 
>
> compile:
> [javac] Compiling 2 source files to 
> 
>
> build:
>
> setCompilerProperties:
>
> init:
>
> junit_check:
>
> BUILD FAILED
> :66: The 
> following error occurred while executing this line:
> :177: junit 
> property is set to 
>  
> but there is no junit.jar there.

Looks like automatic download of junit.jar is broken. I've filed
https://issues.apache.org/jira/browse/DERBY-6860 to track it.

For now, I've reconfigured the build job to run the install_junit target
manually to download junit.jar.

-- 
Knut Anders

[jira] [Created] (DERBY-6860) Automatic download of junit.jar broken

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6860:
-

 Summary: Automatic download of junit.jar broken
 Key: DERBY-6860
 URL: https://issues.apache.org/jira/browse/DERBY-6860
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Affects Versions: 10.13.0.0
Reporter: Knut Anders Hatlen


Automatic download of junit.jar seems to be broken. If you don't already have a 
copy in tools/java, "ant all" fails like this:

{noformat}
junit_check:

BUILD FAILED
/code/derby/trunk/build.xml:66: The following error occurred while executing 
this line:
/code/derby/trunk/build.xml:177: junit property is set to 
/code/derby/trunk/tools/java/junit.jar, but there is no junit.jar there.
{noformat}

The problem seems to be that junit_check refuses to continue if the junit 
property is set, but does not point to an existing file. This property is set 
when the setCompilerProperties target, which runs before junit_check, loads 
tools/ant/properties/extrapath.properties, as extrapath.properties contains the 
following line:

{noformat}
junit=${javatools.dir}/junit.jar
{noformat}

Since the install_junit target depends on the check_junit target, this prevents 
the build script from downloading junit.jar automatically.

Workaround: run "ant install_junit" before "ant all"



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

Re: Build failed in Jenkins: Derby-trunk #2427

[Knut Anders Hatlen]

I've updated the Derby-trunk job in Jenkins to use JDK 8 after support
for 6 and 7 was removed in
https://issues.apache.org/jira/browse/DERBY-6857.

Now it seems to build, but the jardriftcheck target fails:

Apache Jenkins Server   writes:

> jardriftcheck:
>  [java] ERROR: class org.apache.derby.iapi.reference.DRDAConstants.class 
> in
>  [java]derby.jar was not previously there.
>  [java] 
>  [java] ERROR: class org.apache.derbyPreBuild.ReleaseProperties.class in
>  [java]derby.jar was not previously there.
>  [java] 
>  [java] ERROR: class 
> org.apache.derby.shared.common.sanity.SanityState.class in
>  [java]derby.jar was not previously there.
>  [java] 
>  [java] ERROR: class org.apache.derbyPreBuild.ReleaseProperties.class in
>  [java]derbyclient.jar was not previously there.
>  [java] 
>  [java] ERROR: class 
> org.apache.derby.shared.common.sanity.SanityState.class in
>  [java]derbyclient.jar was not previously there.
>  [java] 
>  [java] ERROR: class 
> org.apache.derby.shared.common.sanity.SanityState.class in
>  [java]derbynet.jar was not previously there.
>  [java] 
>  [java] ERROR: class org.apache.derbyPreBuild.ReleaseProperties.class in
>  [java]derbytools.jar was not previously there.
>  [java] 
>  [java] Exception in thread "main" java.lang.Exception: 
>  [java] jar drift check failed; see DERBY-6471 for info. 
>  [java] See error in build output or call ant jardriftcheck. 
>  [java] If the new class is expected run ant refreshjardriftcheck.
>  [java] NB: Run the refresh for both sane and insane builds. 
>  [java] Use the highest supported JVM (currently Java 8) 
>  [java]  to ensure all classes are built.
>  [java] 
>  [java]   at 
> org.apache.derbyBuild.JarDriftTest.main(JarDriftTest.java:103)
>
> BUILD FAILED
> :622: Java 
> returned: 1
>
> Total time: 1 minute 11 seconds
> Build step 'Invoke Ant' marked build as failure
> [WARNINGS] Skipping publisher since build result is FAILURE
> Archiving artifacts
> Compressed 143.31 MB of artifacts by 100.0% relative to #2423

Re: [VOTE] Sunsetting support for Java 7

[Knut Anders Hatlen]

Richard Hillegas  writes:

> Please vote on the following proposed policy for supported
> platforms.

+1

[jira] [Commented] (DERBY-6733) Implement an MBean for monitoring caches

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6733:
---

Making the beans self-describing sounds like a great idea. I did a quick search 
on the internet and found this article, which describes a way to do it: 
https://weblogs.java.net/blog/emcmanus/archive/2005/07/adding_informat.html. It 
looks a bit more complex than I thought it would be, though.

> Implement an MBean for monitoring caches
> 
>
> Key: DERBY-6733
> URL: https://issues.apache.org/jira/browse/DERBY-6733
> Project: Derby
>  Issue Type: Improvement
>  Components: JMX
>Affects Versions: 10.12.0.0
>    Reporter: Knut Anders Hatlen
>    Assignee: Knut Anders Hatlen
> Fix For: 10.12.0.0
>
> Attachments: d6733-1a-page-and-container.diff, 
> d6733-2a-statement-cache.diff, d6733-3a-adminguide.diff, 
> d6733-4a-test-permissions.diff, radminjmxintro.html
>
>
> Add an MBean that allows users to monitor Derby's CacheFactory instances, as 
> discussed in DERBY-5772.



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

Re: Internal Derby Javadoc links on the website are broken

[Knut Anders Hatlen]

Bryan Pendleton  writes:

> On 5/19/2015 7:50 PM, Myrna van Lunteren wrote:
>> I could see the output by going to the derby builds overview 
>> (https://builds.apache.org/view/A-D/view/Derby/)
>
> Thanks Myrna, that works for me, too.
>
> Perhaps the simplest thing to do is to change the links on
>
>   http://db.apache.org/derby/manuals/index.html#javadoc
>
> to point to, e.g.,
>
>   
> https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk/lastSuccessfulBuild/artifact/trunk/javadoc/
>
> If that seems like a reasonable approach, I can do that.

The old, shorter links seem to work again now. Probably it was Myrna's
rebuild that brought back the artifacts.

The docs builds had the same problem. The last build didn't have any
artifacts. Probably the infrastructure team automatically deletes old
build artifacts after a while, and the Derby-docs build hadn't run since
January, so the artifacts were quite old.

I've reconfigured the Derby-docs and Derby-trunk build jobs to run once
every month, even if there hasn't been a commit lately. That should
hopefully be frequently enough to avoid the automatic cleanup. The build
jobs will still check the Subversion repository daily and run more
frequently if the code base is updated.

-- 
Knut Anders

Re: Fwd: Duplicate key feature request

[Knut Anders Hatlen]

Rick Hillegas  writes:

> On 12/5/14 6:38 AM, Camilla Haase wrote:
>> I think these subclasses are not specific to Derby but are found in
>> the Java SE API package java.sql.
>>
>> Kim
>>
>> On 12/4/2014 5:55 PM, Myrna van Lunteren wrote:
>>> Moving this discussion to derby-dev...
>>>
>>> Forgive my ignorance in this area...
>>>
>>> I had a look at the Derby source code and we do not currently seem to
>>> have any subclasses of SQLException, except SQLExceptionWrapper.
>>>
>>> (There are some client exceptions that extend SqlException, but that one
>>> extends Exception, not SQLException).
>>>
>>> I wonder why this was not done before - presumably there was no need
>>> before? Are there negatives connected to extending
>>> java.sql.SQLException? Does anyone have insights on this?
> The JDBC spec requires drivers to return the refined subclasses of
> java.sql.SQLException which were introduced in Java 6. I don't think
> we are forbidden to further refine those subclasses. But we would want
> to verify that.
>
> Before doing this, I would want us to agree on a model for how far
> this refinement goes. I assume that we don't want to introduce a
> separate subclass for each possible SQLState. The SQLStates are
> organized into families, identified by the leading two digits of the
> SQLStates. We could introduce a separate subclass for each of those
> families, but that would still be a lot of subclasses and it wouldn't
> solve John's problem.

I think we would also need to find a solution to the old problem with
sharing classes between the client and the engine. We wouldn't want to
end up with a solution where one would have to check for one exception
class if one is using the embedded driver, and another class if one is
using the client driver.

-- 
Knut Anders

[jira] [Closed] (DERBY-6475) Update documentation for SYSTRIGGERS after DERBY-5866 changes

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-6475.
-
   Resolution: Fixed
Fix Version/s: 10.12.0.0
 Assignee: Myrna van Lunteren

Thanks, Myrna. The fix looks good to me. Closing the issue.

> Update documentation for SYSTRIGGERS after DERBY-5866 changes
> -
>
> Key: DERBY-6475
> URL: https://issues.apache.org/jira/browse/DERBY-6475
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.11.1.1
>        Reporter: Knut Anders Hatlen
>Assignee: Myrna van Lunteren
>Priority: Minor
> Fix For: 10.12.0.0
>
> Attachments: DERBY-6475.diff, rrefsistabs79888.html
>
>
> DERBY-5866 changed the meaning of the SYS.SYSTRIGGERS.CREATIONTIMESTAMP 
> column.
> Currently, the reference manual's mentioning of this columns says "Time the 
> trigger was created".
> I suggest we add something similar to:
> "The time is stored in UTC if the trigger was created after upgrading to 
> 10.11. Otherwise, it is stored in the local time zone at the time the trigger 
> was created. The primary purpose of this column is to ensure the correct 
> execution order of triggers, and the timestamp may have been adjusted for 
> that purpose, so applications should not rely on the accuracy of these 
> values."
> Or maybe that's too much... "For internal use only" might suffice.



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

[jira] [Commented] (DERBY-6475) Update documentation for SYSTRIGGERS after DERBY-5866 changes

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6475:
---

Yes, that sounds fine.

> Update documentation for SYSTRIGGERS after DERBY-5866 changes
> -
>
> Key: DERBY-6475
> URL: https://issues.apache.org/jira/browse/DERBY-6475
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.11.1.1
>    Reporter: Knut Anders Hatlen
>Priority: Minor
>
> DERBY-5866 changed the meaning of the SYS.SYSTRIGGERS.CREATIONTIMESTAMP 
> column.
> Currently, the reference manual's mentioning of this columns says "Time the 
> trigger was created".
> I suggest we add something similar to:
> "The time is stored in UTC if the trigger was created after upgrading to 
> 10.11. Otherwise, it is stored in the local time zone at the time the trigger 
> was created. The primary purpose of this column is to ensure the correct 
> execution order of triggers, and the timestamp may have been adjusted for 
> that purpose, so applications should not rely on the accuracy of these 
> values."
> Or maybe that's too much... "For internal use only" might suffice.



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

[jira] [Commented] (DERBY-6503) Starting network server on a network drive fails with JDK 7 on Windows

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6503:
---

I wouldn't recommend spending a lot of time backporting this fix. All the fix 
does, is changing a ClassCastException to an IOException. It makes it easier to 
see what the underlying problem is, but the cases that failed before the fix, 
will still fail after the fix.

> Starting network server on a network drive fails with JDK 7 on Windows
> --
>
> Key: DERBY-6503
> URL: https://issues.apache.org/jira/browse/DERBY-6503
> Project: Derby
>  Issue Type: Bug
>  Components: Network Server, Services
>Affects Versions: 10.10.1.1
>    Reporter: Knut Anders Hatlen
>Assignee: Mamta A. Satoor
> Fix For: 10.11.1.1
>
> Attachments: DERBY6503_backport_patch1_diff.txt, d6503-1a.diff
>
>
> Starting a network server on a network drive with JDK 7 on Windows fails. The 
> reported exception is a ClassCastException, but the underlying exception is 
> the following:
> java.nio.file.AccessDeniedException: \\host\path\derby.log
>   at 
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
>   at 
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
>   at 
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
>   at 
> sun.nio.fs.WindowsAclFileAttributeView.setAcl(WindowsAclFileAttributeView.java:221)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwnerViaACLs(FileUtil.java:897)
>   at 
> org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwner(FileUtil.java:747)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.PBmakeFileHPW(SingleStream.java:205)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:401)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:72)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.makeFileHPW(SingleStream.java:394)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.createDefaultStream(SingleStream.java:356)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.makeStream(SingleStream.java:132)
>   at 
> org.apache.derby.impl.services.stream.SingleStream.boot(SingleStream.java:92)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1991)
>   at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:334)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:541)
>   at 
> org.apache.derby.impl.services.monitor.FileMonitor.startModule(FileMonitor.java:44)
>   at 
> org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:362)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:343)
>   at 
> org.apache.derby.impl.services.monitor.FileMonitor.(FileMonitor.java:58)
>   at 
> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:285)
>   at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:67)
>   at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199)
>   at org.apache.derby.jdbc.EmbeddedDriver.(EmbeddedDriver.java:95)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:188)
>   at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1032)
>   at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:732)
>   at 
> org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277)
>   at 
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353)



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

[jira] [Commented] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6287:
---

Please also check that it works on CDC and Java 5 before you backport this fix. 
My guess is that we still need reflection on 10.10 in order to run on those 
platforms.

> Don't use reflection to call Java 6 methods in FileUtil
> ---
>
> Key: DERBY-6287
> URL: https://issues.apache.org/jira/browse/DERBY-6287
> Project: Derby
>  Issue Type: Improvement
>  Components: Services
>Affects Versions: 10.11.1.1
>    Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Fix For: 10.11.1.1
>
> Attachments: DERBY6287_patch1_diff.txt, derby-6287-1a.diff
>
>
> The FileUtil class uses reflection to call the following java.io.File methods:
>   setWritable(boolean, boolean)
>   setReadable(boolean, boolean)
>   setExecutable(boolean, boolean)
> Reflection was used because the methods were introduced in Java 6, and the 
> code had to run on older platforms. Now Java 6 is the lowest supported 
> platform, so we can call the methods directly.



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

Re: [Java DB - testing] Error continuous 10.10 (rev 1639238)

[Knut Anders Hatlen]

Mamta Satoor  writes:

> When I click on the Test report above, I don't see any errors there.

When I checked it earlier today, it said that derbyall on amd64_jdk7 had
timed out. I suppose it was restarted and that the second run went well.

> On Wed, Nov 12, 2014 at 11:51 PM,  wrote:
>
> Java DB testing and reporting infrastructure.
> 
> Error continuous 10.10 (rev 1639238)
> 
> There were execution errors and/or timeouts.
> 
> Test report:
> http://download.java.net/javadesktop/derby/request_5599136
> 
>
>

-- 
Knut Anders

[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6764:
---

Thanks for fixing those issues. The latest continuous integration test run 
completed without any failures.

As to ArrayList vs arrays, I'd probably consider the benefits of having simpler 
code greater than the cost of dropping the {{}} part and possibly 
adding a cast when backporting to 10.10. But I don't think it's a very big deal.

> analyze impact of poodle security alert on Derby client - server ssl support
> 
>
> Key: DERBY-6764
> URL: https://issues.apache.org/jira/browse/DERBY-6764
> Project: Derby
>  Issue Type: Task
>Affects Versions: 10.12.0.0
>Reporter: Myrna van Lunteren
>Assignee: Mamta A. Satoor
> Fix For: 10.12.0.0
>
> Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt
>
>
> Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability 
> (CVE-2014-3566)
> Derby supports ssl between the client and network server.
> We should investigate this and decide if we need to change our product, e.g. 
> to eliminate support for SSL in favor of its successor TLS.



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

Re: Wrong jira number in commit comment

[Knut Anders Hatlen]

Mamta Satoor  writes:

> Hi Myrna,
> I tried deleteing the comment from DERBY-674 but I do not see the
> option to do it. What I have noticed is I can only delete the comments
> I have added.

Hi Mamta,

My JIRA user apparently has privileges to delete other people's
comments, so I went ahead and removed the commit notification and your
comment from DERBY-674.

-- 
Knut Anders

[jira] [Issue Comment Deleted] (DERBY-674) Add a new regression test to catch large increases in the size of jar files

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-674:
-
Comment: was deleted

(was: Commit 1636668 from [~mamtas] in branch 'code/trunk'
[ https://svn.apache.org/r1636668 ]

DERBY-674(analyze impact of poodle security alert on Derby client - server ssl 
support)

Changes based on Knut's feedback.)

> Add a new regression test to catch large increases in the size of jar files
> ---
>
> Key: DERBY-674
> URL: https://issues.apache.org/jira/browse/DERBY-674
> Project: Derby
>  Issue Type: Improvement
>  Components: Test
>Reporter: David Van Couvering
>Priority: Minor
>  Labels: derby_triage10_8
>
> Footprint is one of the key principles of Derby.  We should have a regression 
> test that looks at the size of the various jar files and compares them 
> against a high-water-mark and report an error or warning if the size exceeds 
> the water mark.



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

[jira] [Issue Comment Deleted] (DERBY-674) Add a new regression test to catch large increases in the size of jar files

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-674:
-
Comment: was deleted

(was: The commit comment above is meant for DERBY-6764 and not DERBY-674.)

> Add a new regression test to catch large increases in the size of jar files
> ---
>
> Key: DERBY-674
> URL: https://issues.apache.org/jira/browse/DERBY-674
> Project: Derby
>  Issue Type: Improvement
>  Components: Test
>Reporter: David Van Couvering
>Priority: Minor
>  Labels: derby_triage10_8
>
> Footprint is one of the key principles of Derby.  We should have a regression 
> test that looks at the size of the various jar files and compares them 
> against a high-water-mark and report an error or warning if the size exceeds 
> the water mark.



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

[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6764:
---

I'd suggest the following changes to make the code easier to follow, and 
hopefully easier to keep free of bugs:

- remove the {{foundProtocolToRemove}} variable, and instead just check 
{{(removedProtocolsCount < enabledProtocols.length)}}.
- rename the {{removeTwoProtocols}} and {{removedProtocolsCount}} variables. 
Their current names give the impression that they keep track of the protocols 
that are to be removed, but they're actually keeping track of the exact 
opposite (that is, which protocols to keep). Something like 
{{supportedProtocols}} and {{supportedProtocolsCount}} would show more clearly 
what they're used for.
- or maybe even better: use an {{ArrayList}} to collect the supported 
protocols, and call {{toArray()}} on the list to get the array to pass to 
{{setEnabledProtocols()}}. Then there's no need to do manual counting of 
supported/removed protocols or manual array copying, and less potential for 
making mistakes.

> analyze impact of poodle security alert on Derby client - server ssl support
> 
>
> Key: DERBY-6764
> URL: https://issues.apache.org/jira/browse/DERBY-6764
> Project: Derby
>  Issue Type: Task
>Affects Versions: 10.12.0.0
>Reporter: Myrna van Lunteren
>Assignee: Mamta A. Satoor
> Fix For: 10.12.0.0
>
> Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt
>
>
> Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability 
> (CVE-2014-3566)
> Derby supports ssl between the client and network server.
> We should investigate this and decide if we need to change our product, e.g. 
> to eliminate support for SSL in favor of its successor TLS.



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

[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6764:
---

I see that there are failures in the Oracle tests after the commit. I think 
that's because of the inconsistency mentioned in my previous comment, which 
causes one of the elements in the array to be null when two protocols have been 
removed.

{noformat}
java.lang.IllegalArgumentException: Protocol cannot be null
at 
com.sun.net.ssl.internal.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:116)
at 
com.sun.net.ssl.internal.ssl.ProtocolList.(ProtocolList.java:38)
at 
com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.setEnabledProtocols(SSLServerSocketImpl.java:184)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(NetworkServerControlImpl.java:736)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(NetworkServerControlImpl.java:93)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:785)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:782)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:781)
at 
org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2316)
at 
org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353)
{noformat}

> analyze impact of poodle security alert on Derby client - server ssl support
> 
>
> Key: DERBY-6764
> URL: https://issues.apache.org/jira/browse/DERBY-6764
> Project: Derby
>  Issue Type: Task
>Affects Versions: 10.12.0.0
>Reporter: Myrna van Lunteren
>Assignee: Mamta A. Satoor
> Fix For: 10.12.0.0
>
> Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt
>
>
> Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability 
> (CVE-2014-3566)
> Derby supports ssl between the client and network server.
> We should investigate this and decide if we need to change our product, e.g. 
> to eliminate support for SSL in favor of its successor TLS.



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

[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen commented on DERBY-6764:
---

Thanks for fixing this. Note, though, that there were two occurrences of 
{{(removeTwoProtocols.length)-1}} (both when allocating the new array and when 
calling arraycopy), and the patch only changed one of them (in the call to 
arraycopy). I think both should be changed for completeness.

> analyze impact of poodle security alert on Derby client - server ssl support
> 
>
> Key: DERBY-6764
> URL: https://issues.apache.org/jira/browse/DERBY-6764
> Project: Derby
>  Issue Type: Task
>Affects Versions: 10.12.0.0
>Reporter: Myrna van Lunteren
>Assignee: Mamta A. Satoor
> Fix For: 10.12.0.0
>
> Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt
>
>
> Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability 
> (CVE-2014-3566)
> Derby supports ssl between the client and network server.
> We should investigate this and decide if we need to change our product, e.g. 
> to eliminate support for SSL in favor of its successor TLS.



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