Re: Well... I'm nearly running on java 17

--===============5722366176142335981==
Content-Type: multipart/alternative; boundary="0000000000008e98bb05e5955df3"

--0000000000008e98bb05e5955df3
Content-Type: text/plain; charset="UTF-8"

Hi Rick,

Thanks for sharing your results!

It looks like I wrote that test myself, 13 years ago. It's a bit weird that
I did a string comparison, since the assertion failure ends up looking
pretty weird.

In a sense, we shouldn't really be asserting the exact contents of the
journal, since all we care about is that the transaction got
compressed somehow and can be recovered successfully.

One hiccup with that is the fact that running GZIP on a small transaction
will tend to increase its size, not decrease it, so we can't simply assert
that the journal is smaller than it was without GZIP. :) Maybe if we really
care about it, we would generate a large transaction and assert that it
does, in fact, get smaller with GZIP.

On the other hand, having an assertion for the exact contents of the
journal is kind of nice to catch changes like you're seeing, because it's a
little surprising the GZIP format would change. Hopefully it is, at least,
a backward-compatible change, because you wouldn't want your old GZIP'd
journals to become unrecoverable due to a later Java upgrade.

One approach might be to try fiddling with the settings of the Deflater
underlying the GZIPOutputStream that our GZIPSerializer class is using.
It's held in a protected field (def) on the output stream instance, so it
can be accessed and configured by extending the GZIPOutputStream class
(which could be done inline with an anonymous class). According to the JDK
docs, there were some fields added to Deflater in Java 7, so maybe their
defaults have changed. It's possible that you could get it to behave like
it used to, and leave the assertion alone.

Adding the extra character to the assertion might be okay, but my main
concern is that without understanding where the character comes from, we'll
end up with a test that depends on the Java version. It will fail for all
versions < N, for whatever version N introduced the change that you're
seeing.

Cheers,
Justin




On Fri, Aug 5, 2022 at 5:20 PM Rick Ross via Prevayler-Discussion <
[email protected]> wrote:

> So I dusted off 2.7 and did some tweaking to get compiling.   I converted
> broken tests to Junit5 with assert4J and let the legacy engine handle the
> rest.
>
> So far so good, but there is an error I'm not really following.
>
> In
>
> JournalSerializerTest.testCompressedJournal()
>
> I get a single character error.
>
> [...]
>

--0000000000008e98bb05e5955df3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Rick,<div><br></div><div>Thanks for sh=
aring your results!</div><div><br></div><div>It looks like I wrote that tes=
t myself, 13 years ago. It&#39;s a bit weird that I did a string comparison=
, since the assertion failure ends up looking pretty weird.</div><div><br><=
/div><div>In a sense, we shouldn&#39;t really be asserting the exact conten=
ts of the journal, since all we care about is that the transaction got comp=
ressed=C2=A0somehow and can be recovered successfully.</div><div><br></div>=
<div>One hiccup with that is the fact that running GZIP on a small transact=
ion will tend to increase its size, not decrease it, so we can&#39;t simply=
 assert that the journal is smaller than it was without GZIP. :) Maybe if w=
e really care about it, we would generate a large transaction and assert th=
at it does, in fact, get smaller with GZIP.</div><div><br></div><div>On the=
 other hand, having an assertion=C2=A0for the exact contents of the journal=
 is kind of nice to catch changes like you&#39;re seeing, because it&#39;s =
a little surprising the GZIP format would change. Hopefully it is, at least=
, a backward-compatible change, because you wouldn&#39;t want your old GZIP=
&#39;d journals to become unrecoverable due to a later Java upgrade.</div><=
div><br></div><div>One approach might be to try fiddling with the settings =
of the Deflater underlying the GZIPOutputStream that our GZIPSerializer cla=
ss is using. It&#39;s held in a protected field (def) on the output stream =
instance, so it can be accessed and configured by extending the GZIPOutputS=
tream class (which could be done inline with an anonymous class). According=
 to the JDK docs, there were some fields added to Deflater in Java 7, so ma=
ybe their defaults have changed. It&#39;s possible that you could get it to=
 behave like it used to, and leave the assertion alone.</div><div><br></div=
><div>Adding the extra character to the assertion might be okay, but my mai=
n concern is that without understanding where the character comes from, we&=
#39;ll end up with a test that depends on the Java version. It will fail fo=
r all versions &lt; N, for whatever version N introduced the change that yo=
u&#39;re seeing.</div><div><br></div><div>Cheers,</div><div>Justin</div><di=
v><br></div><div><br></div><div><br></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 5, 2022 at 5:20 PM Ri=
ck Ross via Prevayler-Discussion &lt;<a href=3D"mailto:prevayler-discussion=
@lists.sourceforge.net">[email protected]</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20

   =20
 =20
  <div>
    <p>So I dusted off 2.7 and did some tweaking to get compiling.=C2=A0=C2=
=A0 I
      converted broken tests to Junit5 with assert4J and let the legacy
      engine handle the rest.=C2=A0 <br>
    </p>
    <p>So far so good, but there is an error I&#39;m not really following.=
=C2=A0=C2=A0
      <br>
    </p>
    <p>In <br>
    </p>
    <p><font face=3D"monospace">JournalSerializerTest.testCompressedJournal=
()
        <br>
      </font></p>
    <p>I get a single character error.</p>
    <p>[...]</p></div>
</blockquote></div></div>

--0000000000008e98bb05e5955df3--


--===============5722366176142335981==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5722366176142335981==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org

--===============5722366176142335981==--