Re: Well... I'm nearly running on java 17
Rick Ross via Prevayler-Discussion <[email protected]> Sat, 6 Aug 2022 10:26:11 -0700
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============5675109891227040763== Content-Type: multipart/alternative; boundary="------------2sBCeBylDxN46EHYF9PXrGia" Content-Language: en-US This is a multi-part message in MIME format. --------------2sBCeBylDxN46EHYF9PXrGia Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, While I certainly agree that a) it's a bit weird and b) it's kinda useful, I think the right thing to do (in theory) would be to store gzips as test resources at different java version points. Then you could get the same effect with simple end to end tests. However, it is inconceivable to me that gzip formats are not backwards compatible. So I presume that worst case, a manual unzip and rezip might be enough to recover but in reality, it should just work. I don't have a 1.6 zipped journal to use. BUT .. as I personally don't have old data to worry about, AND prevayler is not in terribly active development, I think there is some case to be made for just fixing the test (as I have done). I would be interested in a survey of active implementations, and of course, I am only too happy to PR my changes, if maintainers feel like that is desired. For the time being I am just building my own prevayler-core and factory and using that. R On 8/6/22 9:49 AM, Justin T. Sampson wrote: > 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. > > [...] > > > > _______________________________________________ > To unsubscribe go to the end of this page:http://lists.sourceforge.net/lists/listinfo/prevayler-discussion > _______________________________________________ > "Databases in Memoriam" --http://www.prevayler.org --------------2sBCeBylDxN46EHYF9PXrGia Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Hi Justin,</p> <p>While I certainly agree that a) it's a bit weird and b) it's kinda useful, I think the right thing to do (in theory) would be to store gzips as test resources at different java version points. Then you could get the same effect with simple end to end tests.<br> </p> <p>However, it is inconceivable to me that gzip formats are not backwards compatible. So I presume that worst case, a manual unzip and rezip might be enough to recover but in reality, it should just work. I don't have a 1.6 zipped journal to use.<br> </p> <p>BUT .. as I personally don't have old data to worry about, AND prevayler is not in terribly active development, I think there is some case to be made for just fixing the test (as I have done). <br> </p> <p>I would be interested in a survey of active implementations, and of course, I am only too happy to PR my changes, if maintainers feel like that is desired. <br> </p> <p>For the time being I am just building my own prevayler-core and factory and using that.</p> <p><br> </p> <p>R</p> <p><br> </p> <p><br> </p> <div class="moz-cite-prefix">On 8/6/22 9:49 AM, Justin T. Sampson wrote:<br> </div> <blockquote type="cite" cite="mid:CAAshuuE8FCbFo64coO=bsTNkS78TE-fe_mpLPLUYQ4DgP2R9AA@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div dir="ltr">Hi Rick, <div><br> </div> <div>Thanks for sharing your results!</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>Cheers,</div> <div>Justin</div> <div><br> </div> <div><br> </div> <div><br> </div> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 5:20 PM Rick Ross via Prevayler-Discussion <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <p>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. <br> </p> <p>So far so good, but there is an error I'm not really following. <br> </p> <p>In <br> </p> <p><font face="monospace">JournalSerializerTest.testCompressedJournal() <br> </font></p> <p>I get a single character error.</p> <p>[...]</p> </div> </blockquote> </div> </div> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ To unsubscribe go to the end of this page: <a class="moz-txt-link-freetext" href="http://lists.sourceforge.net/lists/listinfo/prevayler-discussion">http://lists.sourceforge.net/lists/listinfo/prevayler-discussion</a> _______________________________________________ "Databases in Memoriam" -- <a class="moz-txt-link-freetext" href="http://www.prevayler.org">http://www.prevayler.org</a> </pre> </blockquote> </body> </html> --------------2sBCeBylDxN46EHYF9PXrGia-- --===============5675109891227040763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5675109891227040763== 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 --===============5675109891227040763==--