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: dev@daffodil.apache.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: dev@daffodil.apache.org; 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

Reply via email to