"* lets you manipulate a client-side database"
HTML 5 has SQL databases for client-side storage.

"* lets you establish a socket connection to a server"
So long as it's http, you can do a lot of advanced async RPC operations, including poll-based message notifications.

"If you're teaching yourself javascript or html5 then the truth is that you are probably wasting your time."
Cause you know, the marketing end of a web-site doesn't need to access the 99.9% of customers or anything.

You do realize WHY javascript in browsers don't provide native access don't you? Any why node.js does..
How many emergency flash updates have been pushed in the last year? And see if you can find any that were related to javascript security holes.

Have you ever written to a SOA before? It's not exactly the hardest thing in the world to abstract.. It takes like 20 lines of Java code to swap one data-store for another (and I'm talking flat-binary-file, flat-XML-fle, flat-CSV-file, sqlite, hsqldb, mysql, postgres, oracle, NoSQL vendor A,B,C).. It's called coding to abstraction layers.. And guess what, there are already tools that abstract all the major java vendors (elastic bean-stalk, app-engine, etc).

You make it sound like VHDL is harder to write than assembly.. I assure you it's more expressive than that primitive sequential crap that assembly (and it's higher-level derivatives) forces you to think in. :) And every bit as modular.

I'll take your sarcasm and raise it. Clearly you haven't done much embedded programming. Where you almost don't even notice when switching back and forth between C and assembly - and often you're frustrated with the limitations and hackish work-arounds that the high-level language forces you to make.. Why do I need to divide then modulate when one assembly instruction is all I need? :)

classes in javascript are hodge-podge at best, hard-to-read. Inheritence is not worth the trouble. The undefined v.s. null v.s. false-valued is a bug-death-trap. To a lesser degree, equality. scoped/packages are a hack at best. These are all things the language can be forced to do against it's will, and if you exclusively deal with libraries like jQuery you can usually avoid it. But ultimately if you want to write re-usable code, then you have to pick a hackish paradigm. This allows you to write elegant looking software with fewer lines of code (e.g. lower risk of bugs). I see a couple gotcha's "->" v.s. "=>", the "@sym", and a couple other places where debugging will be hell. Then there's the lack of editor support, potential errors in the compiler. But it does make the language more palatable.

If you're already fine with nondeterminisitic 'this' values, and are comfortable with your own thing with modular coding, then this doesn't really bring much to the table for you. But I've read my fare share of unreadible javascript code, and normalized structure is not something that would hurt the language/platform.

Well, you're half right.. It went from main-frame+ASCII terminal to peer-to-peer power-houses, back to COTS centralized hardware (trying to reproduce mainframe without the mainframe) + HTML/Browser.. Now I think it's almost found it's happy medium, proprietary mainframe components (netapp-type storage appliances + cisco + cloud-farms (160-core CPU blades) + VMware-type) for the sharable data + javascript 'thick client'. By thick, I mean gmail takes about 250Meg of RAM these days.

The reason I like the current division is that peer-to-peer is inherently unscalable (unless you're willing to use eventually consistent models, where eventually, here, might be on the order of years). So you take ONLY the portion that needs to be shared and centralize it.. Then farm out the rest to the client.

iOS/android/chrome-OS apps are basically where HTML+Javascript are too limiting. iOS HTML extensions allow swiping events whereas the others don't do it as expressively, so there currently is an edge for embedded apps.. I'm not a fan of them at all.. I'd rather customized HTML that can survive network outage.. Namely if you hit the page and the network is down, the browser just loads the old page.. The use of HTML 5 sql tables means you have off-line storage already.

I think maybe the android Java or the Objective-C binaries can save a little power v.s. a complex javascript system - but I'd be curious to see how true that really is.

Obviously the main thing [evil] Apple wants, is what [evil] MS wants, which is vendor lock-in.. So the richness of the iPhone experience is through their graphical widget API.. No reason they couldn't made them as HTML extensions or javascript libraries, EXCEPT then other platforms would get their capability for free.. So sad..

But it's a matter of opinion whether this is an error or not. If I've subclassed a method and my base class one day implements it too with the same name with a protected or public method then it's fine... If they implement it as private then (and I can't remember which happens) you either fail hard or it calls it's local private - both of which are fine. If you're extending 3rd party code you MUST take into account version mismatch issues - namely you must build a robust packager. If you're extending your own code, then there's no sense for bad taste.

That being said, I have made judisciuos use of the @Override method to do half of what you've described - the half that I think is more important.

And why exactly does a production DB need to allow user-level account access? And why would a dev/test DB care about passwords? Are we still living in a day where client apps have passwords directly into the DB as opposed to having a password file in the DB that allows access to the higher level app?

Because
show [VERBOSE] XYZ like 'foo%bar';
is so less intuitive than \dl \dt \df \l
And to think, using something that looks like SQL inside a SQL maintenance tool.. arrogant bastards. Don't they know using notepad on 4 config files and reloading the server is the proper way to administer things.

Two things.
1) fdatasync on 100 files is going to have a higher probability of updating the inode record (because their individual file sizes will have likely grown) - I'm talking to you postgres too. Thus doubling the number of dirty blocks per synchronous commit.
2) Mysql gives you the option of 1 file, a raw partition (i.e. /dev/vg0/INNODB1 2 3, etc), one large regular file or hundreds of little files.
    I tend to choose the hundreds of little files so I can see last-modified time-stamps on my literally hundreds of aging custom databases. But I definitely prefer the consolidated uber-file for performance reasons.

The idea of a database is that the disk belongs to a single process.. So I never understood this idea of recovering deleted disk space. In fact, I'd prefer to pre-allocate the whole damn partition or at least, on an extent-based file-system the ability to have a defragmented single-mathmatically-block-address-lookup storage file. Cold randomly scattered 4KB randomly allocated sectors require log_2k(n) disk lookups per read/write.. contiguous extends take precisely 1 highly-cached lookup.

Maybe I'm missing something, but I don't see how that's possible. Hibernate is idiot-simple when you have a single table of primitive types. I can write my own adaptor that serializes the entire row contents into a blob, then inject that into a RDBMS or key-value blob-store identically. In fact, the RDBMS will probably do this faster because it has many years of disk-oriented (memory is too small) code, v.s. most NoSQL solutions that are in-memory optimized and page-to-disk bolted on. If you use a BigTable or couchDB javascript document as your serialization, then you're straight back to explicit table land.. Namely because your Hibernate schema definition is rigid (while your BigTable/couchDB definition is not) - but you're limited by the weakest link.

The power of a CouchDB documents is in writing custom filters to translate the data. The power in BigTable is in it's efficient 1-to-many storage. Neither of which, again are leveraged by Object oriented solutions (save perhaps a dynamic scripting language like groovy).

I'm not disparaging NoSQL solutions - but I don't see a one-hat-fits all mold

Haha, only if you control the runtime.. You're only recently reliably able to compile against 1.5 and publish centrally. I STILL see tons of dual deployed open-source projects.. X and X-j5. Let alone compiled against java6 - why risk it? Again, unless you control the runtime.

You'd have to be doing something pretty hokey for this to be an issue. OutputStream maybe - since people wrap those all the time. Link-time, the only problem I can see is if you happened to have the same input signature but a different return type - as that would normally be a syntax error - the class-loader validator would probably fail hard.

That being said.. How else could you handle this? Contain both version 1.2 OutputStream AND version 1.7 ? Not seeing that as a practical.

I've definitely been hit with version mismatches - but they're almost always a missing method errors. Now things like maven really solve this problem nicely (albeit not perfectly).