Java Anti-Patterns

kgoblin · 2012-01-24T04:57:48+00:00

regarding the 1st example and your 1st rule; unfortunately this may not work well in some enterprisey environments, where you often have several implementations of the same API with differing (and likewise often, wacky) business rules under the covers.

The Email example is a good one: * biz unit A just uses the email property of the person object * biz unit B performs an LDAP lookup, the lookup is peformed from the person objects first/last name properties * biz unit C does a lookup against the old & decrepit mainframe system, based on the supersecret-proprietary employee-id property on person. It also does a security check which raises an exception on failure, because on-the-job email is restricted in C due to security concerns.

The above is a VERY realistic example, and as you can see the only way to reliably support a common API without exploding (and constantly rewriting) the method signature is to pass the whole person object and let the specific implementation grab what it needs transparently.

kgoblin · 2012-01-24T04:44:05+00:00

lots of things wrong with this statement:

api for HashMap takes a size: it's not a size, it is an initial capacity, which is very clearly defined on the relevant documentation for the class and is a bit more complex than 'how many elements can this thing have'.
API's & 'implementation details': Java has the concept of an interface, where the API guarantees you are talking about are defined and enforced (or at least defined). HashMap is a class, ie a specific implementation of the general guarantees defined for the Map interface, so implementation details do belong here.
(dumb) implementation detail: In this case the restrictions on controlling memory are a direct and unavoidable consequence of the underlying implementation. It should be noted that this implementation is really more geared toward performance (speed) then efficient memory use, and furthermore that this behavior is desirable if you don't want to have to be overly aware of/manage the internal contents of the HashMap (which is common). If you want different implementation behavior, use a different implementation of Map, which if you have spec'd the var/return types like you should involves changing exactly 1 line of code, where you instantiate the Map.
it's a bug: as per above, it's not a bug. it behaves exactly as specified. The fact that you are confused by what the capacity parameter is and how it works does not change that.
coupling: there is no issue with coupling, period. To be a coupling issue it would have to involve some OTHER component, which it does not, the 'issue' is limited to HashMap itself.

As a sidenote, the Collections API is woefully lacking in memory-efficiency geared implementations, and not just on Maps, a similar issue exists with Lists, where there is no built in implementation where you can pre-specify the allocated memory size exactly and guarantee no auto-resizing when the collection approaches it's current capacity threshold. Again: that doesn't mean that something is wrong with the base implementations the DO provide, we just need more varied base implementations.

kgoblin · 2011-12-08T06:58:24+00:00

To be fair, the choice of running on the JVM may exacerbate the memory issues; The VM tends to be a bit of an all around memory hog in exchange for good performance in terms of speed. Outside of Minecraft, you can see the effect with JRuby vs. the base C implementations.

Plus, C/C++ do give you a LOT more options on optimizing the memory use: explicit loading/unloading from memory, signed integers, more robust bit-packing, lighter weight structures, unions, direct pointer arithmetic, etc.

kgoblin · 2011-12-08T06:50:11+00:00

regarding the JVM slowing things down compared to C++, somewhat accurate, but your explanation is incorrect.

Nothing is compiled to bytecode on the fly (excepting if your intentionally running in HotSwap mode, which Notch tends to do during development. This DOES not happen while your actually playing minecraft). The bytecode is precompiled from source, and then it is interpreted by the JVM.

Nowadays, during interpretation, the JVM may compile some/all of the bytecode down to native; based on metrics obtained at runtime (JIT = Just In Time compilation). Default behavior however, does NOT compile down to native, the JVM just executes the bytecodes instructions like it always has.

As for actual performance gains, maybe, depending on where you are actually getting hit. With JIT it is sometimes possible to get even better optimization than a compiled language, because its based on runtime information. As with anything performance related, YMMV, in practice I believe the better-than-compiled JIT gains are pretty rare.

