Better approach for CompactNumberFormat in QuantityFormat

[keilw]

After support and proper handling of the new CompactNumberFormat in Java 12 was added by #251 the idea was to control how that NumberFormat is created and made part of a NumberDelimiterQuantityFormat, but limitations of the Java spec (as discussed in #346) would not allow creating an instance via getCompactInstance(FormatBehavior, NumberFormat.Style) which it ideally should because that method signature won't work before Java 12. That makes getCompactInstance(FormatBehavior) pretty useless because it is merely a convenience wrapper for one of at least two format style cases. And instead a call to either

NumberDelimiterQuantityFormat.Builder()
            .setNumberFormat(NumberFormat.getCompactNumberInstance(Locale.ROOT, NumberFormat.Style.SHORT))
            .setUnitFormat(SimpleUnitFormat.getInstance()).build();

or

NumberDelimiterQuantityFormat.Builder()
            .setNumberFormat(NumberFormat.getCompactNumberInstance(Locale.ROOT, NumberFormat.Style.LONG))
            .setUnitFormat(SimpleUnitFormat.getInstance()).build();

shold be made explicitly.

We likely need the special Java 12 version of NumberDelimiterQuantityFormat to handle CompactNumberFormat differently if required, but all the factory methods especially those specific to Java 12 and above could be eliminated that way.

[keilw]

@andi-huber, @desruisseaux What do you think about this and could either of you also help or are you too busy with other tasks?

[desruisseaux]

Hello Werner. I will not be able to contribute in the foreseeable future. I have done many promises on SIS and other projects that I have not been able to fulfil yet…

[keilw]

Martin, No worries, I think this is small enough to even do it on my own if nobody else had enough resources. And it would solve the "signature concerns" (as tiny and insignificant as they actually are, because most people may not even know what CompactNumberFormat is or use it ;-) without introducing that "stub" method for lower Java versions.

[andi-huber]

Hi Werner, not my field of interest, sorry.

[keilw]

Andi, no worries, then I'd look into it. I know you are more into "Arithmetics" and your contributions (currently the second-most in this repo) are highly appreciated, so no problem leaving that to others. We learned especially from that other ticket #346 it's often better not to put one's oar in (German: "seinen Senf dazugeben") everywhere ;-)

[andi-huber]

Well quite frankly - regarding the elephant in the room (346) - I have a different perspective. I don't mind a technical discourse, where participants have an opportunity to bring their ideas and then let the better argument win. But to watch this tendency towards insults on a personal level is painful, exhausting and is something I don't want to be associated with. I am here for the fun of it and to learn a few things.

[keilw]

I did not insult him, and the guy who raised the ticket also wrote the kind of stuff quoted which may be you learn in books or interview questions by the likes of Google, but in reality even the JDK itself does not apply. "foot-soldier" is what people supporting customers have to do in the "trenches" just like people in WWI... I was a Developer Relationship "something" just like @nipafx is now. And even if our project may not pay a Million Euros or Pounds to Oracle we still deserve a polite answer (even if it would be "I don't know, but I could ask someone") and not this shabby "Go do yourself" he gave me. Only to have his boss or whatever the "Line of Duty" might be answer it after it may have been escalated to the right level of responsibility. The real insults happen by bad actors who place their malware, ransomware etc. in the mailing lists, mostly at Eclipse (ours at units-users or units-dev may not seem attractive enough but I also got some strange requests on the JSR 354 mailing lists that might be from a front company for some fraud or cybercrime because after asking him about a missing link on their page or something I never heard from him since) and Jakarta EE. One almost could have thought @anthonyvdotbe to have similarly sinister goals, but it seems he's more harmless than those willfully placing malware or phishing links into what they mimick as Jakarta challenges, tutorials or quizzes. He made a single contribution to Jakarta REST but all of it looks like fixing typos in Asciidoc, not an actual piece of code. So a "tech writer" but not an actual coder, otherwise you would also see more like the 2k annual committs you got or I do and almost everyone else and not 59 ;-) Former SUN CEO Scott Mc Neally once spoke about the "shirts" (as in T-shirts) vs. the "suits", but nowadays almost everyone is wearing T-Shirts except maybe the lawyers. Or famous turtleneck posterboy (before Wirecard Braun) Steve Jobs who once called Facebook "Fecebook".😂🤣 Ok Martin also does not push so regularly on GitHub, but he commits a lot to Apache SIS and I don't think the mirrors always reflect the original authors on GH, at least I cannot say for sure. Obviously just mechanically throwing out some ticket without proper preoccupation with the matter (e.g. having read the spec etc.) is not helpful and leads to tickets like the mentioned one. There are Github bots around here doing a better job.🤖

And you know actually the JCP EC should have told us there was this method signature issue when they did the review before voting on MR1. #251 is older than the MR1 which was after 2.1, but I know even when I was in the EC or @dautelle, the majority of members care about politics or IP rights and licenses and almost none of them ever look at the code. Some did in the "old days" when we filed JSR 275 but after the whole rolling JSR and "rubber-stamping" of Java SE JSRs with almost no real review that also happens to most of the other JSRs especially when there's a MR and not a new JSR.😇

[keilw]

Anyway time to solve some real problems like: https://github.com/unitsofmeasurement/unit-api/issues/230 It involves older versions especially of Indriya, so it's worth to check if known issues (including the calculation engines) may be responsible or if it's also about parsing and rendering only?

[keilw]

