feature article
Subscribe Now

The Road from Java

Universal Portable Software Isn’t Doing Anyone Any Favors

“The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.” – F. Scott Fitzgerald

Watch any children’s TV show, from Daniel Tiger on your Roku to 30-year-old reruns of Sesame Street on VHS tape, and you’ll hear two messages loud and clear. One: We’re all the same. And two: We’re all different, unique, and special.

Which is it? And how do little kids reconcile these diametrically opposed viewpoints?

The same irreconcilable dichotomy exists in software development. Are all platforms the same, or are they all different? Can we have it both ways? Can we even entertain both suggestions in our heads at the same time?

From a programmer’s point of view, it would be great if all hardware platforms were the same. Same processor, same memory structure, same hardware peripherals, same debug environment – same everything. Programming any type of device would be like programming any other. You’re coding a thermostat one day and a nuclear submarine the next. Piece of cake. It’s just ones and zeros.

On the other hand, we want all devices to be different. An iPhone has different hardware resources than a web server, which is different from Watson or Deep Blue. Seems natural. Nobody wants a single, state-sanctioned, “approved” hardware platform that we all have to work around. Let creativity reign!

To reconcile these opposing demands, we have… fairytales. Mythological fantasies wrapped up in marketing hype (and hope), passed along as technical innovation. The hero of these stories is called the “portable application,” armed with a magically enchanted “virtual machine.”

It all sounds so lovely. We write an application once and it miraculously runs on anything and everything. No rewriting necessary. No pesky platform-dependent debugging. Heck, you don’t even have to know how big the target screen is – or whether it even has a screen – or whether there’s a mouse, or a keyboard, or a touchpad, or Wi-Fi… or anything! It’s all handled by the Fairy Godmother of universal virtual platform independence. Poof! Your wishes have all been granted.

These fantastical devices have gone by a lot of different names, from Java to Microsoft’s Universal Windows App (UWP) framework. They all promise more or less the same thing: write one program and watch while it runs on various types of hardware, including devices you’ve never seen or that haven’t been invented yet.

Trouble is, it doesn’t work. And it shortchanges the customer, which is an even bigger sin. Portable apps don’t really do anything for the end user; they’re a carrot on the end of a stick for the developer.

Portable Java code or UWP apps attempt to make themselves universal by creating a cocoon around themselves, an imaginary virtual machine hosted on a real machine, thereby abstracting away the messy details of the actual hardware. That’s an interesting academic concept, sort of like a simulation model, but it should end there. Nobody tries to actually ship the simulation model to customers. It’s supposed to be a development tool, not the actual product. Portable apps try to abstract away the usefulness of actual native code.

Take UWP. The idea is that Universal Windows Apps will run on a PC and a Windows Phone and an Xbox (and presumably future Windows-based devices), all without modification. The APIs allow you to ignore the existence of an Xbox controller, or a PC’s keyboard, or a smartphone’s touchscreen, among other things. So from the get-go, you’re ignoring the features that make each device unique. The very features, in fact, that probably helped it get sold in the first place. Who wonders, “Gee, should I get an Xbox or a smartphone? Doesn’t matter – they’ll run the same apps!” That’s like treating a bicycle and an airliner as interchangeable because, hey, they can both get you from San Diego to Portland.

Abstracting away the hardware differences seems like exactly the wrong thing to do, from a customer’s perspective. Why did I buy Device X if the software for it deliberately ignores the features and functions that make it unique? Why offer 31 flavors if they all taste like vanilla?

Universal programming models do more than just ignore unique features. They actively prevent their use. Microsoft’s UWP guidelines suggest that you’re welcome to write UWP apps for a specific platform (a Windows PC, for instance). But that doesn’t make the PC features any more accessible. UWP apps still don’t have access to the PC’s file system. They can’t run at startup, which PC programs have been able to do for, oh, 35 years. Drag and drop is severely limited. You can’t take advantage of dual graphics cards. In fact, your GPU drivers may not work, and your 3D tweaks will likely crash. Playing PC games? Good luck with that, because UWP abstracts away the stuff that makes a PC good for gaming, on the grounds that – boo hoo – they might not be available on other UWP platforms. The phrase “lowest common denominator” comes to mind. 

The other is “one size fits all.” Remember when that used to be a good thing? Now it’s deployed only in sarcastic mode, slamming products that are poorly constructed and not well suited to their purpose. Hello, universal applications, the cheap suit of the 21st Century.

Portable applications rely heavily on sandboxes – sequestered bits of virtual machine isolated from the real computer for safety and portability. They are, almost by definition, limited and with incomplete access to the hardware and the operating system. They’re baby-safe spaces with no sharp corners. It’s supposed to make them (and the apps they contain) safe. But it also makes them rubber-padded playgrounds. Instead of buggy (or malicious) code secretly infecting the host machine, it just asks permission instead. Click-fatigued users will blithely accept any request that an app pops up. Can you access my camera? Sure. My wireless network? Go ahead. My contact list? Go for it. And so on… The universal app is just as harmful as before. But now you get to blame the customer for it.

The very existence of sandboxes for anything other than testing underlines their limitations. What, your software is so unreliable that it has to be caged?

