Due to GenericRecord being checked before SpecificRecordBase,
GenericDatumWriter was used incorrectly for types that extend
SpecificRecordBase.
Resolves#3859
Both the PatternMatcher and JdbcParameterUtils use String.toCharArray for
processing. This will create a new char[] which needs to be collected. The
same code has been rewritten to use String.charAt to reduce the overhead.
Additionally unneeded object creation in the PatternMatcher has been removed
as well, to reduce further objects needed to be gc'ed.
StringBuilder by default has a size of 16, however there
are some places that already create larger strings already.
For efficiency and garbage reduction it would be better to have
larger sizes to begin with.
Guarded the logging statements which do concatenation of strings
or calling toString on objects. When a log level isn't enabled
this still would produce garbage that would need to be collected.
Guarded all logging up to info, warn and error can be assumed to be
enabled on a production system.
Currently when reading/writing JSON and using the reader/marshaller provided
and you want a custom Gson or ObjectMapper instance it still creates the not
needed instance. Move the construction to a constructor and provide a constructor
to directly pass in the pre-configured Gson or ObjectMapper instance.
The same approach is used in Spring itself where Gson or ObjectMapper instances
can be passed in.
This commit temporarily ignores tests that are failing
intermittently on Windows. A link to the corresponding
issue has been added to each test.
FTR, I tried to ignore those tests only on Windows by
using `Assume.assumeFalse(SystemUtils.IS_OS_WINDOWS);`
where `SystemUtils` is from `org.apache.commons.lang3`
but this assumption does not seem to work as expected.
The test `testCompareNewWithOldAfterCopy` does
not work on linux/unix unless a `Thread.sleep`
is added before the file copying (see cbcf28c3).
This test does not work on windows neither,
because it is based on apache commons
`FileUtils.copyFile` which does not honor
`preserveFileDate=false` on windows.
The following test works on linux/unix
but not on windows:
```
@Test
public void testLastModifiedAfterCopy() throws IOException {
File existing = new FileSystemResource(FILE_PATH).getFile();
File temp = new File("target/temp.txt");
assertFalse(temp.exists());
FileUtils.copyFile(existing, temp, false);
assertTrue(temp.lastModified() > existing.lastModified());
}
```
On windows, even though `preserveFileDate=false`,
the last modification date of the copy is equal
(ie preserved) to the one of the original file,
which is not the case on linux/unix. Trying to
use an alternative like `java.nio.file.Files#copy`
does not work since it only offers the ability
to either copy file attributes or replace the
existing file (which is not the idea of this test).
This test does not add any value and should have
been removed since a long time (see TODO in 12d6613).
Before this commit, tests in this change set
were failing on MS Windows due to the file
comparison method which was based on file
content hash comparison. With this method,
differences between OS line endings
(LF vs CRLF) in generated json files produce
different hashes.
This commit uses a logical json comparison
based on the jsonassert library.
This test fails on Java 15 because the Javascript engine
has been removed in Java 15 (JEP 372).
This commit updates the test to assume that the JavaScript
engine is provided to the JVM through a factory (similar
to other tests).
This commit updates the configuration to run unit tests
with maven-surefire-plugin and integration tests with
maven-failsafe-plugin. JSR-352 TCK tests are considered
as integration tests and are executed with other integration
tests (no need for a separate profile to run them).
Some unit tests were failing when integration tests were
skipped.. Those tests have been temporarily ignored.
* Corrects unit tests with expected behavior.
* Creates integration tests highlighting Hibernate lazy-loading failure if the reader has requested the page on open().
Issue #1074
Tests in this class fail intermittently because
they send messages to Kafka in an asynchronous
way and assert on the results immediately without
waiting for the send operation to complete.
This commit updates the tests to wait for
send results before asserting on them
(similar to a140a9f5).
