[tae898]

For users nothing changes in what is stored: a string column given to insert_columns (and through it to insert_dataframe and insert_arrow) on the JVM wheel stores the same values as before, and the same as the native wheel. How the column crosses JPype changes.

Refs #324, part of #315. This targets release/26.11.1 (the base of the wheels-only 26.11.1.post1); it changes the bridge jar, so it ships with the rebuilt wheel, and the engine commit, jars and image are untouched.

What changed:

• A column of nothing but str and None is now sent as one byte[] (the UTF-8 text of all rows back to back), one int[] of row + 1 offsets and, when the column has a null, one boolean[] of the null rows. They are wrapped in a new bridge class, StringColumn, and DocumentBatcher.insertColumns and insertColumnsParallel decode each row when they build its document. Before, _column_to_java called convert_python_to_java for every value and built an Object[] of Java Strings element by element.
• The transfer is a copy: the blob goes through bytes into jpype.JArray(jpype.JByte) and the offsets and mask through numpy into JArray(JInt) and JArray(JBoolean), as the numeric columns already do. I did not use a memoryview of Java or Python memory, since the JPype guide does not say whether it pins or copies.
• The type census, the lengths and the join run in C (set(map(type, ...)), np.fromiter(map(len, ...)), "".join).
• Kept on the per-element path, exactly as before: a mixed column (an int, bytes, a date-time, a list), an empty column, a column with a lone surrogate (no UTF-8 form: the blob builder gives up and never raises, and the old path refuses the column with the UnicodeEncodeError JPype raises, before anything is written, as it does for every bulk entry point), and a column whose text exceeds an int offset (2 GiB).
• Not touched: numeric columns, dataframe.py (it reaches the change through insert_columns), and the native wheel.

Memory, not measured: the blob holds the UTF-8 bytes plus 4 bytes per row (plus 1 per row for a mask) in Java at once, where the old path held an Object[] of references plus one Java String per distinct value (UTF-16) for the whole column, so a high-cardinality column holds less and a column of a few distinct values holds a little more. On the Python side the ASCII case builds the joined text and its encoded copy once (about the column's byte size each), and the non-ASCII case a list of the encoded rows (about 45 bytes per row plus the text) that is freed before the transfer. The Java Strings now live only for the row being built. The untimed profile study (queued) and the laptop A/B are what measure it; I make no speed or memory claim here.

Tests, which run in CI only:

• tests/test_insert_columns_string_blob.py (JVM wheel) spies on convert_python_to_java (no call for a string column, which fails on the old code), checks which columns become a StringColumn and which keep the per-element path, compares the stored table with the one the per-element path stores for the same columns (non-BMP characters, NUL, an empty string, a null, a 5,000-character string, in the synchronous and the parallel mode), and checks that the Java side refuses a malformed column.
• tests/test_insert_columns_strings.py (both wheels) checks that those values come back as given from a list, a numpy string array and an object array, in a mixed column, with a single row, and in the parallel mode.
• A local pytest run was not possible here, so I compiled and ran pyflakes on the Python files, ran the blob and offsets logic against a decoder on edge cases and random columns outside the JVM, and read the Java by eye: the CI build of the bridge jar is its first compile.

🤖 Generated with Claude Code