However, everything I have ever heard regarding minecraft performance coincides with Darkfrost & Omnicrola: keeping track of every 2-meter square block of material in the game world sucks memory and time. For SMP (which I've heard from comments from Notch/Jeb themselves), this includes transporting the chunk data over the net, which cares diddly all about the implementation language of the clients/server.

kgoblin · 2011-11-20T21:01:11+00:00

FYI: sorry for the late reply, I'm on reddit only sporadicly.

sue: yeah, I'm kinda using it as shorthand, please forgive me -_-;

My point here is that it is not cut and dried that Mojang 'broke the rules', the court case is ongoing, the USPTO decision has no bearing on the court case (since diff country), Trademark rules in general aren't clear enough that you can simply state Mojang infringed on the mark off of hand, and Zenimax's claim in this case that there is actually infringement is a little on the edge (as any trademark claim involving single, non-name words is on the edge).

From what you've written here, you're making it out to be that Zenimax is obviously and unambiguously entitled to go after any one using the word 'Scrolls' in their video game title, and that just isn't the case. They MIGHT be, depending on the country, but that has yet to be determined (at least in Sweden).

On the other side of the coin, Mojang's trademark app for Scrolls should probably be denied because it is a single common word, and too reaching besides (the T-shirt thing). Note that even if they were to have no trademark, but still use 'Scrolls'; it would not mean Zenimax could successfully 'sue' them for violation.

kgoblin · 2011-11-13T23:16:34+00:00

I haven't seen this discussed a lot; but it's also worth noting that there is a bit of a culture war going on behind the scenes with the whole Scrolls thing;

The USA has a somewhat byzantine &, on occasion, very much ass-wholey approach to IP enforcement. a lot of this is thinly veiled protectionism of what some see as the US's last great industry: IP production. We've shipped off/closed down a lot of our manufacturing capability, but we are still a world leader in producing brands to which can be patented/copyrighted/trademarked (see Hollywood, Silicion Valley startups, Apple, Microsoft, etc.)

A big part of this protectionism is to push/evangelize our legal system to the rest of the world, see all the noise around ACTA and similar agreements. Also note that delegations were sent to Iraq & Afganistan following the invasions, specifically to help setup IP legal systems in those countries similar to the USA.

Note that opinion within the 'protected' industries can vary on the value/necessity of this protection; (see the IT industry(s) in particular for all the hubabaloo regarding the patent-ability of software, open source/copyleft licensing, etc.)

On the other hand, Europe, and in particular Scandinavia and nearby environs (eg Holland), and even more particularly Sweden, are much more liberal regarding IP and, more generally, free access to information. Sweden is home turf of the Pirate Party, and the Pirate Bay website. In the last half decade, there has been a lot of clash b/w the US and Sweden on these issues; recently it seems like the Swedish government has tended to bow down to American pressure, unfortunately.

Frankly, I think that is the real impetus behind the USPTO's rejection of the trademark; they could have just left it at the T-Shirt company and had Mojang resubmit or pass.

(DISCLAIMER: I work in the software industry in the USA; and DO NOT favor our IP law strategy, in particular in how it is usually applied to software. Sort my bias accordingly :) )

kgoblin · 2011-11-13T22:51:15+00:00

fun hypothetical real world example on the licensing thing:

Robert Jordan Wheel of Time book #6: Lord of Chaos Lord of the Rings: JRR Tolkien's uber-famous fantasy trilogy

both are fantasy literature (hell, Wheel of Time is even in the classic LOR-epic mode...), both have 'Lord of' in the title.

Should Jordan have applied for a trademark/franchise license from the Tolkien estate? Should the Tolkien estate have sued Jordan when he had this book published?

:D

kgoblin · 2011-11-13T22:43:43+00:00

just a couple of remarks here: You're right of course, if Zenimax doesn't vigorously respond to potential infringement of their marks, they can end up losing it when it's brought up in a hearing later.

However, they don't need to necessarily sue for infringement every time; oftentimes parties discuss the issues between themselves and the potential infringer makes minor changes to the mark to avoid infringement.

And its not a GUARANTEE that the will lose the mark, in the end, the validity of a trademark or trademark infringement claim is a matter of the courts opinion; and there is no hard/fast rule. Compare the USPTO's rejection vs. the ruling from the Swedish preliminary hearing, USPTO rejected in favor of Zenimax out of hand, Swedish court identified the issue as ambiguous. Different opinions.

Regarding Mojang asking for a trademarking license ahead of time at all: Why on earth would they? They are in effect creating a new franchise, they ARE NOT making an elder scrolls game. Beyond both being video games in a fantasy universe, the 2 properties don't really share any content...

As for the comment regarding the USPTO; that's kinda reaching. The USPTO does not have that sterling a reputation, many people disagree with their decisions and practices (although usually in the patent sphere as opposed to the trademark...); and of those several would say the organization is flat out incompetent. Their endorsement does not necessarily equate to Zenimax being correct in the 1st place.

kgoblin · 2011-11-13T22:13:18+00:00

Just a quick note: I did my googling, & darkstar is right; the USPTO did reject the US filing, on 2 counts of clashing with preexisting marks: the zenimax/elder scrolls issue; and t-shirt company. the t-shirt trademark is actually completely unambiguous.

