smarks

Lots of useful history.

The bug in question has a number in the 8,000,000 range, but that doesn't mean there are 8M bugs. The bug numbering was carried over from the old Sun-internal bug database. That bug database was shared across a large number of Sun projects, not just Java, so it went through the numbers pretty quickly. I'm not entirely sure, but I think the numbering might have started at 1,000,000 in order to make sure the bug IDs all had seven digits.

In addition, there were several migrations to different databases, where "new" bugs were created at a particular range (say, 4,000,000) to distinguish them from "old" bugs that had been migrated from the previous system. Thus, there are large gaps in the numbering.

When OpenJDK migrated from the old Sun bug database to JIRA, something similar was done. New bugs were created starting in the 8,000,000 range. Most of the old Java-related bugs were migrated from the Sun bug database into JIRA, preserving their existing numbers. There are bugs in the 1,000,000 range that date back to 1994, predating Java 1.0, and well before Java was open-sourced.

The lowest-numbered bug in the current database is this one from 1994:

https://bugs.openjdk.org/browse/JDK-1169723

(This includes only JDK bugs. There are other projects in the same JIRA instance that have different numbering schemes.)

Finally, a single bug can generate multiple items in the JIRA database. For example, if a bugfix needs to be backported to an older release, this generates subtasks for each targeted release. There are about six actively maintained releases, so there's a bit of a multiplier effect. (Not every bugfix is backported, though.)

There are currently about 318,000 bugs (open and closed) in the JDK project.

At least they didn’t blame the intern.

> base64 encoding and application level decoding is also an accepted practice

I feel seen. I remember suggesting this during a design discussion where the issue was how to embed an arbitrary document in another, where the embedded document could even be ill-formed. Everybody told me it was a gross and dirty hack and ignored the suggestion.

At Sun Microsystems this notion was so common that there was a TLA for it:

CLM = "career limiting move"

Agreed that LinkedList memory footprint and locality are serious issues.

Fundamentally though the problem is that the LinkedList implementation is at odds with the abstraction provided by List -- access by index.

Certainly, straight iteration of every element is better done by a for-each loop (which uses an Iterator under the covers). But the availability of indexed access leads one to use it for a variety of additional circumstances. Consider for example processing every even-numbered element, or finding an element that meets some criterion and then operating on an adjacent element. Iterating over indexes for cases like these is quite natural given the List API. (ListIterator can be used for this sort of stuff, but it's quite cumbersome, and sometimes it doesn't actually help.)

Right. The main problem is that Java's List interface affords access by int index, making it seem array-like. Unfortunately get(i) on a LinkedList is O(n). This turns apparently innocuous things quadratic, like looping over a list by index.

Good list. I’d add the following:

* Requires virtually no system administration.

It seems like every other piece of technology needs some setup, backups, periodic updates, or fiddling when something inevitably goes wrong.

If I’m not mistaken the 12C doesn’t have a clock. Thus, it doesn’t need to be updated 2x a year for Daylight (Summer) time, nor to have its time zone tables updated. It doesn’t need a clock; there are plenty of other ways for me to find the time, thank you. Not having a clock is a feature! Too many devices have a clock that cannot be disabled. A clock that is set wrong is worse than no clock at all. Thus, a device with an unnecessary clock demands my periodic attention to ensure the clock is set correctly.

About the only system administration necessary for the 12C is to replace the batteries. The batteries last for a very long time. As noted above, the 12C operates for a long time in a low battery condition, so you can choose to change the batteries when it’s convenient to do so.

I know, right? When Oracle bought Sun they forced all the engineers to choose between legal and proctology; I chose the latter. After ten years I’m starting to regret my decision. At least Sun wasn’t bought by IBM. (That was actually in play before the Oracle deal.) At IBM they force the engineers to go into Sales. That would have been far, far worse.

Cliff Stoll is a real character. I remember attending an author event for him at Computer Literacy in Sunnyvale, for his subsequent book “Silicon Snake Oil”. This would have been 1995 or so. The place was packed. He talked about the book a little bit, but he basically told stories nonstop for about two hours.

