Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Performance of commit preparation

I agree 100% with you on this Alex.  We need this code to be its own separate bundle/component and our main library has to work completely without this JNI layer.  I would even go so far as to say we should also have a version that forks and runs shell tools like ln -s to create symlinks so that even if we don't have the JNI layer we may still be able to honor symlinks on POSIX systems.

On Oct 23, 2010 12:42 AM, "Alex Blewitt" <alex.blewitt@xxxxxxxxx> wrote:
> On Sat, Oct 23, 2010 at 8:16 AM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
>> On Fri, Oct 22, 2010 at 5:08 PM, Matthias Sohn
>> <matthias.sohn@xxxxxxxxxxxxxx> wrote:
>>> 2010/10/21 Shawn Pearce <spearce@xxxxxxxxxxx>
>>>> NIO2 in Java 7 might solve this problem.  But right now that isn't
>>>> available to us.  I keep thinking about doing an optional tiny JNI
>>>> layer for JGit that just offers us a handful of helper routines.
>>>> Exposing the basics (type, length, last modified time) of POSIX and
>>>> Win32 stat system calls is one of those.
>>> any hints on which other helpers we would need in addition and
>>> how this layer should look like ? I would be willing to try this ...
>> I had 5 things in mind that might be useful to JGit:
> I agree these could be useful, but we should probably put the layer in
> a separate bundle/fragment, which can be removed if not needed. One of
> JGit's strengths over other environments is that it's pure Java, and I
> know that makes a difference in some organisations in terms of its
> adoption.
> If we put it in its own POM and build it as a fragment (which can be
> attached to JGit's bundle) with the interface in the main JGit bundle,
> then a Class.forName() inside JGit will do the lookup if it's on the
> path (or attached as a fragment) or null if not present.
> Alex

Back to the top