Bug in Utils.tryWith

[Aleksey Shipilev]

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?