I forget most of the stories, but one was about a grandfather clock (a tall pendulum clock) that was being thrown out because somebody thought it was useless —- it ran fast by four minutes a day. But the clock had been set that way deliberately. Why? Clue: the clock was found near the astronomy department.

Gur craqhyhz jnf nqwhfgrq fb gung gur pybpx xrcg fvqrerny gvzr.

It was an incredibly fun and extremely nerdy event.

I’d recommend against using spray oils such as Pam because they include lecithin, I think so that the oil coats surfaces more easily. Eventually lecithin will build up and make the cooking surface less effective. You can scrub it off with detergent but it’s kind of a pain.

I’d recommend putting just a little oil on a paper towel and spreading a very thin coat across the surface. Only takes a few moments.

It’s no good unless it’s organic.

+1 for Kenji’s book “The Wok”. I use an inexpensive carbon steel, flat-bottomed wok on my regular old electric stove. Sure, a round-bottomed wok on a gas burner might work better but I can get good results on my setup.

Oh yes, totally undefined.

But consider the time frame, early 1980s K&R C on 4bsd Unix on a VAX. This predates ANSI/ISO C and Posix. It even predates “nasal demons.” There was no specification; or perhaps the implementation was the specification. The fact was that at some point the bsd allocator did leave freed memory untouched until the next memory allocation operation, and so people wrote programs that relied on this.

Again, I’m not defending this, but this seemed to be the way that some people thought about things. I even remember questioning some code that used memory after having freed it. It was explained to me that this was “safe” because the memory wouldn’t be modified until the next malloc!

Also, remember that BSD was the system where if you did

    printf("%s", NULL);

it would print “(null)” instead of getting SIGSEGV. And in general, deferencing a null pointer would return zero. The rationale for this was that it “made programs more robust.” (Again, I disagree, don’t argue with me about this!)

One more common technique from the BSD era (srogue again, but other programs did this too). To save the state of a program, write to a file everything between the base of the data segment to the “break” at the top of the data segment. To restore, just sbrk() to the right size and read it all back in, overwriting everything starting at the base of the data segment. I always found it surprising that this worked, but it worked often enough that people did sh!t like this.

Definitely not GC. This was K&R C on BSD Unix around 1984.

Yes, grad students at Berkeley in the early 1980s. For some reason I associate this technique with Bill Joy (who obviously was a major influence on a lot of what went into the 4bsd releases). However I have no evidence of this, nor whether any or what kinds of substances might have been involved.

"Multidreaded programs" :-)

This was at least a decade before multithreading in C and Unix. But yes this "technique" would have failed miserably in a multithreaded environment.

It was definitely malloc'd memory, as I remember removing free() calls from the callee and adding them to the caller.

I'm convinced there was another style of C API where the callee would malloc a struct, populate it, and free it immediately before returning a pointer to it. Of course, the only way the caller can use the result is after it has been freed.

Naturally there was a dependency on the exact behavior of the allocator, specifically, that it had to leave a freed block of memory untouched sufficiently long for the caller to be able to use the results. I seem to recall the stipulation was that freed memory was left untouched until the next memory allocation operation. The caller also had to be careful about using or copying the results immediately, before doing too much work.

I have dim memories of people talking about this sort in thing at university in the early 1980s; we were a 4.2 BSD shop. I also recall debugging some old C source code (srogue, which also has BSD heritage) decades later, and encountering use-after-free crashes. There were several instances of this. There were too many to be accidental; it seemed deliberate to me.

I suspect the reason for this "technique" was to relieve the caller of the burden of freeing the memory. It allowed the caller to return variable-length data easily, which couldn't be done if the pointer was to a static data area. And finally it relieved the callee of defining an explicit "free" API.

Frankly I think this is a terrible API style. However, code that used it properly and that was sufficiently careful would actually function properly. But it seems like an incredibly fragile and sloppy way to design a system.

