Hi Thomas.
> I'm overriding 4 classes of the java.io package
>
> In theory, what you do should work, but making it 100% compatible with
> java.io.* is very hard, if not impossible: some applications may rely on
> implementation details. You could argue this is a bug in the application,
> but it's still problematic to have to change the bootclasspath to use your
> tool.
>
By "application", I believe you mean H2 here. I would greatly appreciate if
you could share some insights on why achieving 100% compatibility with
java.io.* would be hard or impossible, especially when H2, like all Java
clients, would, in my guess,
a) be relying only on the public, documented class interface of
java.io.*
AND
b) H2's test suite (such as TestFileSystem) further asserting on this
compatibility or lack thereof.
AND
c) the fact of H2's availability on multiple OSes and JVMs.
In fact, wouldn't this the current situation be a good usecase for
re-examining (a) or (b)?
Just fyi, all that I'm doing in my tweaks to the 4 java.io.* classes is
scheme-routing. Meaning, every method body in my version now has a giant
if-else inside: If the scheme of the filename is "myfs:" then I route it to
my code; else I use the original code. That's all!
So, if TestFileSystem is unable to pass some test, it may very well be due
to some bug in my code. Or, it could be because the H2 test suite is too
'tight' in some of its assumptions (bootclasspath use or no-use being one
example, but there could be others too). Or, both.
Since H2 has been around for many years, and would be much more stable and
robust by now in every way especially compared to my code which is just
work-in-progress, I would love to use H2 to test my code. But only if I
know at the outset that things like bootclasspath are allowed and no
implementation-specific java.io.* features are in use.
What I would do is keep that part (the java.io.* part) optional, so your
> tool can be used without having to change the bootclasspath. Then of course
> can only be used with H2 and Java 7+, but it's much cleaner and easier to
> use.
>
But if I could keep it optional, I would have preferred to /not/ use it at
all! My constraints is: The older Java apps, that have no counterpart for
NIO2 of Java 7 or FilePath of H2, have to run alongside H2 in the same JVM!
Regards,
/PN
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
