WTF Bites

Carnage

@boomzilla said in WTF Bites:

setFoo( new Boolean( false ) )

That's wrong. The author obviously intended
setFoo( new Boolean( ! Boolean.TRUE ) )

FTFY

Mason_Wheeler

My Kindle app just gave me a recommendation: Now that you've finished XYZ 3, try reading the next book in the series, XYZ 4.

I haven't gotten around to reading XYZ 4 yet, primarily because it won't be released until September!

Zerosquare

"That's not a problem, sir; would you like to preorder it now?"

Mason_Wheeler

@Zerosquare No ; that appears to be the intended purpose of this, since clicking the notification took me to the page where I could do exactly that.

Tsaukpaetra

@Tsaukpaetra said in WTF Bites:

I'm nearly choking

Status: FUCK YOU!!!

Mason_Wheeler

@Tsaukpaetra Unity?

Tsaukpaetra

@Mason_Wheeler said in WTF Bites:

@Tsaukpaetra Unity?

Yeah, someone extended a Behavior and decided they needed to make their own enabled property, but named with a capital E.

Mason_Wheeler

@Tsaukpaetra ...which Unity really should have done from the beginning. It's severely annoying how many things in there are done in a very specific, standardized way that's completely at odds with the well-established .NET ways of doing things. (Everything from naming conventions to serialization to the massive that is coroutines...)

PJH

@Bulb said in WTF Bites:

@Gąska said in WTF Bites:

the official Linux Git repo has actually suffered from the even more unlikely collision of 160-bit SHA1's.

Did it? Google does not seem to know about it.

Misremembered breakage of SVN, perhaps?

SHA-1 collision can break SVN code repositories

Watson

@Mason_Wheeler
Is that an artefact of its starting out on Mac OSX (I really don't know if/what coding standards were in use there)? And then just stuck with those on the .NET platform for project consistency.

Mason_Wheeler

@Watson I have no idea. I do know that some of the ness of Unity's bizarre coroutine system can be explained by Unity being a few years older than async/await, but even so they've had many, many years to fix it since then.

Their completely b0rked serialization system, however, there's really no excuse for. It can't deal with generics aside from List<T> which it special-cases, it ties class names to source code filenames because , and it wasn't able to handle inheritance until version 2019.3, released earlier this year -- and that requires annotating your reference with a special attribute to opt in to something that should have been working out of the box since version 1!

dkf

@Carnage said in WTF Bites:

@BernieTheBernie said in WTF Bites:
@boomzilla said in WTF Bites:

setFoo( new Boolean( false ) )

That's wrong. The author obviously intended
setFoo( new Boolean( ! Boolean.TRUE ) )
FTFY

setFoo( Boolean.getBoolean("false") )

And if you know what that does, you'll know why it needs to be killed with fire, from orbit!

dkf

@PJH I approve of this:

It's not but it has something of the same vibe…

PJH

@dkf said in WTF Bites:

@Carnage said in WTF Bites:
@BernieTheBernie said in WTF Bites:
@boomzilla said in WTF Bites:

setFoo( new Boolean( false ) )

That's wrong. The author obviously intended
setFoo( new Boolean( ! Boolean.TRUE ) )
FTFY
setFoo( Boolean.getBoolean("false") )
And if you know what that does, you'll know why it needs to be killed with fire, from orbit!

System.setProperty("false", "1");

Kamil Podlesak

@dkf said in WTF Bites:

setFoo( Boolean.getBoolean("false") )
And if you know what that does, you'll know why it needs to be killed with fire, from orbit!

Fortunately sane IDEs come with enabled warning. Of course, you might disable it (or use notepad).

HardwareGeek

@Kamil-Podlesak said in WTF Bites:

use notepad

Don't be ridiculous! Vi.

Applied Mediocrity

@dkf said in WTF Bites:

if you know what that does

I don't know how it does it in Java, but honestly I wonder why .NET Boolean Parse and TryParse are not hand-optimized. The "True" and "False" literals will never ever change.

I'd do value null check, a value length check (where 4 is definitely not false, and the other way round) and then compare letters.

Instead it goes through five switch condition checks to find it must do a case insensitive ordinal comparison, then dives to native code to find if both are ASCII. If they are, it does ASCII comparison (which inside the loop again checks whether both are ASCII). If not, it dives to native code to do some arcane Unicode comparison. Against a global constant, I remind.

I know all about readability, developer effort and correctness concerns, but in my mind that argument against micro-optimizations does not work for frameworks. Frameworks should be both correct and as fast as possible, because application developers will always make dog's breakfast of anything.

Kamil Podlesak

@Applied-Mediocrity said in WTF Bites:

@dkf said in WTF Bites:

if you know what that does

I don't know how it does it in Java, but honestly I wonder why .NET Boolean Parse and TryParse are not hand-optimized. The "True" and "False" literals will never ever change.

I'd do value null check, a value length check (where 4 is definitely not false, and the other way round) and then compare letters.
...

Since you've completely missed the point, I think some explanation is necessary: Boolean.getBoolean (and Integer.getInteger and Long.getLong) do not parse the given string (that's what parseXXX/valueOf methods do).
These methods get system property of given name and then parse it (via the "parse" method).