Even little kids know that it’s important to be able to play well with others. And that, while we all share certain basic traits, we also have important differences from one another. If “variety is the very spice of life, that gives it all its flavor,” then celebrate those differences. Don’t be like the mindless drones in the “1984” commercial. You didn’t choose your favorite products because they were bland and unremarkable. Don’t peddle vanilla when you can provide the spice. 

10 thoughts on “The Road from Java”

  1. I strongly disagree here mostly because the flip side is so wrong and this negates a basic tenet of computer which is further abstraction.

    I’m currently using Java (specifically Codename One) to build a mobile app and I’m pretty happy with it. Is it perfect?

    No. But it’s WAY better than the alternative of Objective-C or Swift for iOS, Android’s weird set of API’s/Tools & Windows technology du jour.

    Pretty much every game uses Unreal or similar Write Once Run Anywhere tools. It’s rare to see a game that isn’t written using such tools today.

    Java worked really well in the desktops in the day, yes there were MANY awful apps because people often use WORA to save on costs and then also save on design and engineering but that’s a project problem not a tool problem.

    While devices are precious little unique snowflakes they are still converging and today’s Android/Windows apps are far more similar to iOS apps than ever before. I’m talking about natively written apps.

    I haven’t seen a single tool that promises to target a watch with the same code you use for a phone and pretty much every tool (whether WORA or native) expects you to adapt your UI to tablets so I don’t see what you are driving at here.

    I think you looked at some badly written apps and concluded the tool is broken rather than the logical conclusion:

    1. The tools are immature.
    2. Developers use them to save money and build mediocre apps with them.

    When targeting native you might as well go all the way down to ASM. But I’m assuming you don’t. You follow the same trend of abstraction this industry has followed since its inception so these tools will take over because the need is big, obvious and growing.

  2. I wont go into the above too much. I ranted on this a few years back. I still think Java is useful and being used today.

    Recently I’ve been exploring the Unity3D Game engine for gui applications and demos that can run on many platforms. It’s geared toward games, but is so much more. There’s Oculus Rift api being used as we speak.
    By adding usb/serial or ethernet etc interfaces, you can interact with other embedded devices to make a more immersive environment. One guy I just read about now plays a scary game he developed and the lightning flashes within the game are enhanced with real world strobe lites.

    I can import a 3D model of a new product idea and interact with it when presenting to a customer. This is the way of the future!

  3. I find that – particularly with game engines like Unreal and Unity, portability is not one of the biggest benefits. Those engines bring incredible amounts of high-level capability to the app (3D renderers, physics engines, etc.), and I’d estimate they reduce engineering effort by 1-2 orders of magnitude.

  4. Agreed to all your points! it is a powerful graphics engine and fun.

    My newcomer benefit is that in writing a single unity code base that, with minor issues, the Unity code will build for multi-platform targets using unity kernel for each platform so that is similar to java’s goal. I can’t wait to get an VR set like Occulus-Rift or similar. I like that there is a huge forum and fan base for support. They did recently drop javascript( really a subset called unityscript ) in the intellisense for MonoDev and VisualStudio so I code mostly in C# now.


    For example: I can make a Home automation widget that shows my house in interactive 3D, click-zoom on items to control, from both my phone, PC, or Mac that looks the same across. Best Regards guys -Lee

  5. Pingback: binaural
  6. Pingback: day trading
  7. Pingback: zd porn
  8. Pingback: Aws Alkhazraji

Leave a Reply

featured blogs
Apr 16, 2024
In today's semiconductor era, every minute, you always look for the opportunity to enhance your skills and learning growth and want to keep up to date with the technology. This could mean you would also like to get hold of the small concepts behind the complex chip desig...
Apr 11, 2024
See how Achronix used our physical verification tools to accelerate the SoC design and verification flow, boosting chip design productivity w/ cloud-based EDA.The post Achronix Achieves 5X Faster Physical Verification for Full SoC Within Budget with Synopsys Cloud appeared ...
Mar 30, 2024
Join me on a brief stream-of-consciousness tour to see what it's like to live inside (what I laughingly call) my mind...

featured video

MaxLinear Integrates Analog & Digital Design in One Chip with Cadence 3D Solvers

Sponsored by Cadence Design Systems

MaxLinear has the unique capability of integrating analog and digital design on the same chip. Because of this, the team developed some interesting technology in the communication space. In the optical infrastructure domain, they created the first fully integrated 5nm CMOS PAM4 DSP. All their products solve critical communication and high-frequency analysis challenges.

Learn more about how MaxLinear is using Cadence’s Clarity 3D Solver and EMX Planar 3D Solver in their design process.

featured chalk talk

Accessing AWS IoT Services Securely over LTE-M
Developing a connected IoT design from scratch can be a complicated endeavor. In this episode of Chalk Talk, Amelia Dalton, Harald Kröll from u-blox, Lucio Di Jasio from AWS, and Rob Reynolds from SparkFun Electronics examine the details of the AWS IoT ExpressLink SARA-R5 starter kit. They explore the common IoT development design challenges that AWS IoT ExpressLink SARA-R5 starter kit is looking to solve and how you can get started using this kit in your next connected IoT design.
Oct 26, 2023