> > I would think that this would show up in nightly builds. I guess I could > try older versions, or I'll keep tracking it down to the cause.
I think by default most machines have a default timezone set to UTC, so it might not. On Fri, Mar 12, 2021 at 7:53 AM bobtins <bobti...@gmail.com> wrote: > > > On 2021/03/12 04:09:21, Micah Kornfield <emkornfi...@gmail.com> wrote: > > > > * Build does require Java 8, not "8 or later" as stated in java/README.md > > > There's a reference to sun.misc.Unsafe > > > in > memory/memory-core/src/main/java/org/apache/arrow/memory/util/MemoryUtil.java > > > which of course went away in JDK 9. > > > > Is this the case even using "-Dio.netty.tryReflectionSetAccessible=true" > as > > mentioned in the README? > > > OK, now I can't duplicate the compile-time issue; now if I point it at JDK > 11 it gets a warning, but previously it was actually unable to resolve > "sun.misc.Unsafe" and got a compile time error; I'm not sure why it > happened before and doesn't now, so I'll move on. > > > > * The build won't work on Windows because the java/format POM downloads a > > > binary flatc executable, but there's no artifact for Windows, just > Linux > > > and OSX. I wound up downloading Visual Studio and building the > flatbuffers > > > project. > > > > This unfortunately sounds familiar, I think this indicate the popularity > on > > windows. I also think the hosting of the mac and linux are not exactly > > official (they are hosted by a former contributor). Updating the Readme > > might be a good first step with instructions on how to do this. > > > As far as providing instructions on building the flatbuffers project on > Windows, I'm not an expert at all with the Microsoft ecosystem, but I could > provide a summary. > > > I see in the pom.xml that user.timezone is set to UTC. I have seen these > > > types of errors in tests before; I know there are ways to insulate the > test > > > from the user's current timezone but maybe someone knows what's going > on > > > > This is somewhat surprising. I would thought we had the user.timezone > set > > for exactly this reason. There might have been a regression, this might > > make a good second contribution if you wanted to look into fixing it. > > ; > I would think that this would show up in nightly builds. I guess I could > try older versions, or I'll keep tracking it down to the cause. > > > * I bumped into what looks like a spurious checkstyle error: it reports > > > memory/src/test/java/io/netty/buffer/TestExpandableByteBuf.java having > no > > > linefeed at the end when it definitely does. I set up Git not to do > Windows > > > conversions, and I checked with various editors and binary dump > utilities. > > > One source says that this because I'm running on Windows, checkstyle > > > actually expects a CR-LF and throws an error if it doesn't find it! > I've > > > worked around this by disabling the check. > > > > It looks like we can force the checker to assume linux line feeds: > > > https://stackoverflow.com/questions/997021/how-to-get-rid-of-checkstyle-message-file-does-not-end-with-a-newline > > (second answer). This would also make a good contribution for someone > new. > > > Sure! > > > > > >
