Make JDK source code UTF-8

Re:Make JDK source code UTF-8 by geokon on Wednesday March 01, 2023 @07:11AM (#34981462)

thanks. Interesting examples - and thanks for actually finding in-code examples :)

I didn't realize OpenJDK targets systems without filesystems. Having a requirement that all tests have to be inline seems very onerous and a bit limiting. Do they do this with image manipulation libraries as well?

I can see how an external file makes it a bit more of an "integration test" that would in effect be testing several moving pieces. I don't agree it would create more boiler plate or make things any less clear though. It makes it much easier to test many different complex and large inputs and to feed in new tests without needing to recompile. It's also easy to version control and introduce new tests with pathological cases. It presents a clear separation of test inputs from code - but maybe I can understand the counterargument. It does look neater to have everything together

[ Parent | on HN ]

Re:Make JDK source code UTF-8 by xmcqdpt2 on Wednesday March 01, 2023 @07:52AM (#34981804)

Yeah the resources feature in Java

https://www.jetbrains.com/help/idea/resource-files.html

makes it easy to embed arbitrary data with your code (or in this case, your tests, which are usually compiled separately) so no, you can easily test against files without access to a filesystem (beyond the access required to read the jars).

I still think having test cases with strings in the code is often a lot clearer personally.

(Unrelated: I wish more PLs made it easy to embed files within executables and access them with an OS-independent filesystem like API, it's often very useful.)

[ Parent | on HN ]

Re:Make JDK source code UTF-8 by MaulingMonkey on Wednesday March 01, 2023 @02:13PM (#34986883)

> I didn't realize OpenJDK targets systems without filesystems.

To be fair I'm not sure it does, really, per se. I know embedded Java is/was a thing, though, and it wouldn't suprise me if someone somewhere tortured their own personal fork into running a test suite on embedded stuff - if only for legacy support testing purpouses.

And poking around in that directory did make it clear some tests use files containing test vectors.

> I don't agree it would create more boiler plate

To get concrete again, I consider this boilerplate:

https://github.com/openjdk/jdk/blob/9fc518ff8cadbbb731a016d8...

And this is merely (de)serializing pure unstructured strings without any kind of data format or failiable schema beyond charset encoding, making this a poster child for exiling test data to files (probably part of the reason why it was exiled to files!)

> It makes it much easier to test many different complex and large inputs and to feed in new tests without needing to recompile.

For bulk plain text I'd agree. For codebases with slow incremental builds, structured data might also benefit from being exiled for iteration speed. Or there can be benefits to skipping having a full developer environment.

But if incremental builds are fast (a worth goal), and if full developer environment is reasonably assumed (dev-focused unit/integration testing), compiler assistance with structured data is often more convenient, and has better error reporting for syntax errors etc. than what you'll get from many/most simple and straightforward uses of deserializers.

[ Parent | on HN ]