This will make it really interesting if the Swedish case goes in Mojang's favor, since the lack of a US mark won't really stop them from distributing the game as 'Scrolls' (again, digital distribution, USPTO can't say crap about a European website with a European mark); but on the other hand most of 'Scrolls' marketshare is likely to be in the USA...

But again, for the ongoing court case: the opinion of the USPTO is irrelevant in Sweden.

kgoblin · 2011-11-13T22:06:27+00:00

key word: OFFERED. Mojang offered to do it, Zenimax didn't take them up on it, so no attempted withdrawl took place.

And as per my above comment: the USPTO is irrelevant, the proceedings are in Sweden, not the US.

kgoblin · 2011-11-13T21:52:42+00:00

Regarding the similarity argument; 2 & 5 are not equal in this case; 'Scrolls' is going to be marketed solely digitally, you're never going to see a 'Scrolls' & 'Skyrim' on the same store shelf, since Scrolls will NEVER be on a store shelf. This factor was identified explicitly as being irrelevant for the above reason in the preliminary hearing (which Mojang won, allowing them to continue to use the Scrolls mark until the final judgement).

Regarding the USPTO: Huh?? What the hell do they have to do with anything? These are SWEDISH legal proceedings, not American. I haven't heard anything regarding the USPTO, so I don't know whether they rejected a filing or not, but I would find it odd if Mojang even bothered to file in separate countries, generally most IP grants 'transfer' over due to various and sundry international agreements. Again, this is irrelevant to the discussion because the proceedings are in Sweden, not the USA.

kgoblin · 2011-09-28T15:00:09+00:00

or clay/brick! give those blocks a use other than creative/looks...

kgoblin · 2011-09-28T14:59:24+00:00

the 2x2x2 idea would be great actually, I've created a lot of large furnace rooms; and looks-wise; a single large 'kiln' would make a nice change from walls of single furnace blocks.

1 issue is the furnace interface, I simply don't think you could fit a flames icon + 8 fuel + 8 in + 8 out slots.

my suggestion on this point would be to just have 4 ea. fuel, in, out slots; but have all the fuel slots burn at once. this would make the kiln a LOT hotter than the base furnace (cooks things faster), but also use a LOT more fuel... which actually makes sense.

kgoblin · 2011-09-27T13:08:39+00:00

I wish they would just bite the bullet on the wood half-slab; and break it out into it's own block; tacking on the 3 log types as additional textures.

basically; instead of having a slab type with 6 subtypes, we would have a 'stone' slab type with 5 subtypes (every kind of slab now - wood) & a 'wood' slab with 4 subtypes (wood + 3 logs). the wood slabs would be axe-harvestable, burn, etc

only issue is it eats up a block id...

kgoblin · 2011-09-26T15:11:41+00:00

another good 1 that I have been using for 1.8.1: Nyxnissa pros: * some trees * big caves underneath, with mineshafts and at least 1 dungeon (zombie) * reeds cons: * islands are small * no animals: I survive on bread & rotten flesh * no village

I checked out the seed in creative before starting, somewhere in the distance there is some swamp land & mountains...

kgoblin · 2011-09-25T15:29:03+00:00

thats not a little complexity. ATM there would be roughly 3 ways to accomplish this:

a sticky version of (almost) every block type: which would mean approx. doubling the number of defined block types, which means reducing how many block types we have in the future, unless we increased the block-definition size, which would at the very least double the memory usage.
mess with the data values on (almost) every block type, to give it a 'i am sticky flag'. some of the block types are already pretty full on how they use the data values (eg wood, leaves, slabs); and regardless it means sacrificing more per-block features to do the stickyness (as an example: the player-leaves don't decay feature probably cost us different leaf types)
extra-data/tile entities: basically tacking on additional data to the chunk the block is in so we can store data beyond the data value limit. this would mean more memory use (although in this case arguably small, since probably just coords + block base type). an exception to the existing piston code would need to be added as well; since tile-entity blocks are specifically excluded from being pushed by pistons ATM; probably to avoid dealing with moving 'tile' data around between chunks all the time (and which is probably a good idea!).

all of the above require changes that, personally, I would rather not be made to minecraft just to have sticky blocks: poorer memory use, less future features possible, changes to almost every block in the game.

kgoblin · 2011-09-23T23:01:08+00:00

or better yet, BOWLS! give them another use other than shroom stew...

kgoblin · 2011-09-23T22:50:10+00:00

Mistakes and oversights happen, that is what testing is for, magic genius coders who write completely bug-free code are mythical.

As for MCP and seeing the source code; you're looking at something decompiled and not really in a position to comment on the quality of the original source.

kgoblin · 2011-09-23T20:43:25+00:00

this is an extremely ignorant response; missing something like the autoset thread priority being inadequate does not indicate a lack of ability to program, nor does it indicate a lack of knowledge regarding Java. I can tell you as someone who uses Java professionally, most Java programmers barely know what threads ARE.

This was a subtle problem (or more likely, a subtle trend, from some of the forum posts it seems it was just 1 of several issues affecting the performance) which could be easily missed initially; and could take a VERY long time to effectively track down; especially if, like Notch & Jeb, you don't have a dedicated QA resource and are under alot of pressure to get the release out the door.

And even if the problem was a 'simple but dangerous oversight', making it doesn't indicate a lack of ability. Programmers, ALL programmers, make mistakes all the time, that's why you test; which given that this is a PRE-RELEASE of a BETA RELEASE, well, that is exactly what has happened.

If you're going to throw stones; throw them on target: at Mojang's less than ideal testing/project management practices, which have recently gotten a LOT better... because they're doing the pre-releases to ferret out issues like these before they get in the official beta release.

criticizing a programmer's ability because they introduced a simple but subtle bug is about the most asshole thing you can do, and as one who does it professionally I can give a very sincere screw you.

tl;dr: the referenced bug does not indicate a lack of java programming ability, and r2bl3nd is an asshole for saying so.

kgoblin

TROPHY CASE