Bug in Utils.tryWith

Chris Newland cnewland at chrisnewland.com
Thu May 28 07:00:48 UTC 2015


Hi Aleksey, Aleksandr,

I've been looking at GPL-compliant ways to provide hsdis binaries as part
of JITWatch and got a positive reply on the adoption-discuss ML:
http://mail.openjdk.java.net/pipermail/adoption-discuss/2015-May/000835.html

If that is correct then it would only need Oracle to modify the license on
the 2 small files that form the wrapper around binutils.

Regards,

Chris
@chriswhocodes

On Wed, May 27, 2015 17:46, Aleksey Shipilev wrote:
> Hi,
>
>
> On 27.05.2015 17:31, Aleksandr Dubinsky wrote:
>
>> With all due respect to your hard work and achievement, I hope you
>> realize you're coming across as a bit unfriendly to your users.
>
> Observation #1: No matter how much time you spend improving your
> product, there are always be users who take the all past UX work for
> granted, and see the refusal to make just a tiny additional step an
> "evidence" of being unfriendly to users.
>
>
> Observation #2: Confusing the unfriendliness and the absence of
> enthusiasm for spending considerable time implementing the suggestions is a
> good way to alienate the developers. OSS work is granted you gratis, the
> implementation work for your suggestions is courtesy, not privilege.
>
> This is an open source and free software project. If you want to
> contribute, please consider contributing the actual fixes, and going for
> the review process to get your changes accepted. If you don't have time to
> make the code contribution, verbal suggestions are fine too, but they come
> with much less chance of being acted upon. In any case, please be
> open-minded about maintainers reframing and/or rejecting the
> contributions.
>
> Maintainers also have 8 hours workdays, and not every work hour is
> destined to be spent on projects they love. Therefore, we need to draw a
> line in a sand somewhere. My reply was on-the-record response on how to
> fix the actual issues, instead of doing band-aid and/or misplaced fixes.
>
> I admit, PrintAssembly reply was written hastily, let me try again:
>
>
>> Being woefully mistaken about "any hassle with building the actual
>> hsdis can be resolved with a tiny bit of following up" is not friendly.
>> (Have
>> you tried following any of the several bits of advice on building hsdis?
>>  Sure, there's lots of instructions. The trouble is none of them work.
>> I
>> wasted a whole day. The killer is you need experience in native
>> development on Linux to make sense of and fix the errors.)
>
> Oh yes, I did build hsdis on most platforms, and yes, it is a PITA. I
> also understand the license tainting, and so have sympathy for those who
> refrain to put the binaries out, despite others calling them "copyright
> nazis".
>
> That said, what's relevant is that if there is a deficiency in
> PrintAssembly build instructions in the authoritative source [1], you
> have to address it there. StackOverflow is *not* an authoritative source,
> unless something is being answered by the person in charge. Internet, as
> the rule, is always full of outdated "suggestions". I think those
> suggestions were actually backed with a good will like yours, but they
> were finally abandoned there to rot.
>
>
>> I'll do my part by participating in StackOverflow to catch whatever
>> falls through the cracks in the documentation.
>
> Advising on corner cases and dispelling the misunderstandings is a good
> fit for SO. But providing the extended documentation on SO is IMO a
> dangerous practice. These should be addressed close to source. For
> example, there is a comments section at [1] that can be used to provide
> corrections and updates to the page. You can even look up the page history
> and identify those who can make an actual change.
>
> Aside: If something is claimed to be undocumented, spelling out the
> current implementation behavior on SO does not make it "documented". It
> just messes up the whole idea of providing the projects with the
> customization knobs that can be changed without thinking about the
> compatibility, extended testing, doc syncups, release notes, etc.
> Documenting the undocumented, you are trapping maintainers in
> "non-documented, but widely used" vortex.
>
>
> Also, dispersing the docs on uncontrolled forums makes the documentation
> mistakes proliferate even when fixed in the product documentation. For
> example, I see people almost blindly copy-pasting JMH Samples as the "JMH
> introductions", but that makes almost a disservice to prospective users
> since we cannot rephrase the samples for better flow and
> understandability. And then you are facing users educated on outdated
> docs...
>
> Thanks,
> -Aleksey
>
>
> [1] https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
>
>
> P.S:
>
>
>>> On 26.05.2015 09:34, Aleksey Shipilev wrote:
>>> The only UX improvement we can do is to make profilers accept these
>>> options through regular means, e.g. -prof perfasm:events=cycles,insns;
>>>  which will allow, among other things, using -prof perfasm:help.
>
> I was actually meddling with "profiler options" dance, so that something
> like -prof perfasm:help would be available with option descriptions.
> Instead of doing the coding work there, I spent time replying to the
> inflammatory thread. Hey Aleksey, that was silly of you, eh?
>
>




More information about the jmh-dev mailing list