feature article
Subscribe Now

U.S. Attacks Java

Homeland Security says it’s Zero Dark Thirty for the software

“Unless it is absolutely necessary to run Java in web browsers, disable it.” That’s the word from the U.S. Department of Homeland Security’s Computer Emergency Readiness Team, as posted two days ago on its website.

Ouch. It’s rough when your own government tells you that software is bad for you.

This isn’t the first time DHS has launched a drone strike on Java, either. Oh, no. This is just an update of an earlier post that warned citizens away from Java, saying that bugs in the program were being exploited to commit identity theft and other crimes.

Oracle (now the owner and keeper of Java) released an emergency update to Java after the first government wave-off. But DHS isn’t impressed. Even after the patch, they’re still telling users to jettison Java.

I almost feel bad for Oracle. They’re in a tough spot, what with the government warning people that their product is hazardous. If only someone at, say, Philip Morris could help them deal with this dilemma.

I’ll be honest: I’ve never liked Java, and this latest brouhaha just confirms my long-held bias. Java is a virus-implementation language, pure and simple. It’s slow, pointless, slow, needlessly complicated, slow, resource-hungry, and slow. It’s evidently buggy, too, but so is most software, so I can’t really whack Oracle for that. Oh, wait—yes I can. Java is enabling identity theft, credit-card fraud, and general malfeasance sufficient to attract a public warning from the Federal Freaking Government! That’s about as spectacularly untrustworthy as you can get.

It also seems supremely unnecessary to me. What is the point of Java again? Oh, yeah—to allow programs to run on any platform, anywhere, regardless of processor, hardware, or operating system. “Write once, run anywhere,” right? How’s that working for you?

Last time I checked, there wasn’t a single Java program anywhere that ran on every Java platform. I don’t think even the Java version of “hello, world” works everywhere. There are just too many variables, and trying to create an entire virtual machine on top of a real machine is like building a house of cards in a moving airplane. A biplane. While flying upside-down.

Since embedded designers generally know what hardware/software platform they’re targeting, they have no particular need of Java. On the contrary: Java just adds another layer of software, indirection, and unpredictability between them and their system. Platform-independence, if it even existed, is largely irrelevant.

At the other end of the spectrum, we’ve got desktop programmers targeting PCs, Macs, the occasional Linux box, and whatever other desktop environments still exist. They also know their platforms pretty well. PC architecture hasn’t changed in a couple of decades (it just seems like centuries), and Mac APIs are pretty well-understood. So what incentive do these guys have for chasing platform independence? There’s a reason we don’t see Java-based games or serious applications.

In the middle we have smartphones, most of which run Android, most of which run third-party apps, most of which use Java. With the plethora of different Android-based phones, I can see the allure of Java for reaching the largest customer base possible. But doesn’t that putative independence also exact a big toll on performance, capability, and size?

For most embedded developers, efficiency is important. Maybe not the most important thing—that would be schedules—but right up there near the top. Reliability is also key, and for life-critical systems, the overriding concern. And cost. And determinism. And so on. None of which bodes well for Java in embedded systems. To host Java, you need a biggish system, a lot of memory, and a lot of patience. It’s fine for adding clever animation to the occasional web page, but it’s a poor excuse for a real platform when developing embedded systems.

And according to the guys who tap phones and chase terrorists for a living, Java’s also a security risk. In this case, I’m inclined to agree. 

