Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different newlines on Windows #6

Open
prdoyle opened this issue Dec 27, 2021 · 2 comments · May be fixed by #10
Open

Different newlines on Windows #6

prdoyle opened this issue Dec 27, 2021 · 2 comments · May be fixed by #10

Comments

@prdoyle
Copy link
Contributor

prdoyle commented Dec 27, 2021

Summary

WIndows has trouble with newlines and I'm not sure how you want to proceed.

Failure

When I run JfrSchemaFactoryTest.canRunSimpleSelectFromClassLoad on Windows, it fails on column 2 because the newlines are different:

assertThat(rs.getString(2)).isEqualTo("""
        {
          classLoader = null
          name = "java/lang/Throwable"
          package = {
            name = "java/lang"
            module = {
              name = "java.base"
              version = "17"
              location = "jrt:/java.base"
              classLoader = null
            }
            exported = true
          }
          modifiers = 33
          hidden = false
        }
        """);

Cause

JfrSchema.getConverter is using the following converter:

else if (field.getTypeName().equals("java.lang.Class")) {
    LOGGER.log(INFO, "| -> java.lang.Class");
    return event -> event.getClass(field.getName());
}

I believe when the testcase calls rs.getString(), this is calling RecordedClass.toString() which ultimately uses StructuredWriter.lineSeparator which is initialized to String.format("%n"), and this differs by platform.

Possible solutions

Should we return the java.lang.Class in this case, rather than the RecordedClass object? The Class.toString() method should produce the same result on all platforms.

@prdoyle
Copy link
Contributor Author

prdoyle commented Dec 27, 2021

I suppose we can't necessarily get the java.lang.Class because we're running in a different JVM that might not have that class loaded.

I wonder what's the best way to deal with toString() variations across platforms, given how eager ResultSet is to call it. 🤔

@prdoyle prdoyle linked a pull request Dec 27, 2021 that will close this issue
@prdoyle
Copy link
Contributor Author

prdoyle commented Dec 27, 2021

I can't really find a clean way to handle this.

Facts:

  1. We want our result set to contain a RecordedClass
  2. ResultSet.getString calls toString
  3. RecordedClass.toString is different on different platforms
  4. We want the same behaviour on all platforms

One of these has to give. I hope it's 2 or 3 but I'm afraid it might have to be 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant