java - array length changes in openjdk -

i've seen strange behaviour in application can't explain. occur unfrequent can't reproduce them. while place these problems occur changes, common part seems array changes size after has been created (i know, not possible, hence: strange behaviour).

a couple of examples make point clear:

java.lang.stringindexoutofboundsexception: string index out of range: 86     @ java.lang.string.checkbounds(string.java:409)     @ java.lang.string.<init>(string.java:577)     @ com.acunia.fleet.diagnostics.providers.tacho.vdoklineinputparser.getrealdriverid(unknown source) 

the code cause this:

public string getrealdriverid(byte[] buffer) {   if (buffer.length > 86 && isdrivercardinserted(buffer)) {     return new string(buffer, 70, 16);   }      return null; } 

so first check buffer big enough (more 86 bytes) before trying create string them.

a second example:

java.lang.arrayindexoutofboundsexception: -1     @ java.lang.string.lastindexof(string.java:1889)     @ java.lang.string.lastindexof(string.java:1835)     @ java.lang.string.lastindexof(string.java:1817)     @ com.acunia.service.position.nmea.comm.commpositionprovider.isvalid(unknown source) 

the line causes exception is:

int csi = line.lastindexof("*"); 

i had @ openjdk string.java source, couldn't find fault unless arrays start changing size after created.

the reference online find might related openjdk bug: https://bugs.openjdk.java.net/browse/jdk-6817012. bug marked 'not issue' though, although when reading can't tell if problem mentioned not recognized bug, or if person closed bug doesn't see why bug cause problems.

if has ever encountered similar problem appreciate hearing it. stands problem unstable attempt fix using other versions of openjdk.

problem seen on:

hardware: custom arm platform java version "1.6.0_31" openjdk runtime environment (icedtea6 1.13.3) (6b31-1.13.3-1~deb7u1) openjdk 0 vm (build 23.25-b01, mixed mode) linux 3.2.0 #1 fri jun 20 10:25:16 cest 2014 armv7l gnu/linux 

this issue bytes , system charset. the documentation explicitly says:

the behavior of constructor when given bytes not valid in default charset unspecified.

you can circumvent explicitly providing correct charset:

new string(buffer, 70, 16, standardcharsets.utf_8)