Yes, everything changes with java8; they finally got it right-er :) But the usages I've been looking at don't leak into public scope.
I have mostly been looking at the two "Utils" classes, which both have private usage. I'll patch any non-public usage and see how far that goes. Kristian 2014-12-01 14:44 GMT+01:00 Andy Seaborne <[email protected]>: > On 01/12/14 13:17, Kristian Rosenvold wrote: >> >> I'd be interested in patching jena to use the thread-safe >> FastDateFormat of commons-lang3 3.3.2 (or 2.6). The current use of the >> non-threadsafe SimpleDateFormat class is a bit of a performance slob, >> and >> FastDateFormat is designed as direct replacment. >> >> This would add commons-lang3 as a dependency some new places. Is is >> worth spending my time on this ? >> >> Kristian >> > > Sounds great. > > commons-lang3 is already a recursive dependency (via thrift) and gets > shipped in the distribution binaries so it's just a matter of adding it > explicitly to jena-parent for version and jena-core for the dependency. > > [INFO] org.apache.jena:jena-arq:jar:2.12.2-SNAPSHOT > [INFO] +- org.apache.thrift:libthrift:jar:0.9.1:compile > [INFO] | \- org.apache.commons:commons-lang3:jar:3.1:compile > > > I grepped for SimpleDataTime in some of the main modules and found > > RequestLog.java > jena-fuseki2/src/main/java/org/apache/jena/fuseki/server > > schemagen.java > jena-core/src/main/java/jena > > StringUtils.java > jena-arq/src/main/java/com/hp/hpl/jena/sparql/util > > Utils.java > jena-arq/src/main/java/com/hp/hpl/jena/sparql/util > > > > The speed ups due to special integer to StringBuffer is not new - > DateTimeStruct does similar. At the time I thought it was a local issue, > maybe not. > > Does this change at Java8 and DateTimeFormatter? I haven't tried that at > all. (This is isn't a reason to not do it - it may be a reason to hide > things behind local libraries) > > Andy > >
