[jcifs] jcifs-1.0.0 released / 5 Years and Beyond

[Michael B Allen]

See http://jcifs.samba.org/ for an HTML version of this message.

According  to  the  freshmeat page, JCIFS is 5 years old today. The project
has come a long way in those years. Its features now include: 

    *  The  NTLM HTTP Authentication Filter, which adds easy Single Sign On
    (SSO)  functionality  to  Java  Servlet containers, is clearly the most
    popular  feature  of  JCIFS.  Eric  did  a great job of deciphering the
    details  of that protocol. The filter is mind-numbingly easy to install
    as  all  it  requires  is  the  JCIFS  jar and a filter section in your
    web.xml with two or three init parameters [1].

    *  The performance of JCIFS is one of its more surprising achievements.
    Consider  the client can enumerate 5GB of files and directories in less
    than  10  seconds  [2]. To reduce memory usage and increase concurrency
    JCIFS  automatically  reuses existing transports and sessions. One nice
    artifact  of  this  design  is that the NTLM HTTP Authentication Filter
    scales  to  thousands  of  active  clients.  And because the negotiated
    credentials  are  cached  in  the  user's  HTTP  session  the number of
    concurrent user's supported can be many times greater than that.

    *  The  SmbFile.copyTo()  method  is a venerable feature in itself. All
    file  and  directory  attributes  and timestamps are mirrored perfectly
    [3].  It  employs  an  extra  thread  to write data while the next read
    operation  is  in  progress.  This optimization makes JCIFS the fastest
    client  available  for  copying  large  trees  of files and directories
    across hosts (neither of which needs to be the local machine).

    *  Accessing  DFS  volumes  (sub-trees  of  files  and directories that
    actually  reside on another host) is fully transparent to the user. The
    client may be redirected multiple times in the middle of any operation.
    After a redirection has occurred the mapping is cached but the cache is
    only queried for transports that indicate they host DFS volumes.

    *  SMB signing is robust and negotiated automatically with servers that
    require it.

    *   The  SmbRandomAccessFile  implementation  is  a  complete  drop  in
    replacement for the standard java.io.RandomAccessFile. When opened with
    SmbFile.FILE_NO_SHARE  share access this class is a legitimate database
    API.

    *  Named  Pipes  of  all  types are fully supported. TransactNamedPipe,
    CallNamedPipe,  and  standard  file  I/O  style pipes are all supported
    using    a    single    generic    API    that    conforms    to    the
    InputStream/OutputStream model.

    *  JCIFS'  name resolution capability is very sophisticated. WINS, DNS,
    NetBIOS broadcast queries, and remote lmhosts files are supported well.
    Which  services and the order in which each service is queried is fully
    configurable. The name service cache policy is also adjustable.

    *  JCIFS  implements  the SMB URL Draft Specification V07 and processes
    all  SMB URLs through an SMB URL proticol handler. This same handler is
    used  to  build  standard  java.net.URL  objects  which  means once the
    protocol   handler  is  registered  SMB  URLs  can  be  used  with  any
    application           that           uses           URLs          (e.g.
    -Djava.rmi.server.codebase=smb://mymachine/c/download/myapp.jar).

Other  features  include  NTLM and LMv2 Authentication [4], optimal request
batching,  NT  STATUS codes, full transactions, large file support, Unicode
support  from the ground up [5], NTLM HTTP authentication wrappers for HTTP
and  HTTPS clients, a simple logging facility, and extensive documentation.
If  that's  not  enough, there's always jcifs-ext where bleeding edge JCIFS
extensions live.

But  the best feature of JCIFS is the simplicity of the API itself. We have
diligently   resisted  "feature  creep".  The  SMB  URL  allows  addressing
resources  with  wonderful ease. The SmbFile class is a drop in replacement
for java.io.File so if you know how to use that, you know how to use JCIFS.

JCIFS  is  now  one  of  the  most  sophisticated and powerful CIFS clients
available  free or otherwise. It is used in production environments by many
large  commercial  organizations  and the Open Source model has worked well
for us as these users have contibuted valuable feekback that has made JCIFS
rock solid.

To  commemorate these achievements we are proud to release JCIFS 1.0. Aside
from  fixing  broken  links  and a few packaging tweaks it is not different
from  0.9.8  and  we hope it stays that way. Moving forward, the 1.0 branch
will only receive critical fixes.

In  recent weeks a MIDL compatible IDL compiler was developed. Coupled with
the  Jarapac  DCE/RPC  framework for Java it is now practical to make MSRPC
calls.  This  means that the Microsoft network management API functions are
very  close  to being incorporated into JCIFS. IDL files need to be written
and  APIs need to be devised but we will soon be able to create users, edit
groups,  control  NT  services, reboot machines, edit the registry, execute
programs  on  a  remote  host,  and  much  much  more. This will open up an
entirely new level of integration between Java and Microsoft environments.

Finally,  thanks  goes  out  to  Eric  and Chris and everyone else that has
contributed  their  time.  JCIFS  is truely a great product because we have
taken  full  advantage  of  the  Open  Source model. We would not have made
nearly  as  much progress without the code, bug fixes, problem reports, and
solutions provided by our users.

--

[1]  although  running  through web servers that also try to negotiate NTLM
HTTP or do not properly support keep-alives is problematic
[2] Client Host: 500MHz Debian Linux "testing" Java 1.4 JCIFS 1.0.0; Target
Workstation:  2.7GHz  5.77GB Windows NT 4 sp6; Nework: 100 Mbps full-duplex
switched;  Test  Program:  examples/T2Crawler.java  with println statements
commented   out,  default  properties,  ran  3  times  to  load  up  target
workstation  cache;  Results: $ time java -Djcifs.properties=../miallen.prp
T2Crawler  smb://myworksta/c$/  3  1000,  real  0m9.929s  user 0m5.580s sys
0m0.600s
[3] although currently extended attributes are not copied
[4] NTLMv2 is not fully supported but LMv2 permits the client to operate in
NTLMv2 environments
[5]  Unicode  share  names are not supported but will be soon now that RPCs
are underway