The answer is NO.
But why on Earth would you want to move masses of data from Java to the server ? (1) Java isn't designed for that, so it will be very slow (2) native bcp or C+bcp or perl+bcp or any shell command+bcp would scream circles around it, and displace it anyway. It's like wanting to run bcp via ODBC or JDBC.
We need to move away from Maslow's Hammer and Use the Right Tool for the Job.
Further detail, responding to comments:
An ordinary PROGRAM that connects to the ASE server (Client-Server style) uses the provided Open Client Library; this is native, and moves the TDS packets efficiently. The connection is a universally available one inch garden hose. PROGRAMS written in C, C++, COBOL, Perl, and PowerBuilder use this transport.
ODBC (and thus JDBC because it is built on top of ODBC) is a simple method of connecting to the server using a one millimetre hose. While this is quite adequate for tasks such as using Excel to draw charts directly from ASE tables, where the data transfer speed is not relevant; it is quite inadequate for moving data of any substantial volume, for normal app access to a data server (except where the "programmer" is ignorant of the fact that [1] is available).
.
Java does not have [1] and is limited to this [2] transport.
bcp is an utility PROGRAM (exists on its own) supplied by the vendor that connects to the server much more tightly. It is not a "special bit of the client API". There is no "lying and cheating" involved, all constraints are directed by the DBA performing the task. The connection is a two and a half inch fire hose, not generally available to the public. It is designed to move large data volumes at speed. If used on the same host as the server, since the hose is not reticulated through the network, it moves data even faster.
Much later, the vendor made the bcp capability available as a Library (API in your terms), which can therefore be invoked from any reasonably architected compiler. C, C++, COBOL, and Perl are such, and produce PROGRAMS, and therefore provide access to this library directly from your code. The connection is the same two and a half inch fire hose, but due to the additional layers, it runs at a maximum speed of a two inch fire hose.
(Note to readers who expect this to be a complete list: There are two other options which I have not detailed here, because they are server-server and not relevant to this thread).
Since Java PROGRAMS are currently limited to the one millimetre connection to the ASE server, there is no use in providing the bcp API to Java (you will merely have a two and a half inch fire hose reticulated through the network, with a FLOW of one millimetre), it is an absurd enterprise. There is a reason why, despite the millions many organisations have poured into Java, during its rather long um progression, none of them have spent money in providing a firehouse that moves drips and drops.
You cannot obtain the speed of a greyhound from a dachshund, there is no use giving it racetrack training. You can stop whispering promises in its ear.
Second, Java cannot handle large (source) data sets efficiently, it was not designed for that. Therefore even if the JDBC strangulation was lifted (eg. a native Open Client Library was implemented), it still cannot move data as fast as C, C++, COBOL, Perl, PB; it will move data at a trickle (quarter inch ?) in the one inch hose. Therefore, even then, it would be absurd to provide the bcp capability to the Java library; that would be worthwhile if and when Java (which was designed with other priorities in mind) is annointed with large data transfer capability.
It may help to move out of your Java, Java, and nothing but Java mindset, and Use the Right Tool (PROGRAM) for the Job. If you are a Java "programmer", then at least you need to familiarise yourself with the capability and limitations of your programming language and the libraries available. The original question demonstrates complete ignorance of that, hence I had to supply it in my revised post.
Programmers who are not limited to Java, think about where the large data source is located; minimise data transfers across networks; think about what PROGRAMS are already written and that can be used (as opposed to writing their own in isolation from the rest of the planet); and use them.
Finally, for understanding, even if you did obtain the bcp capability in some Library, and implemented it, when you place the "program" in the real world, any reasonable DBA will dismiss it due to its trickle speed data transport, and use bcp with its fire hose instead.
If all of that is beyond your understanding, just read the first line, and stop there.