Heh, there's a mention here to Andy and Bill's Law, "What Andy giveth, Bill taketh away," which is a reference to Andy Grove (Intel) and Bill Gates (Microsoft).

Since I have a long history with Sun Microsystems, upon seeing "Andy and Bill's Law" I immediately thought this was a reference to Andy Bechtolsheim (Sun hardware guy) and Bill Joy (Sun software guy). Sun had its own history of software bloat, with the latest software releases not fitting into contemporary hardware.

This is a really cool site! Thanks for maintaining it.

My father worked for Wang through the 1970s so I'm familiar with all of these and also with several other Wang products. I see you have a lot of documentation hosted here too. Brings back a lot of memories.

In a sibling comment I just posted a little story about one of my earliest programming jobs, on a Wang 2200 MVP.

https://news.ycombinator.com/item?id=32232557

One of my earliest programming jobs as a college student was programming BASIC for Wang 2200MVP systems. A couple business school graduates had formed a partnership to develop semi-custom computer applications to support agribusiness corporations in Latin America. They got some hardware through one of Wang's developer programs (which my father worked on at the time, around 1981-1982). They also needed programming help, and my father referred them to me.

They had developed quite a capable application, which is amazing given the limitations of the system. The 2200 was memory-limited (both code and data) and so in order to deal with this limit, we had to use code overlays. And the BASIC (mostly) didn't support symbols for subroutines, so we had to use line number conventions. For example, lines 8000-8999 might have been designated as the overlay area. To load some overlay routines, those lines would first need to be cleared, and new code would be loaded that by convention would start at line 8000.

And subroutines (mostly) didn't have parameters or return values, so we had to keep conventions for all the different subroutines to take parameters in certain named variables and to return values in other named variables. There were no local variables, so all the code needed to conform to some conventions over use of temporary variables so that different parts of the code didn't stomp on each others' data.

I don't remember much else about the system, but they did manage to get the Simplex Algorithm working well enough to solve optimization problems, such as where to apply resources in order to maximize revenue.

I also got a trip to Ecuador out of it in order to do a customer installation. Pretty cool for a college student to get international business travel.

Yes, this. My father worked for Wang through the 1970s and he thought it was a huge mistake that An Wang handed over the company to his son Fred, instead of to a company veteran like J.F. Cunningham, who left around the time it became clear that Fred would be An Wang's successor.

https://www.latimes.com/archives/la-xpm-1985-07-20-fi-6028-s...

The VS was more of a successor to the 2200 than a competitor. The 2200 was mostly a single-user system with a ROM-based (later, firmware-based) OS that simply ran a BASIC interpreter. Later versions (e.g., 2200 MVP) supported limited multi-terminal, multi-user capability, but it was essentially multiple independent BASIC interpreters, one per user.

The VS came out a few years later and was an IBM 370-like machine in a minicomputer form factor. It supported 370-like assembly language and several compiled languages including COBOL, RPG-II, and BASIC. The BASIC was quite a bit different and considerably evolved compared to 2200 BASIC.

Huh, I might try this. The previous time I bought drip grind and used an automatic drip maker. They don’t seem to specify the grind anymore. I suppose I could buy whole beans and grind them myself, but that would seem to be a bit contrary to the spirit of this discussion.

Of course the article is less about good coffee or bad coffee but about how coffee is intertwined with our lives and our culture (at least, American culture). For example, the author mentioned Perkins and I knew exactly what he was talking about. The stories about his stepdad Ted were touching as well.

Two memorable coffee experiences come to my mind.

One was a dinner I had with the late John Vlissides (probably known to some HN denizens as one of the Gang of Four design patterns folks) at a basement Indian restaurant in San Francisco. The meal was excellent, and for some reason we had coffee afterward instead of the usual masala chai. The coffee was far from bad, in fact it was quite good, so we asked about it. The waiter came back with the answer. It was not Peet's, not Graffeo, not some gourmet roaster I had never of. It was Hills Brothers. Hills Brothers was (I guess still is) an old school coffee roaster founded in San Francisco in 1900.

