[p4] Java interface to Perforce / P4API for Java

Gordon Broom Gordon.Broom at pwrm.com
Wed Oct 31 15:55:25 PST 2001

Also be aware that "p4 -s" may not handle "text:" lines properly
(job005070).  It certainly did it in P4D/NTX86/2000.2/19882, and I assume
it's in 2001.1 too. I haven't received a notification on this bug, and have
used "p4 -G" to work around it (and also haven't upgraded to 2001.1 yet
(shhh.... :-) ).  Both "p4 -s" and "p4 -G" return the output from the
underlying ,v file in 4096 byte chunks.  The "p4 -s" output splits a text
line that straddles a 4K boundary into 2 "text:" lines, so upon reassembly
you have spurious newlines (because normally the newline in the data also
terminates the "text:" tag).  Even though "p4 -G" returns the data in 4K
chunks too, you don't have a problem because all the meta data is "out of

Gordon Broom 
Configuration Management Engineer
Power Measurement Ltd. <http://www.pwrm.com/>
+1 250 652-7100 x7608

-----Original Message-----
From: Chris Patti [mailto:cpatti at atg.com]
Sent: Wednesday, October 31, 2001 3:02 PM
To: perforce-user at perforce.com
Subject: RE: [p4] Java interface to Perforce / P4API for Java

At 04:32 PM 10/30/2001 -0800, you wrote:
>[Sending a copy to perforce-user, since I think that these URLs are
>particularly useful.   And "yes, the command-line interface is so
>robust and easy to use that I would NOT bother with the C++ API
>for any sort of build needs, ever. For linking against an application
>written in C++ that does other stuff, maybe; for Perl/shell/Python
>sorts of scripts, the command-line's great!"     -jab]
>At 12:32 PM 10/30/2001 -0700, you wrote:
>>Thanks for your response Jeff--I'll look into it.  Do you know if the
>>command-line interface is very robust?
>         VERY robust. You'll find FAQs at
>                 http://public.perforce.com/public/perforce/faq/index.html
>         The build one is 
> http://public.perforce.com/public/perforce/faq/build.html
>         I wouldn't bother with the API unless I was writing GUI
>         that needed a C++ library to link against; the most I'd do is
>         in Python (which I like a lot) and use the "p4 -G" option to have
>         write its output (and read its input) in Python-friendly 
> "marshal" objects.
>         -jab


All of what you say is completely true and I hope you'll understand that 
I'm *NOT* arguing with any of it (In fact see my endorsement of your 
suggestion below :)

However, doing the parsing by hand (even with -s, which is marginally 
useful at best..  It considers a sync with no files needing to be synced an 
error, whereas some REAL errors are marked info.  Useless, or nearly so) is 
not only a drag but a recipe for disaster.

A better solution is needed.  Perforce's inclusion of the undocumented -G 
option for Python scripters is proof positive that at least on some level 
they're aware of this.

I agree that the C++ api approach is severely flawed as well for most 
normal scripting applications - if faced with a choice between that 
extremely complex, event driven API (Way, *WAY* too heavyweight for what 
script writers want) and the command line flawed though it may be for 
scripting purposes, I'll choose the command line any day of the week.

If I can find time I plan to pursue a solution for Java that uses a Java 
class someone wrote that understands the Python marshalled object format, 
thus making Java a usable vehicle for pre-parsed objects to be passed back 
from the p4 client using the -G option, more detail to follow.

(The Java class in question is at 
http://www.gjt.org/pkgdoc/org/gjt/jjt/marshal/index.html )

perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list