[jcifs] Re: jcifs-0.7.10 released

[Eric]

> Specifically, I want the decoding/encoding technique to be consistent. All 
> existing code in the smb package uses decoding/encoding methods that
> pass the object being decoded/encoded, source or destination byte array,
> and the index into that array where the object is being decoded or
> encoded. This is much more efficient than allocting storage with 'new
> byte[..]' encoding your message and then arraycopy-ing that into another 
> bigger buffer also allocated dynamically, etc.

Will do.  I have a tendency to under-optimize my R & D code (the "if it 
ain't broke" fallacy).  I'll pick over my stuff when I get a chance.

> jCIFS is not slow so whatever I'm doing can't be too bad. The specific
> examples in your code are using writeUShort(ByteArrayOutputSteam,
> value) which calls ByteArrayOutputSteam.write() for each byte

This isn't actually *too* bad, in theory -- ByteArrayOutputStream 
allocates a block internally, and only allocates more when the internal 
array is filled; so writing a single byte basically just does an 
internal[counter++] = value.  I say "in theory", however, because I 
neglect to specify an initial capacity when creating the 
ByteArrayOutputStream, so it uses the default of 32 bytes (which is way 
too small).

> ServerMessageBlock.writeTime()
> could have been used where you encode a 64bit TIME structure in
> NtlmPaswordAuthentication.createBlob(). 

Wasn't aware of it's existence.

> Also, querying Properties at Runtime is very expensive.

Agreed -- I wasn't sure of the "policy" on this.  In most places, jCIFS 
reads the props in an initializer (and I think the documentation 
indicates properties should be fixed in advance).  Some places had them 
dynamically read, however, so I didn't know if I should be handling 
cases in which the user does a setProperty mid-execution.  Doing them at 
init time is definitely preferable.

> 
> I'm happy to see you working in the SMB layer but I have to enforce my
> coding standards in there. I realize that in many cases efficiency is not
> very important but if it effects something that happens very frequently
> (like every SMB) could have a noticable impact on performace. I'd like
> to see you use the same techniques in all the packages but if it's mosty
> your code I would be a fool to complain considering you're knowledge of
> HTTP and all the web service stuff that I'm clueless about.
> 

I don't consider constructive criticism "complaints" -- I obviously want 
to end up with the best product, and input/feedback are essential to the 
process.  That's why I send out updates piecemeal (rather than 
submitting pre-built release packages with my changes included, as was 
previously offered); as you are the lead on jCIFS, I consider it your 
right and privilege to perform the final review on all my submissions 
before inclusion.  The *last* thing I want to do is sacrifice quality 
for features.

I'll go through and do some auditing of my stuff (both the new and the 
old) and look for opportunities for optimization.  Thanks!


Eric