Blackcap Blog

Published at 09:17 on 14 June 2025

There has been a lot of hand-wringing recently from many on the anti-Trump side of how the recent protests against ICE are doomed to be a disaster because they are not perfectly adhering to the ideals set forth by those wringing their hands.

Look, this is a stupid basis on how to judge things. No set of protests of any size and consequence is ever going to strictly adhere to any one individual’s pet set of standards for political protest. It’s just not going to happen.

This sort of unrealistically high standard is almost uniquely applied at home and nowhere else. Look at any other authoritarian country where open opposition emerges, and you will find incidents of, at the least, property destruction and retaliation in kind against police violence. Of course, the narrative is never about the property destruction or retaliation then. In fact, that stuff usually gets papered over in the mass media. But it’s fairly easy to find the images of burning vehicles and protesters throwing rocks at police if you look for them.

Almost never is there the “oh, dear, the protester’s tactics are going to alienate people from their cause” take for such protests abroad. Rather, the sign that protests are emerging at all is seen as a positive sign that the regime’s spell over its populace is breaking.

And yes, at this point, the USA is best understood as some form of a soft authoritarian regime. It’s really the only honest way to characterize a society where masked secret police go around disappearing people, with (up until the last week or so) very little resistance from the populace.

No, that doesn’t mean that optics are unimportant, or that there are not big issues on the American Left. I have written before on how much the American Left is an inward-looking subculture and of the necessity of any protest movement to break out of that subculture.

But that latter point cuts both ways. There is also a need for any protest movement to break out of the control of the Democratic Party and its allies. That crowd is so stunningly incompetent at the whole politics game that any leadership role on their part probably dooms opposition to ineffectiveness. What we don’t want is protests that can be turned on and off at the whims of the Democratic Party. We need the heat to stay turned up on Washington even after Trump is, one way or another, removed from office. The Democrats did very little to fight fascism under Biden and there is exactly zero reason to assume they will, absent a lot of pressure from below, do much about it again if they ever manage to regain power.

And this leads me to the really worrying thing about the planned No Kings protests. From what I have been able to determine, it’s all being run by a centralized leadership that is, in fact, closely linked to the Democratic Party.

We still have yet to see any sort of broad none-of-the-above movement emerge. This limits my optimism, although it is also true that in this sort of situation, any protests almost always beat no protests. So I am more optimistic than I was a month ago, but it will take significant changes in the nature of the opposition to Trump to raise that optimism to a truly significant level.

Published at 10:31 on 13 June 2025

The time and date situation. Specifically, the new “improved” one.

Yeah, I get it. The old one is full of deprecated legacy cruft calls. Its fundamental time type is mutable (which is undesirable when writing multithreaded code). Plus it has an absolutely horrible name: Date refers to an object that holds the number of milliseconds since the UNIX time epoch.

On that latter point, I have no idea why the early Java dev team chose such a lousy name. They really had no excuse. About eight years prior, the Posix team chose time_t for their analogous data type. That had only one-second resolution so they later came up with a struct timeval with microsecond resolutions. Both are fundamentally reasonable name choices. Calling a time a time makes just so much more sense than calling a time a date. Just goes to show how long the brain rot has been prevalent in the Java world.

Speaking of that brain rot, Baeldung is one of the go-to sources for information in the Java world and their article on the new time and date API is a total hoot. It’s just one whopper after another. Let’s pick out a few of them, shall we?

Working with dates in Java used to be hard.

No, it didn’t. Not really, once you got over the weird naming convention of calling a time a date, and the fact that there were two classes for formatting a time. Because of course there were. This is Java, and we can’t do anything right. Got to write one weak, lame API and then a second one (also limited) to make up for the weakness and lameness of the first.

These were only suitable for the most basic tasks.

Bullshit, they were suitable for virtually every routine task. Only a tiny percentage of programs delved into the minutiae of dates, times, time zones, and calendars enough for the standard library to be insufficient, and that was not reason enough to clutter up that standard library with support for rarely-needed edge cases. It’s a reason for a third-party library of extended, specialized time and date functions to exist.

A first advantage of the new API is clarity…

Bwahahahahahahahahaha! This whopper is so bad I could write several paragraphs about just how much of a whopper it is.

And now I shall write those paragraphs.

The new library has no fewer than nine absolute and two relative time classes. No, I am not making this up. They all differ in various subtle ways from each other, ways that will require one to spend no small amount of time reading documentation to figure it all out. And figure it all out you must, or your code will throw fatal exceptions and fail to run if you use the wrong class in the wrong place. This is apparently what Java-heads consider “clarity,” and feel so strongly that it is such that they set the term in boldface.

And that’s just times. Then there’s time zones. There are two time zone classes, again because of course they are. (Making three types of time zone in total once you add the legacy one which is still around. Oh, wait, I also forgot that there are now time zone ID objects, which differ from actual time zones in various subtle ways.) The two new zone types also differ in various subtle ways, and you have to study the documentation a while to understand these differences, too.

The most common uses by far for a time object are to create it and to print it. Manipulations are so far down on the list that they can be disregarded for purposes of discussing the most common uses. Let’s print the date in the preferred format for the current locale. For the old Date option, it is relatively simple:

Date now = new Date();
DateFormat formatter = DateFormat.getDateTimeInstance();
System.out.println(formatter.format(now));

After a lot of reading, eventually one figures out that the Instant (you might think they would call it Time or TimeStamp, but apparently some types just never learn, sigh) class is the closest analogue to the old Date class, and the new formatting class is DateTimeFormatter. Great!

Instant now = new Instant();
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime();
System.out.println(formatter.format(now));