Soon after, I went to the grocery store and bought a can of Hills Brothers coffee and brewed a pot. It was disappointing. Not nearly as good as the coffee we had that night in the restaurant. It could be that Hills Brothers delivered different coffee to bulk buyers such as restaurants as opposed to the retail market. Or the difference could have been my dining companions.

Another coffee memory is hauling my late parents' 50+ year old Pyrex glass percolator out of the closet and brewing a pot. I remember when I was a kid, watching the clear water start to boil, and droplets of coffee falling from the grounds basket into the water, turning it first reddish brown, then darker brown, and then finally black. There is something mesmerizing about watching coffee percolate this way. After it was done I had a cup. It tasted kind of burnt, but at the same time kind of thin and weak. Not terrible, but not really very good. I don't think I made it incorrectly; I think this is how coffee always was for my parents. Hm, that was a while ago. It's about time to haul out the percolator again.

Diaconis is a real character. He gave a guest lecture to my statistics class at university ... um, several decades ago. His then-current research was around the effects of unfair dice. He was going to get his grad students to roll unfair dice thousands of times and see what effects loading and shaving would have on the outcomes.

To get some unfair dice, Diaconis went to a loaded dice shop somewhere in Los Angeles to see about ordering a set of custom dice. (This was before you could order unfair dice over the internet.) Since an unfair die is intended to have one face come up more frequently than the others, he wanted each die to have a pip only on that side, with the rest blank. This would make it easier to record the results.

The proprietor of the shop looked and him strangely and said, "What kind of game are you running, buddy?"

Diaconis said, "Oh I'm not running a game. See, I'm a university professor, and I'm doing some research into the effects of unfair dice."

Proprietor: "Yeah. Sure."

The "native HashTable" referred to here is the string hash table that's inside the JVM. The JVM has to intern strings from class files' string literals here, so it's all implemented in native code. The comment about performance probably refers to Java constantly improving in performance because of improvements to the JIT compiler, whereas that native HashTable in the JVM is pretty static in performance unless somebody rewrites it or if the C++ optimization gets significantly better. Essentially Shipilëv is saying that Java code gets faster more quickly than the C++ code in the JVM.

Unlikely, as Java’s string interning behavior was specified in the first edition of the JLS (1996). This predates C# as far as I know.

https://download.oracle.com/otn-pub/jcp/jls1-spec/jls1.pdf?A...

See section 3.10.5.

(Note: the article is from 2019, but it is still relevant and interesting.)

If all you're doing is deduplicating string objects in order to save memory, the article makes a good case to use `HashMap` or `ConcurrentHashMap` instead of `String.intern`.

The reason to use `String.intern` is in the fairly narrow case where you want to use `==` to compare strings, and some of these strings originated as string literals in Java source code. Java specifies that string literals for equal strings are always the same Java object, even if they occur in different class files that are compiled separately. This is accomplished by interning the strings, and `String.intern` provides user-level access to this same intern pool.

Right. At least at Sun through the 1990s, when everybody had their own workstations, many network nodes had local filesystems, so they were both NFS clients and NFS servers. For this to work well it pretty much required that UIDs/GIDs were globally consistent.

This was maintained using YP/NIS. But Sun was too big for a single YP/NIS domain, so there was a hack where each YP/NIS master was populated via some kind of uber-master database. At least at one point, this consisted of plain text files on a filesystem that was NFS-mounted by every YP/NIS master....

This was all terribly insecure. Since everybody had root on their own workstations, you could `su root` and then `su somebody` to get processes running with their UID, and then you could read and write all their files over NFS. But remember, this was back in the day when we sent passwords around in the clear, we used insecure tools like telnet and ftp and BSD tools like rsh/rcp/rlogin. So NFS was "no more insecure" than anything else running on the network. But that was ok, because everything was behind a firewall. (Some sarcasm in those last bits, in case it wasn't obvious.)