Re: [jgit-dev] Java NIO Options

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Tue, May 27, 2014 at 10:51 PM, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
>
>
> ----- Ursprungligt meddelande -----
>> Från: "Aaron Tull" <atull@xxxxxxxxxxx>
>> Till: jgit-dev@xxxxxxxxxxx
>> Skickat: onsdag, 28 maj 2014 1:59:14
>> Ämne: [jgit-dev] Java NIO Options
>>
>> I was trying to use JimFS with JGit to see if I could get an efficient in
>> memory repository built. All documentation states that the
>> InMemoryRepository should not be used outside of testing or simple
>
> The InMemoryRepository is meant for testing. What's the compelling reason
> for using it?
>
>> experiments while for some use cases it is also not sufficiently secure to
>> access the default file system.
>
> Why?

Maybe you want to clone a remote repository locally, but you don't
trust the remote or the JGit library to do something stupid like make
you overwrite /etc/passwd when you run them as root.

If you are just doing the clone to lookup a few objects locally,
because you can't remotely, this sort of makes sense. But
InMemoryRepository is currently only suitable for smallish things, as
it was written to support tests, not handle a clone of the Linux
kernel.


>> Currently JGit's interface and implementation is coded directly against the
>> java.io.File. This precludes any possibility of interopping directly with
>> nio classes. While a java.nio.Path has a toFile option, the toFile
>> implementation in JimFS correctly throws an UnsupportedOperationException.
>> When the java.io.File instance is created, the FileSystem is set to the
>> DefaultFileSystem and cannot be overridden (private static final).
>>
>> Has there been any thought to adding additional operations to support Paths
>> as arguments and changing the File based api to call to the Path api?
>
> Sure we have "thought" about it, but to actually do it there must be an compelling
> need, rather than a "it'd be nice to"-need.
>
> As for one part of NIO, JGit has supported memory mapping of pack files for a long time, but it's not the
> default. You can enable it using core.packedgitmmap = true. I'm mostly on Mac nowadays and
> as I recall it, memory mapping only helps on Linux. On Windows and OS X it doesn't buy anything,
> because the remapping call is so expensive. Only Linux does it efficiently.
>
> The we do use some NIO2 stuff too, through the Java7 bundle. That's how we support symbolic
> links if your JRE supports it, but the API is till Java 5/Java 6 compatible.

Right, we are (still!) targeting Java 5 and Java 6 platforms. So we
can't go crazy and use Java 7 NIO features throughout the core part of
the JGit library. But we can do it through some minimal sections that
are important and easily isolated, like symbolic link support.

There has been talk about dropping Java 5, but not 6 compatibility.
Unfortunately there is no plan of action to actually do that.