Hi,

Sure, H2 we can change, but I guess you want to support other applications
as well, and some are not as easy to change. If you can show there is a bug
in H2 or the unit test of H2: patches are welcome!

> But if I could keep it optional, I would have preferred to /not/ use it
at all!

What I mean is:

Legacy: For some libraries and applications that use java.io.* directly,
you can use the bootclasspath part (changed java.io. classes). That way the
application and library doesn't have to be changed, but starting the JVM is
more complicated.

Clean: For other libraries and applications, for example H2, that do have a
file system abstraction or use Java 7 style NIO2. That simplifies starting
those applications, as no bootclasspath hacks are needed.

There might be mixed cases (both Legacy and Clean) within the same JVM,
that would result in Legacy mode. But there are also Clean use cases, for
example running the H2 server.

Regards,
Thomas







On Wed, Apr 30, 2014 at 9:19 AM, PN <pingnik...@gmail.com> wrote:

> 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 h2-database+unsubscr...@googlegroups.com.
> To post to this group, send email to h2-database@googlegroups.com.
> Visit this group at http://groups.google.com/group/h2-database.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Reply via email to