Btw @andi-huber how did the work with GeoTools go? You will recall they also had a bit of an unfriendly tone towards us and especially @desruisseaux even more than myself, and that was based on his description mostly because he and SIS "dared to create another implementation". So you sometimes get these kinds of things and if you spent anough time in the JCP EC like @dautelle and I did, you learn even more of those things and people like Rod Johnson calling the EC the "political commissars" like those in Communist countries only to be invited by Oracle or I think it was still Sun at the time into that very same EC in a ratified seat. He just showed up at one F2F for about 15 minutes or so. 10 out of that I had a conversation with him, then his phone rang and he left without ever being seen again. Leading to the "Lex Johnson" in the JCP about participation. Something we also consider in the Jakarta EE WG because especially the representatives of LJC were notoriously absent from Spec Committee calls (either because they wear "too many hats" including the JCP EC one or because their new bosses at Microsoft are at their neck with corporate projects?) @dautelle was also the only Individual to ever host a JCP EC meeting in his home the famous "Boston Barn Meeting" where I believe the whole Apache Harmony dispute started or escalated. Maybe if he has time he could tell you more about that and if you are still based in Vienna after the lockdown, maybe we could have a coffee or beer some day and if he's not too busy with actual politics we could also try to include @struberg to tell you even more about Oracle, the JDK or Jigsaw.😉

[desruisseaux]

I do not think that GeoTools peoples are unfriendly in general. The friction between myself and some other core members had a longer history that started before we decided to continue our developments outside. It is an history of different priorities, code review not properly done, commercial interests causing pressure, etc. Those things happen, it just get more intense when we invested a lot in a project.

On latest discussions, I think that authority arguments should be avoided because they create frustrations, because they usually come from a different context not necessarily applicable to the discussion. Instead if a technical argument got no answer or if the answer suggests that there is a misunderstanding, I suggest to divide the technical argument into simpler arguments until we reach a common understanding.

[keilw]

What is that whole "authority" thing? At least in the JCP EC or Jakarta Spec Committee I was or am elected to a higher "authority" and that I pointed out myself and others were confronted with say JPMS or every Java SE Spec since Java 7. I cannot undo that and I had to witness and even help moderate (with my EC "hat") sometimes much more hostile and foul-mouthed arguments between e.g. the OSGi people and OpenJDK/JPMS team or between JSRs like @Inject (especially Bob Lee who got the name "Crazy Bob" for a reason) and the first version of CDI. As JCP EC Member at the time I was also asked by some EU Antitrust Commissioner (currently Margrethe Vestager but it was someone before her) about the Oracle Sun merger, so yes, the almost 10 years in the EC got me into a role with a slightly higher "authority" than most of those involved in that discussion. So was @dautelle some years ago but he decided to only run for one term. Some at Oracle also had the authority and duty to testify in front of the SCOTUS for sure, but I doubt any of those involved in this discussion had to or were asked to.

[desruisseaux]

The word "authority" was not refering to anyone in particular. "Authority argument" is a generic name for a particular kind of argument. When a discussion uses the opinion of an authority on a topic as evidence to support an argument, this is called "authority argument". The authority is not necessarily any of the peoples participating directly to the discussion.

[keilw]

Ok but either way I or @dautelle cannot change that we had "multiple hats" including those on the "other side" (than a Spec lead or EG member) of almost every spec including the Java SE ones between 2007 and late 2017, thus having seen and reviewed those specs long before others like @nipafx were involved was naturally part of our duties. And as mentioned here before, I won't remind them explicitly because they have many other things to do (especially on the Jakarta EE side) but if the JCP EC had the same attitude and eagerness it had around 10 years ago, THEY would have told us that a class likely violated the spec because they keep reviewing and approving all those specs on a regular basis, but many of them do not care as much about the technical aspect as others including myself did. I pretty much made all my votes based on technical arguments even if I was the only one abstaining or voting "No" sometimes, other cases like that JPMS vote saw a majority against it, similar to what we had with JSR 275 although for a combination of different reasons as you may remember.

I wold also say, in an ideal world we as the EC also should have asked the JSR 376 Spec Lead (Mark Reinhold) for less ambiguity in the wording but there were more critical things to sort out that did not work before the Reconsideration Ballot and we got him to archieve that. A "No vote" stopping the JSR or Java 9 could have caused Oracle to stop the JCP altogether because of losing its face there (similar to trying to ratify some completely unexperienced and unknown company to the EC which all the members also voted down) so it was a compromise we had to make. Looking at bugs like JDK-8235229 I must say we as the EC then (including myself) could have done a better job and tried to pressure Mark to take some things of their plate (because of bugs they could not even fix until Java 16 that were first introduced in Java 9!!) but that was not in our hand alone and even less in mine, so I am sorry for that but we could not really force them to do a more cautious feature planning then either.

I don't see @nipafx unblocked yet but I guess those 3 days might be over soon.

[keilw]

I also created the page for UCAR and JSR 108: http://unitsofmeasurement.github.io/2021/20yearsjavaxunits.html A little late, but it also anticipates a possible implementation by NetCDF. @desruisseaux Is there any development there or prospect it might happen? Unless the reasonably constructive discussion about toolchains for MP-JARs also used in Glassfish https://github.com/eclipse-ee4j/jakartaee-platform/issues/329#issuecomment-840524012 brings a much better alternative to the toolchain plugin used here, I don't see how we could or should change that (as #348 suggested) but for any implementation including Indriya itself, Seshat (2.x) or maybe a future NetCDF one we may well add signature checks or other verifications to the TCK.

[desruisseaux]

I'm not aware of work regarding javax.measure implementation by UCAR. I think this is a "nice to have" feature for them, but with no short term plan yet. They seem busy with a major upgrade of the netCDF library for now.

[keilw]

Never mind, if they get there nice, otherwise no problem either. Closing this, because all the methods are removed in favor of the described approach in java12/QuantityFormatDemo. As #301 explained the JDK bug we helped workaround when fixing it, the separate demos are also not required anymore.