This is easily the biggest in Java and definitely one of the top API s of all times.

Applied Mediocrity

@Kamil-Podlesak said in WTF Bites:

do not parse the given string
get system property of given name and then parse

Alright, fine. Completely missed.

bobjanova

@Kamil-Podlesak said in WTF Bites:

This is easily the biggest in Java

java.util.Date would like a word

So would Java's terrible generics - who would imagine type erasure was a good idea after .Net had already shown how to do it properly to boot

EDIT: Particularly y when one of the 'justifications' is to still be able to use old code that does non-generic collection things - but then also creating new collection classes to support generics (Vector -> List<T>, Hashtable -> Map<K,V>)

dkf

@bobjanova While Date's horrible, it's also mostly marked as deprecated so you know you're meant to beware. The ghastly way that Boolean.getBoolean causes trouble is that it tempts you into using it for parsing, but in fact it goes off and does something else entirely. The equality operator on java.net.URL is similarly bad: never use those for map keys as that class uses DNS lookups to compare hostnames and that's spectacularly wrong for some protocols (including rare ones such as HTTP).

The type erasure thing doesn't cause anything like the trouble that you seem to think, and the fact that all the instances of a generic class are all the same has substantial memory advantages (they share compilations much more readily).

Bulb

@dkf said in WTF Bites:

The equality operator on java.net.URL is similarly bad: never use those for map keys as that class uses DNS lookups to compare hostnames and that's spectacularly wrong for some protocols (including rare ones such as HTTP).

Is there any advantage of using java.net.URL over java.net.URI anyway? The later is at least able to parse to authority, path, query and fragment (if that scheme uses them) and escape and unescape.

@dkf said in WTF Bites:

The type erasure thing doesn't cause anything like the trouble that you seem to think, and the fact that all the instances of a generic class are all the same has substantial memory advantages (they share compilations much more readily).

Which is more than outweighed by all the extra boxing. .NET only expands the code for value-typed substitutions, which avoids boxing; for reference-typed substitutions the code is shared and just uses object dynamically, so the only overhead is a little metadata in those cases.

dkf

@Bulb said in WTF Bites:

Is there any advantage of using java.net.URL over java.net.URI anyway?

URL is the only one of the two that can download the document. You might need that occasionally.

Bulb

@dkf Ok, great design

bobjanova

@dkf said in WTF Bites:

The type erasure thing doesn't cause anything like the trouble that you seem to think, and the fact that all the instances of a generic class are all the same has substantial memory advantages (they share compilations much more readily).

Java generics make me swear at least once a month in my actual job - usually because I can't find what typeof(T) or T.class is, when that's useful. Lots of Java methods end up looking like

public static <T> doSomething(T value, Class<T> domainClass) { ... }

... precisely because you can't find typeof(T). Even well known frameworks have to do this (e.g. Spring's getBean(name, class)). This is ugly and bad and you don't have to do it in .Net.

Not being able to have two constructors or method overloads taking different types of list is a related too.

There might be some marginal memory improvements in some scenarios but:

If you care about memory on that scale you shouldn't be using Java anyway
A common use of generics is List<int> or Map<int, T> or Map<K, int> and the extra boxing (memory wasted per record not just per class) for that type of situation almost certainly outweighs it anyway
For a high level language letting you write nice code should be higher priority than small memory considerations anyway

Kamil Podlesak

@bobjanova said in WTF Bites:

@Kamil-Podlesak said in WTF Bites:

This is easily the biggest in Java

java.util.Date would like a word

So would Java's terrible generics - who would imagine type erasure was a good idea after .Net had already shown how to do it properly to boot

