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!
>
>