7 thoughts on “U.S. Attacks Java”

  1. Hi Jim, I whole hardheartedly disagree. I switched a lot of my applications written for Visual C++ over to java because I go tired of being forced to adhere to microsoft’s
    pWhimOfThis->year. I invested in MFC coding at Qualcomm, then MS started advertising Java as the next big thing in Help, showing analogs of the Classes for both languages, then the big .net / java fallout. And now we have to drink the coolaid of silverlight and whatever they think we should conform to next. I currently program in MS C++ and Java about 50/50 for my daily needs.

    Many of your blanket statements about Java not working out, or not used in major applications are screaming that you don’t really know much about Java. Sorry I like you, but disagree.

  2. The original JDK 1.0 security model was to create a “sandbox” for unsecured/untrusted code.

    However, that was abandoned, and in the end, network loadable Java applications with extensive system access, became click to install (and bypass all security) as the accepted norm.

    Sorry … time for Java to go, because the designers forgot the stated security part of it’s mission (which was the justification for it’s existence), and created yet another malware vector for small children (and non-technical trusting adults), with to click to install Trojans along with their desired games or activity.

  3. You do not appear to make any distinction between Java and JavaScript, quote: “It’s fine for adding clever animation to the occasional web page…” The DHS concerns seem to be about Java and not JavaScript (specifically mentioning browsers with a Java plug-in). Can you please clarify?

  4. Dyson: I don’t think anyone is complaining about JavaScript … It’s not Java at all, does not require the java VM, and doesn’t have the features that create the security problems.

  5. Studley-

    What I’m hearing is that Java is better than Microsoft. You’ll forgive me, but that’s faint praise. Microsoft’s attitude toward APIs is all over the map, as you point out. Multiply that frustration for embedded development.

    As a third option, there are many embedded operating systems that have solid APIs, deterministic performance, good development tools, and zillions of working installations. Express Logic, Green Hills, Micrium, LynuxWorks, and dozens of others have many happy customers, and all without either Java or Microsoft.

  6. Hi Jim, Not exactly saying that. I do use both daily for my own PC based apps and utilities.
    Each has its strengths, but Java has a better track record for not pulling the rug out and forcing a new porting effort for older tried and true programs I’ve written in the past when I revisit them to add a feature.

    For Embedded( whole different animal ), I have used many of the ones you mention. I like rolling my own for simple things( state-based ) and Micrium(uCos) from Jean Labrosse has great documentation. We used(and debugged) Mentor’s Arm offerings at Hypercom. I have a BlueCatRt diploma from LynuxWorks.
    See:
    http://www.infoworld.com/d/application-development/java-tops-c-in-language-popularity-assessment-not-much-185808?source=footer

    I just think a blanket statement saying Java is not popular( sorry, it’s one of the most widely used languages out there.) and should go away used is not good and reeks of some SW-political overtones.
    Java’s ability to escape the browsers control IMO is a failure of the browser’s sandboxing or JavaEngine implementation and yes Oracle needs to fix some things, but an exploit can be written in any language. Both Java and Javascript are being targeted( as opposed to some odd claims above ) and I challenge you guys to disable it in your browsers and surf. Many sites like Google, Gmail and others will not work in any but the most basic modes. It’s a good discussion but I ask you all to be open minded. Thx -Lee Studley

  7. an article “Java security settings can be ignored by malware” in infosecurity is pretty blunt.

    For me it’s pretty difficult to trust the engineers and company behind a product that is sold based on the foundation of being a secure sandbox, that is anything but secure. Freckin clueless.

    So are the developers that are still claiming sand box security exists.

Leave a Reply

featured blogs
Oct 26, 2020
Last week was the Linley Group's Fall Processor Conference. The conference opened, as usual, with Linley Gwenap's overview of the processor market (both silicon and IP). His opening keynote... [[ Click on the title to access the full blog on the Cadence Community s...
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through-hole products, or a single or double row surface mount with a larger centerline rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and con...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...
Oct 23, 2020
Any suggestions for a 4x4 keypad in which the keys aren'€™t wobbly and you don'€™t have to strike a key dead center for it to make contact?...

featured video

Better PPA with Innovus Mixed Placer Technology – Gigaplace XL

Sponsored by Cadence Design Systems

With the increase of on-chip storage elements, it has become extremely time consuming to come up with an optimized floorplan with manual methods. Innovus Implementation’s advanced multi-objective placement technology, GigaPlace XL, provides automation to optimize at scale, concurrent placement of macros, and standard cells for multiple objectives like timing, wirelength, congestion, and power. This technology provides an innovative way to address design productivity along with design quality improvements reducing weeks of manual floorplan time down to a few hours.

Click here for more information about Innovus Implementation System

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

Featured Chalk Talk

Accelerate the Integration of Power Conversion with microBUCK® and microBRICK™

Sponsored by Mouser Electronics and Vishay

In the world of power conversion, multi-chip packaging, thermal performance, and power density can make all of the difference in the success of your next design. In this episode of Chalk Talk, Amelia Dalton chats with Raymond Jiang about the trends and challenges in power delivery and how you can leverage the unique combination of discrete MOSFET design, IC expertise, and packaging capability of Vishay’s microBRICK™and microBUCK® integrated voltage regulators.

Click here for more information about Vishay microBUCK® and microBRICK™ DC/DC Regulators