I like this notion. Much less maintenance headache.
The catch can probably be generic, and just say "Schema Reload Error: Class %s is needed by this schema but was not found in this Java version (%s), nor on the classpath." and leave it at that, or maybe we print the classpath like we do for Misc.getRequiredResource if the resource isn't found. ________________________________ From: Steve Lawrence <slawre...@apache.org> Sent: Tuesday, April 10, 2018 10:06:28 AM To: firstname.lastname@example.org; Mike Beckerle Subject: Re: Java 7 and Base64 To solve the reload issue, instead of laziliy creating Base64 objects (I agree, this would be a headache), would it work to catch ClassNotFoundException when reloading a parser and inspect the message? If the message contains java.util.Base64, then we can throw an error explaining that this saved parser will only work on Java 8 due to requiring base64 layering? That would allow most saved parsers to work on Java 7. - Steve On 04/10/2018 09:55 AM, Mike Beckerle wrote: > I can put in a check that will SDE unless at least Java 8 if a base64 > layering is used. > > > I am a little concerned that a serialized parser/unparser will have objects > stored in it, the construction of which will make calls to Java-8-only base64 > code. So it will fail on reloading the schema. We can try to avoid this by > treatning the Base64 objects as if they were non-serializable - so they get > constructed lazily after the reloading is done. But this is a maintenance > headache of course. > > > I suppose it is ok to document a restriction that Java 7 cannot use > pre-compiled schemas created with Java 8. Or perhaps can't use pre-compiled > schemas at all? > > > > > > ________________________________ > From: Steve Lawrence <slawre...@apache.org> > Sent: Tuesday, April 10, 2018 8:37:53 AM > To: email@example.com; Mike Beckerle > Subject: Re: Java 7 and Base64 > > Considering that Java 7 was end of life'd 3 years ago and we don't test > at all on Java 7, I think it's reasonable to continue requiring Java 8, > especially if it makes our lives easier for coding. > > Perhaps we can say that Base64 layering is never supported in Java 7, > regardless of the errorOnUnsupportedJavaVersion tuanble, and have a > runtime Java version check that will fail with an error if any base64 > layering exists in the schema? > > - Steve > > > On 04/10/2018 08:12 AM, Mike Beckerle wrote: >> So we recently added a feature allowing Daffodil to run on Java 7, with the >> disclaimer that we don't test on Java 7. >> >> Well I am working on adding "layering" aka "base64" support to Daffodil, and >> Java 8 introduced a very nice java.util.Base64 class which is very easy to >> use. >> >> What is our policy on Java 8-dependency in Daffodil releases post 2.1.0. >> >> Should I go back to implementing this the Java 7 way using >> javax.mail.internet.MimeUtility? >> >> ...mike beckerle >> > >