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
Dec 19, 2024
Explore Concurrent Multiprotocol and examine the distinctions between CMP single channel, CMP with concurrent listening, and CMP with BLE Dynamic Multiprotocol....
Dec 24, 2024
Going to the supermarket? If so, you need to watch this video on 'Why the Other Line is Likely to Move Faster' (a.k.a. 'Queuing Theory for the Holiday Season')....

Libby's Lab

Libby's Lab - Scopes Out Silicon Labs EFRxG22 Development Tools

Sponsored by Mouser Electronics and Silicon Labs

Join Libby in this episode of “Libby’s Lab” as she explores the Silicon Labs EFR32xG22 Development Tools, available at Mouser.com! These versatile tools are perfect for engineers developing wireless applications with Bluetooth®, Zigbee®, or proprietary protocols. Designed for energy efficiency and ease of use, the starter kit simplifies development for IoT, smart home, and industrial devices. From low-power IoT projects to fitness trackers and medical devices, these tools offer multi-protocol support, reliable performance, and hassle-free setup. Watch as Libby and Demo dive into how these tools can bring wireless projects to life. Keep your circuits charged and your ideas sparking!

Click here for more information about Silicon Labs xG22 Development Tools

featured chalk talk

Implementing Infineon's CoolGaN™: Key Essentials and Best Practices -- Infineon and Mouser
Sponsored by Mouser Electronics and Infineon
In this episode of Chalk Talk, Zobair Roohani from Infineon and Amelia Dalton explore the fundamentals and characteristics of wide band gap materials. They also investigate why the higher band gap and higher electric field withstanding capability of GaN brings us closer toward that ideal switching technology and the unique design challenges one must pay attention to when driving GaN devices.  
Dec 12, 2024
6,756 views