But that won’t even compile. Turns out you can’t construct an Instant, the constructor is now private. You must call the now static method:

Instant now = Instant.now();
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime();
System.out.println(formatter.format(now));

Nope, still lose. Turns out formatting has been dumbed down. Formatters are now too stupid to come up with a preferred default style. You must tell it the style. To do that, you have to learn about (and introduce) an extra style-specifying class.

Instant now = Instant.now();
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG);
System.out.println(formatter.format(now));

Yay! It compiles! Uh oh, it throws a weird exception when running.

Exception in thread "main" java.time.temporal.UnsupportedTemporalTypeException: Unsupported field: MonthOfYear
	at java.base/java.time.Instant.getLong(Instant.java:604)
	at java.base/java.time.format.DateTimePrintContext$1.getLong(DateTimePrintContext.java:205)
	at java.base/java.time.format.DateTimePrintContext.getValue(DateTimePrintContext.java:308)
	at java.base/java.time.format.DateTimeFormatterBuilder$TextPrinterParser.format(DateTimeFormatterBuilder.java:3363)
	at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2402)
	at java.base/java.time.format.DateTimeFormatterBuilder$LocalizedPrinterParser.format(DateTimeFormatterBuilder.java:4848)
	...

Now you get the fun of delving into the Temporal interface and temporal accessors. Which it turns out doesn’t even help. The problem is not even there, it is someplace else. It turns out that the new formatter will accept arguments it is incapable of processing. There are nine date/time objects, remember? Which ones work at which times is a complicated set of rules. So not so fast! You have to take on the cognitive load of understanding all that too.

Eventually you hit on it. Time zones used to be part of formatting. Makes sense, right? A point in time is a point in time. What the clock shows for that point in time depends on your local time zone. But that’s too simple and logical for Java, so we’ve fixed it for you. Some edge cases might want to store times together with time zones. It’s easy enough to do that on one’s own (just define a class containing a time and a zone), but hey, let’s shove complexity at the programmer and support that edge case. It’s the Java way. Might as well support the notion of a time of day discombobulated from any notion of a zone, too, just in case someone might want that. As well as a whole batch of other possibilities. And since we want to format those objects, too, we can’t have a zone in the formatter. It must be in the time object itself. So we are passing the wrong sort of time object if we want to print out a local time with a zone.

After more studying yet, you finally determine that the one time of day class out of nine which we need is ZonedDateTime. Of course, Java being Java, you can’t just call the ZonedDateTime constructor with the Instant you wish to print. The constructor is again private and you must call a static method. And to top it all off, that static method is too stupid to have any notion of a default local time zone so you must fetch and furnish that as well. And at long last, you have arrived at the code to do what you want:

Instant now = Instant.now();
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG);
ZonedDateTime printable = ZonedDateTime.ofInstant(now, ZoneId.systemDefault());
System.out.println(formatter.format(printable));

Of course, most programmers never get that far. The ones whose eyes don’t glaze over after learning there are nine different time types (they’re in a hurry and don’t have time for this lunacy), are probably going to give up when they run into the UnsupportedTemporalTypeException getting thrown on them. Again, they just don’t have time for this crap. The boss is wondering when the new feature that sales promised the important new customer will be ready. Trusty old Date works just fine, doesn’t spring weird surprises on them, and isn’t even officially deprecated (and probably won’t be for a good long time).

And then you have hardcore Java-heads expressing frustration and mystification as to why so many programmers are continuing to use the legacy API. Gee, I dunno why that might be. It’s just a mystery.

And the problem is, it’s like this all over the place in Java. Gratuitous complexity everywhere. Code in Java, and the cognitive load you must contend with is at least an order of magnitude greater than it needs to be, if reasonable and sane software design prevailed in the Java world.

Published at 21:12 on 7 June 2025

The robots are back, and crawling the hell out of my Mercurial repository that really can’t take that sort of rate of access. So this site has been more down than up recently.

robots.txt has been adjusted accordingly, but the offending robots are apparently working on cached data and still making banned requests. So I have temporarily turned Web access to the repository off. The requests continue, but now they get relatively cheap 404 responses involving only Apache, instead of having to fork and exec a Python CGI script to process each request, so they are no longer doing much harm.

When the robots stop trying to access that CGI script (probably in a day or so), I will re-enable Web access.

Published at 16:15 on 7 June 2025

Nice Liberals might fret about stories like this, but I see them as signs of hope. At long last, grassroots resistance to Trump seems to be emerging on the streets, and hopefully in time for Trump to have a long, hot summer.

Because, yes, unrest can involve excesses, but so far, these are not happening. A little graffiti and blocked traffic? Sure, those things are illegal. But Trump is breaking laws left and right (and getting very little pushback from the Democrats) and getting away with it, so let’s have some perspective here.

I mean, really now. There are literal gangs of masked fascist goons arresting people without due process under the president’s orders, and yet the real problem is supposed to be some graffiti, disrespectful chanting, and blocked traffic? Please.

It is interesting to note that the Nice Liberals were wringing their hands when MLK was disrupting business as usual in the Civil Rights Era. So much so that MLK himself wrote about the phenomenon in his Letter from a Birmingham Jail. And yet, real substantive gains were won as a result of that unrest, gains that had failed to happen in well over a century of quiet, polite, obsessively lawful action (or, more commonly, inaction).

And, a lot more recently, Biden cruised to victory on the heels of Black Lives Matter protests (and even a few literal riots) that disrupted business as usual.

Historical evidence indicates unrest is not so universally toxic as the Nice Liberals claim it to be. In fact, it often tends to accompany or precede periods of progressive change.