Thread: PL/Java 1.5.2 - fixes one regression in date conversion in 1.5.1
--- Note to packagers - please make sure the newly-added file $sharedir/pljava/pljava--1.5.1--1.5.2.sql will be installed, alongside those from prior releases. It is found in the pljava-packaging/target/pljava-*.jar file but not in any build directory (it gets added synthetically to the jar file based on a template). --- PL/Java 1.5 brings functions, triggers, and types in Java to PostgreSQL releases from 11 back to 8.2. Release 1.5.2 fixes a regression in 1.5.1 that affected the conversion of PostgreSQL date values to Java java.sql.Date objects. Project site: http://tada.github.io/pljava/ Release notes: http://tada.github.io/pljava/releasenotes.html ## Change Before 1.5.1, PostgreSQL date, time, and timestamp values could be accessed in PL/Java as java.sql.Date, java.sql.Time, and java.sql.Timestamp objects. PL/Java 1.5.1 added the option of accessing those values as objects of new classes in the Java 8+ java.time package. The new classes are recommended as a superior API for accessing dates, times, and timestamps. However, one regression resulted in the older conversion between PostgreSQL date and java.sql.Date, leading to an error of one day for some dates of the year in some time zones. Release 1.5.2 restores the former behavior. Please see the release notes for more complete information. Availability: 1.5.2 is available from GitHub as a source release, which builds quickly using Maven: Release page: https://github.com/tada/pljava/releases/tag/V1_5_2 This wiki page will add links to prebuilt packages that become available: https://github.com/tada/pljava/wiki/Prebuilt-packages
Re: Chapman Flack 2018-11-05 <5BE08D74.2060207@anastigmatix.net> > Before 1.5.1, PostgreSQL date, time, and timestamp values could be accessed > in PL/Java as java.sql.Date, java.sql.Time, and java.sql.Timestamp objects. > PL/Java 1.5.1 added the option of accessing those values as objects of new > classes in the Java 8+ java.time package. The new classes are recommended as > a superior API for accessing dates, times, and timestamps. > > However, one regression resulted in the older conversion between PostgreSQL > date and java.sql.Date, leading to an error of one day for some dates of the > year in some time zones. Release 1.5.2 restores the former behavior. Hi, 1.5.2 doesn't build on Jessie and Trusty anymore (JDK 7): https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/24/ https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/24/architecture=amd64,distribution=jessie/console 23:35:43 [ERROR] /<<PKGBUILDDIR>>/pljava-examples/src/main/java/org/postgresql/pljava/example/saxon/S9.java:[35,16] error:package java.time does not exist 23:35:43 [ERROR] /<<PKGBUILDDIR>>/pljava-examples/src/main/java/org/postgresql/pljava/example/saxon/S9.java:[879,12] error:cannot find symbol 23:35:43 [ERROR] symbol: variable TIME_WITH_TIMEZONE 23:35:43 [ERROR] location: class Types (There is another issue that apparently maven doesn't like running several times in parallel, it chokes while reading/writing to ~/.m2.) I've also enabled -Psaxon-examples - is it correct that no new files appear in the .deb, but the examples are inside the existing /usr/share/postgresql/11/pljava/pljava-examples-1.5.2.jar file? Christoph
Re: Chapman Flack 2018-11-05 <5BE08D74.2060207@anastigmatix.net> > Before 1.5.1, PostgreSQL date, time, and timestamp values could be accessed > in PL/Java as java.sql.Date, java.sql.Time, and java.sql.Timestamp objects. > PL/Java 1.5.1 added the option of accessing those values as objects of new > classes in the Java 8+ java.time package. The new classes are recommended as > a superior API for accessing dates, times, and timestamps. > > However, one regression resulted in the older conversion between PostgreSQL > date and java.sql.Date, leading to an error of one day for some dates of the > year in some time zones. Release 1.5.2 restores the former behavior. Hi, 1.5.2 doesn't build on Jessie and Trusty anymore (JDK 7): https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/24/ https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/24/architecture=amd64,distribution=jessie/console 23:35:43 [ERROR] /<<PKGBUILDDIR>>/pljava-examples/src/main/java/org/postgresql/pljava/example/saxon/S9.java:[35,16] error:package java.time does not exist 23:35:43 [ERROR] /<<PKGBUILDDIR>>/pljava-examples/src/main/java/org/postgresql/pljava/example/saxon/S9.java:[879,12] error:cannot find symbol 23:35:43 [ERROR] symbol: variable TIME_WITH_TIMEZONE 23:35:43 [ERROR] location: class Types (There is another issue that apparently maven doesn't like running several times in parallel, it chokes while reading/writing to ~/.m2.) I've also enabled -Psaxon-examples - is it correct that no new files appear in the .deb, but the examples are inside the existing /usr/share/postgresql/11/pljava/pljava-examples-1.5.2.jar file? Christoph
On 11/06/18 02:49, Christoph Berg wrote: > 1.5.2 doesn't build on Jessie and Trusty anymore (JDK 7): > > 23:35:43 [ERROR] .../example/saxon/S9.java:[35,16] error: package java.time does not exist > ... > I've also enabled -Psaxon-examples - is it correct that no new files > appear in the .deb, but the examples are inside the existing > /usr/share/postgresql/11/pljava/pljava-examples-1.5.2.jar file? Correct. 1) Thanks for enabling -Psaxon-examples :) 2) ... but don't enable it for JDK 7 builds (S9.java uses Java 8 features). I think that should solve the Jessie / Trusty problem. Cheers, -Chap
On 11/06/18 02:49, Christoph Berg wrote: > 1.5.2 doesn't build on Jessie and Trusty anymore (JDK 7): > > 23:35:43 [ERROR] .../example/saxon/S9.java:[35,16] error: package java.time does not exist > ... > I've also enabled -Psaxon-examples - is it correct that no new files > appear in the .deb, but the examples are inside the existing > /usr/share/postgresql/11/pljava/pljava-examples-1.5.2.jar file? Correct. 1) Thanks for enabling -Psaxon-examples :) 2) ... but don't enable it for JDK 7 builds (S9.java uses Java 8 features). I think that should solve the Jessie / Trusty problem. Cheers, -Chap
Re: Chapman Flack 2018-11-06 <5BE18B2F.9030805@anastigmatix.net>
> 2) ... but don't enable it for JDK 7 builds (S9.java uses Java 8 features).
>
> I think that should solve the Jessie / Trusty problem.
Thanks, you had probably mentioned that earlier, but I got lost with
too many PG versions in parallel.
There's still a problem, though. Jessie, 9.3, OpenJDK 7:
ERROR: java.lang.SecurityException: read on /usr/share/javazi/Europe/Prague
STATEMENT: SELECT sqlj.install_jar('file:/usr/share/postgresql/9.3/pljava/pljava-examples-1.5.2.jar', 'examples',
true)
https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/25/architecture=ppc64el,distribution=jessie/console
(That's on ppc64el, the rest is still building as of now.)
https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/25/
(The i386 errors are my fault.)
Christoph
Re: Chapman Flack 2018-11-06 <5BE18B2F.9030805@anastigmatix.net>
> 2) ... but don't enable it for JDK 7 builds (S9.java uses Java 8 features).
>
> I think that should solve the Jessie / Trusty problem.
Thanks, you had probably mentioned that earlier, but I got lost with
too many PG versions in parallel.
There's still a problem, though. Jessie, 9.3, OpenJDK 7:
ERROR: java.lang.SecurityException: read on /usr/share/javazi/Europe/Prague
STATEMENT: SELECT sqlj.install_jar('file:/usr/share/postgresql/9.3/pljava/pljava-examples-1.5.2.jar', 'examples',
true)
https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/25/architecture=ppc64el,distribution=jessie/console
(That's on ppc64el, the rest is still building as of now.)
https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/25/
(The i386 errors are my fault.)
Christoph
On 11/06/18 09:56, Christoph Berg wrote:
> There's still a problem, though. Jessie, 9.3, OpenJDK 7:
>
> ERROR: java.lang.SecurityException: read on /usr/share/javazi/Europe/Prague
> STATEMENT: SELECT sqlj.install_jar('file:/usr/share/postgresql/9.3/pljava/pljava-examples-1.5.2.jar', 'examples',
true)
Hmm. Does that happen only on Jessie? Is there a debianism where zoneinfo
files for Java are distributed in this other location instead of under
$JAVA_HOME ?
At present, the security manager for "trusted" PL/Java doesn't offer any
easy way to configure additional filesystem locations that are ok to read
from. I'm working on that for a future version, but that doesn't help here.
I suspect it could be made to work by adding
trust=org.postgresql.pljava.annotation.Function.Trust.UNSANDBOXED
in the @Function annotation on the issue199() method in
pljava-examples/src/main/java/org/postgresql/pljava/example/annotation/PreJSR310.java
However, it is only a regression test, and it is probably simpler just to
build with a patch to not run it (say, by removing the @SQLAction annotation
at the top of that file). That's preferable to adding UNSANDBOXED willy
nilly to things in the examples jar that people may casually install.
This is good for me to know about, as I was thinking of changing PL/Java's
behavior in a future release to set Java's timezone to match the PG
session's by default. Now I know not to do that until there is a way to
accommodate zoneinfo from atypical locations.
-Chap
On 11/06/18 09:56, Christoph Berg wrote:
> There's still a problem, though. Jessie, 9.3, OpenJDK 7:
>
> ERROR: java.lang.SecurityException: read on /usr/share/javazi/Europe/Prague
> STATEMENT: SELECT sqlj.install_jar('file:/usr/share/postgresql/9.3/pljava/pljava-examples-1.5.2.jar', 'examples',
true)
Hmm. Does that happen only on Jessie? Is there a debianism where zoneinfo
files for Java are distributed in this other location instead of under
$JAVA_HOME ?
At present, the security manager for "trusted" PL/Java doesn't offer any
easy way to configure additional filesystem locations that are ok to read
from. I'm working on that for a future version, but that doesn't help here.
I suspect it could be made to work by adding
trust=org.postgresql.pljava.annotation.Function.Trust.UNSANDBOXED
in the @Function annotation on the issue199() method in
pljava-examples/src/main/java/org/postgresql/pljava/example/annotation/PreJSR310.java
However, it is only a regression test, and it is probably simpler just to
build with a patch to not run it (say, by removing the @SQLAction annotation
at the top of that file). That's preferable to adding UNSANDBOXED willy
nilly to things in the examples jar that people may casually install.
This is good for me to know about, as I was thinking of changing PL/Java's
behavior in a future release to set Java's timezone to match the PG
session's by default. Now I know not to do that until there is a way to
accommodate zoneinfo from atypical locations.
-Chap
Re: Chapman Flack 2018-11-07 <5BE32DAE.7090508@anastigmatix.net>
> > There's still a problem, though. Jessie, 9.3, OpenJDK 7:
> >
> > ERROR: java.lang.SecurityException: read on /usr/share/javazi/Europe/Prague
> > STATEMENT: SELECT sqlj.install_jar('file:/usr/share/postgresql/9.3/pljava/pljava-examples-1.5.2.jar', 'examples',
true)
>
> Hmm. Does that happen only on Jessie? Is there a debianism where zoneinfo
> files for Java are distributed in this other location instead of under
> $JAVA_HOME ?
Trusty has the same problem.
Both ship with a "tzdata-java" package that has timezone info in that
location. Newer Java apparently use the standard TZ database in
/usr/share/zoneinfo/. (The only java-specific thing I could find was
-rw-r--r-- 1 root root 105882 Okt 17 09:31 /usr/lib/jvm/java-11-openjdk-amd64/lib/tzdb.dat )
> At present, the security manager for "trusted" PL/Java doesn't offer any
> easy way to configure additional filesystem locations that are ok to read
> from. I'm working on that for a future version, but that doesn't help here.
>
> I suspect it could be made to work by adding
> trust=org.postgresql.pljava.annotation.Function.Trust.UNSANDBOXED
> in the @Function annotation on the issue199() method in
> pljava-examples/src/main/java/org/postgresql/pljava/example/annotation/PreJSR310.java
>
> However, it is only a regression test, and it is probably simpler just to
> build with a patch to not run it (say, by removing the @SQLAction annotation
> at the top of that file). That's preferable to adding UNSANDBOXED willy
> nilly to things in the examples jar that people may casually install.
Hmm, just not building pljava on the older dists looks more and more
attractive...
> This is good for me to know about, as I was thinking of changing PL/Java's
> behavior in a future release to set Java's timezone to match the PG
> session's by default. Now I know not to do that until there is a way to
> accommodate zoneinfo from atypical locations.
Well, the location is typical for Java 7 on Debian. If it's still a
problem with Java 8+, I'd claim Java should be patched to recognize it
as "normal".
Christoph
Re: Chapman Flack 2018-11-07 <5BE32DAE.7090508@anastigmatix.net>
> > There's still a problem, though. Jessie, 9.3, OpenJDK 7:
> >
> > ERROR: java.lang.SecurityException: read on /usr/share/javazi/Europe/Prague
> > STATEMENT: SELECT sqlj.install_jar('file:/usr/share/postgresql/9.3/pljava/pljava-examples-1.5.2.jar', 'examples',
true)
>
> Hmm. Does that happen only on Jessie? Is there a debianism where zoneinfo
> files for Java are distributed in this other location instead of under
> $JAVA_HOME ?
Trusty has the same problem.
Both ship with a "tzdata-java" package that has timezone info in that
location. Newer Java apparently use the standard TZ database in
/usr/share/zoneinfo/. (The only java-specific thing I could find was
-rw-r--r-- 1 root root 105882 Okt 17 09:31 /usr/lib/jvm/java-11-openjdk-amd64/lib/tzdb.dat )
> At present, the security manager for "trusted" PL/Java doesn't offer any
> easy way to configure additional filesystem locations that are ok to read
> from. I'm working on that for a future version, but that doesn't help here.
>
> I suspect it could be made to work by adding
> trust=org.postgresql.pljava.annotation.Function.Trust.UNSANDBOXED
> in the @Function annotation on the issue199() method in
> pljava-examples/src/main/java/org/postgresql/pljava/example/annotation/PreJSR310.java
>
> However, it is only a regression test, and it is probably simpler just to
> build with a patch to not run it (say, by removing the @SQLAction annotation
> at the top of that file). That's preferable to adding UNSANDBOXED willy
> nilly to things in the examples jar that people may casually install.
Hmm, just not building pljava on the older dists looks more and more
attractive...
> This is good for me to know about, as I was thinking of changing PL/Java's
> behavior in a future release to set Java's timezone to match the PG
> session's by default. Now I know not to do that until there is a way to
> accommodate zoneinfo from atypical locations.
Well, the location is typical for Java 7 on Debian. If it's still a
problem with Java 8+, I'd claim Java should be patched to recognize it
as "normal".
Christoph