RFA: libjava seems to miss some files for win32

[Dave Korn]

Kai Tietz wrote:
> 2009/7/19 Dave Korn <dave.korn.cygwin@googlemail.com>:
>> Kai Tietz wrote:
>>
>>> There are a lot of issues about casting HANDLE values into jint types,
>>> which is for x86 valid, but for x64 can lead potential to pointer
>>> truncations. Those part need some review by libjava maintainers. My
>>> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into
>>> integer scalar before casting it into jint. I put comments at those
>>> places, where some rework is necessary.
>>  Argh.  You're replacing a bunch of warnings that draw attention to a real
>> problem by a bunch of silent fixmes in the code.  That's a bit scary to me.
> 
> Right, therefore those comments are for. But otherwise I couldn't get
> it build, as those kind of failures are treated as errors (what is in
> fact a good thing).

  Yes, so since they are a good thing, you should *not* get rid of them.  It
is better for it not to build than for it to silently build bad code.  If you
want it to work, you should make it *actually* work, otherwise just add it to
noconfigdirs until such time as you can make it work.  There is not only no
point successfully building a broken library, there is _less_ than no point.

  Whenever adding fixmes, you must plan on there being a very great likelihood
of them getting forgotten and never fixed.  Rule #1 of maintenance-friendly
coding.

>>  Question is, can we change the sizes of the members of class objects, such
>> as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their
>> layout form part of an ABI, and/or do they ever get serialised?  The Java guys
>> will be able to tell us.

> This was the reason, why I didn't changed api here. The final patch I
> see here done by the java team, as I have no real idea, if those types
> and members are part of abi, here. If it is there are ways to solve
> this (e.g. making abstract handle values for OS handles as example).
> So it is for sure necessary that a java maintainer takes action here.

  I fail to see the value of building a broken libjava for w64.  It's not a
step you need to get past on the roadmap to making a working java for w64.
Just don't build it at all.  --disable-libjava or $noconfigdirs.

  Alternatively, wait a few hours until the java guys have a chance to
respond.  Maybe we can just change the datatypes, after all.  But I really
can't see any use and only harm in adding a silently broken implementation.

    cheers,
      DaveK