That's not even the same league.
Also: Java 1.5 (the one with generics) was released full year before C# 2.0, so the only "properly to boot" implementation was C++

Also, I distinctly remember that the C# department of the company I worked for allocated at least one full quarter as "upgrade to C# generics" and they talked about "almost complete rewrite". I also remember that when I asked about C# take on covariance and contravariance, I got black and confused stares... and my attempts to explain were met with "nonsense, no such thing is needed" reaction. So maybe was somewhere else.

EDIT: Particularly y when one of the 'justifications' is to still be able to use old code that does non-generic collection things - but then also creating new collection classes to support generics (Vector -> List<T>, Hashtable -> Map<K,V>)

Both Vector and Hashtable fully support generics without any problem or incompatibility. They are deprecated and replaced by other types for completely different, independent reasons (I think it's just a conincidence that these two changes ended up in the same JDK version):

Vector and Hashtable are classes, List and Map are interfaces. This is not "theoretical" difference - Map came with several implementations (HashMap=hashtable, TreeMap=red-black tree, EnumMap=simple array, some anonymous like single-value map), List too to a lesser degree (ArrayList and LinkedList). Additional implementations were added later (ConcurrentHashMap, ConcurrentSkipListMap = skip list) and of course there are many libraries with some interesting implementations.
Vector and Hashtable have all methods synchronized, which did have huge impact on performance (it got better, but it's still nice to avoid the overhead completely when possible).

Kamil Podlesak

@dkf said in WTF Bites:

@Bulb said in WTF Bites:

Is there any advantage of using java.net.URL over java.net.URI anyway?

URL is the only one of the two that can download the document. You might need that occasionally.

It's another reminder of the original applet-focused APIs and it should be at least marked as deprecated.

Tsaukpaetra

status: stepmom is teaching little brother to type uppercase letters by pressing Caps Lock.

Oh dear.

topspin

@Tsaukpaetra said in WTF Bites:

status: stepmom is teaching little brother to type uppercase letters by pressing Caps Lock.

Oh dear.

Disable Caps Lock.

cvi

@topspin I just remap it to escape.

Tsaukpaetra

@cvi said in WTF Bites:

@topspin I just remap it to escape.

Or do it like Google and map it to a useless function. Maybe Search.

Gąska

@Mason_Wheeler said in WTF Bites:

@Tsaukpaetra ...which Unity really should have done from the beginning. It's severely annoying how many things in there are done in a very specific, standardized way that's completely at odds with the well-established .NET ways of doing things. (Everything from naming conventions to serialization to the massive that is coroutines...)

@Watson said in WTF Bites:

@Mason_Wheeler
Is that an artefact of its starting out on Mac OSX (I really don't know if/what coding standards were in use there)? And then just stuck with those on the .NET platform for project consistency.

Nope. First-letter-capital properties are the standard .Net convention officially supported by Microsoft since always.

Gąska

@PJH said in WTF Bites:

@Bulb said in WTF Bites:

@Gąska said in WTF Bites:

the official Linux Git repo has actually suffered from the even more unlikely collision of 160-bit SHA1's.

Did it? Google does not seem to know about it.

Misremembered breakage of SVN, perhaps?

SHA-1 collision can break SVN code repositories

I'm pretty sure it was Git. Specifically, the Linux kernel Git repo. It might be fake altogether, but it's impossible I've misremembered it.

pie_flavor

@Kamil-Podlesak said in WTF Bites:

C# take on covariance and contravariance

This is the part where Java really fucked up. Even type-erased generics can be worked around, but this part here blows. In a sane language, Iterator<String> is a subtype of Iterator<Object>, and Consumer<Object> is a subtype of Consumer<String>. In Java, go fuck yourself, and write out Iterator<? extends Object> every time you want to do anything.

MrL

@Mason_Wheeler

@Tsaukpaetra ...which Unity really should have done from the beginning. It's severely annoying how many things in there are done in a very specific, standardized way that's completely at odds with the well-established .NET ways of doing things. (Everything from naming conventions to serialization to the massive that is coroutines...)

Don't get me started on those dorks at JetBrains that set awful styling defaults in Resharper, which make them 'standard', because 99% of programmers are too lazy to change anything in settings.

pie_flavor

@MrL what styling defaults are those?

Gąska

@pie_flavor based on @Mason_Wheeler's post, my guess is lowercase property names.

El_Heffe

@Tsaukpaetra said in WTF Bites:

status: stepmom is teaching little brother to type uppercase letters by pressing Caps Lock.

Oh dear.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,00,00,3a,00,00,00,00,00

No more capslock.

El_Heffe

Raymond Chen / Aug 5, 2020

What does it mean when it says that FORMAT_MESSAGE_ALLOCATE_BUFFER can be used in Store apps starting in Windows 10? - The Old New Thing

What happens if you use it anyway?

Okay, first of all, let’s set the context. The context is Windows Store apps; that is, apps that are submitted to the Windows Store and which run as a UWP app. These apps must pass a test known as the Windows App Certification Kit or just WACK for short. Passing this test as a prerequisite for being accepted by the Windows Store

Well, that certainly seems appropriate.

Gąska

@El_Heffe the second part is much more WTF-worthy.

Raymond Chen / Aug 6, 2020

What was so horrible about the FORMAT_MESSAGE_ALLOCATE_BUFFER flag that the Windows Store disallowed it for so long? - The Old New Thing

Letting in the riffraff.

Benjamin Hall

@Gąska since I'm a novice, that all sounded like discussions of cricket to me. Like...I know all the words, but they don't make sense.

Gąska

@Benjamin-Hall here comes ELI5.

For context: Windows Store apps are meant to be more secure than regular programs, so they're banned from using 90% of WinAPI - basically everything that can be used to mess up with the computer in some way. This includes the FormatMessage function, but only when using flag FORMAT_MESSAGE_ALLOCATE_BUFFER.

There's some very confusing wording in WinAPI documentation:

In previous versions of Windows, this value was not available for use when compiling Windows Store apps. As of Windows 10 this value can be used.

Basically:

It cannot be used by Windows Store apps for Windows 8.
It can be used by Windows Store apps for Windows 10.
But wait, it's a compile-time thing. Why the fuck would Windows version matter!?

The first post explains it in more detail. In short - it's not about Windows version. It's about Windows SDK version. When Windows 8 was released, it was decided the flag should be unavailable in Windows Store apps - meaning that if an app used it, it would be rejected by Microsoft during verification process and be impossible to publish in store. But to make lives of developers easier, it was also conditionally removed from SDK - when configured in Windows Store mode, the symbol would become unavailable and cause compile error. But when Windows 10 was released, the flag was now allowed to use - so Windows 10 SDK didn't disable it. With new SDK, you can build apps using that flag targeting Windows 8 and it will pass verification just fine.

But wait, why was disallowed in the first place? The second post explains it as such:

FormatMessage is a C function, so like all C function, it needs a buffer to create a string. Usually it's provided by user.
FORMAT_MESSAGE_ALLOCATE_BUFFER flag tells FormatMessage to do its fucking job and allocate the buffer by itself. The user still has to free this memory later.
Like every good C library, WinAPI provides no less than 5 different ways to allocate memory that are basically equivalent.
FormatMessage is an old function so it uses the old (16-bit Windows) LocalAlloc that has long been deprecated. Following the ancient C tradition, the only way to free this memory is by calling the matching LocalFree function, which is also 16-bit era relic that has long been deprecated. It's worth noting that under the hood, these two functions are basically very thin wrappers around HeapAlloc and HeapFree.

So far so good. But then:

Windows Store API architects have (rightfully) decided that it's as good time as any to remove all the legacy crap for good.
Almost all 16-bit era relics have been disabled for Windows Store apps.
That also meant disabling LocalAlloc and LocalFree.
Without LocalFree, it's officially impossible to free memory after FormatMessage.

So, what could Microsoft do in this situation?

Allow LocalFree in Windows Store apps?
Disable the flag that makes FormatMessage allocate memory?
Document the implementation details of LocalFree so that FormatMessage can be freed with HeapAlloc?

Windows 8 chose #2, Windows 10 chose #1. Option 3 was discussed and even almost implemented before Windows 8 release (it's only a documentation change so not much to implement), but someone must have given it a red light after previously giving it a green light.

pie_flavor

@Gąska said in WTF Bites:

@pie_flavor based on @Mason_Wheeler's post, my guess is lowercase property names.

but it absolutely does not have lowercase property names by default.

Gąska

@pie_flavor if not Microsoft and not JetBrains, then who uses lowercase properties?

The plot thickens!

Bulb

@Benjamin-Hall said in WTF Bites:

@Gąska since I'm a novice, that all sounded like discussions of cricket to me. Like...I know all the words, but they don't make sense.

It's simply histerical raisins at its best. Windows memory allocation was complicated in part because 16-bit mode was complicated and in part because Microsoft tends to program the first solution that crosses their mind instead of spending some mental effort trying to find a simpler one. And that complication was carried forward for backward compatidebility all the way to the present day.

bobjanova

@Kamil-Podlesak said in WTF Bites:

Java 1.5 (the one with generics) was released full year before C# 2.0

Huh, my memory must be playing tricks on me on that point.

the C# department of the company I worked for allocated at least one full quarter as "upgrade to C# generics" and they talked about "almost complete rewrite". I also remember that when I asked about C# take on covariance and contravariance, I got black and confused stares..

I think here is your coworkers. But it's true that C# 2.0 didn't do these things well and they've improved C# generic since to do it better.

Both Vector and Hashtable fully support generics without any problem or incompatibility. They are deprecated and replaced by other types for completely different, independent reasons (I think it's just a conincidence that these two changes ended up in the same JDK version)

Maybe coincidental but the effect was still that new code couldn't just call old without explicitly writing changes to do so, making doing generics in that way pointless.

JBert

@bobjanova said in WTF Bites:

Both Vector and Hashtable fully support generics without any problem or incompatibility. They are deprecated and replaced by other types for completely different, independent reasons (I think it's just a conincidence that these two changes ended up in the same JDK version)

Maybe coincidental but the effect was still that new code couldn't just call old without explicitly writing changes to do so, making doing generics in that way pointless.

Ah, but you're forgetting about the Java Virtual Machine. At the point that generics were introduced there were several JVM implementations.

Since both Java-the-language and Java-the-bytecode-format are designed by committee, JVM makers got to complain that existing bytecode should keep working. That might be a huge part of why the types are erased: that way JVMs don't need to keep track of generics and just work with classes like they always did.

Kamil Podlesak

@bobjanova said in WTF Bites:

the C# department of the company I worked for allocated at least one full quarter as "upgrade to C# generics" and they talked about "almost complete rewrite". I also remember that when I asked about C# take on covariance and contravariance, I got black and confused stares..

I think here is your coworkers. But it's true that C# 2.0 didn't do these things well and they've improved C# generic since to do it better.

Yeah, I agree. After all, these are the same people that gave me sources (I needed to reverse-engineer some WTF protocol) as a Windows Installer (not, not self-extracting zip; honest-to-god installer with wizard and everything). When I asked about that, the answer was: It's the only way to create archive in Visual Studio.

Both Vector and Hashtable fully support generics without any problem or incompatibility. They are deprecated and replaced by other types for completely different, independent reasons (I think it's just a conincidence that these two changes ended up in the same JDK version)

Maybe coincidental but the effect was still that new code couldn't just call old without explicitly writing changes to do so, making doing generics in that way pointless.

I honestly have absolutely no idea what you're talking about. Maybe you're confusing that with C# 2.0 or something, because in Java is was exactly the opposite.

Bulb

@JBert said in WTF Bites:

@bobjanova said in WTF Bites:

Both Vector and Hashtable fully support generics without any problem or incompatibility. They are deprecated and replaced by other types for completely different, independent reasons (I think it's just a conincidence that these two changes ended up in the same JDK version)

Maybe coincidental but the effect was still that new code couldn't just call old without explicitly writing changes to do so, making doing generics in that way pointless.

Ah, but you're forgetting about the Java Virtual Machine. At the point that generics were introduced there were several JVM implementations.

Since both Java-the-language and Java-the-bytecode-format are designed by committee, JVM makers got to complain that existing bytecode should keep working. That might be a huge part of why the types are erased: that way JVMs don't need to keep track of generics and just work with classes like they always did.

Each Java version brings changes (new features) to the bytecode and the JVM, the alternate implementations were always behind and often never got the newer features at all, and Sun never gave a fuck about them anyway.

El_Heffe

@Gąska said in WTF Bites:

Basically:

It cannot be used by Windows Store apps for Windows 8.

It can be used by Windows Store apps for Windows 10.

But wait, it's a compile-time thing. Why the fuck would Windows version matter!?

The first post explains it in more detail.

Raymond Chen also says, in his discussion of the very appropriately named WACK:

"Passing this test as a prerequisite for being accepted by the Windows Store is a policy issue, not a technical one."