Cookie Notice

As far as I know, and as far as I remember, nothing in this page does anything with Cookies.
Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

2015/05/14

There are Two Javas

So, this happened...

On the one hand, I wrote this on a day when I woke up after watching this fantastic conference talk on Neo4J and RNeo4J from Nicole White before bed. This had served to stoke the fires of my Big Data / Data Science jones and had moved graph databases from the corner of NoSQL that I just didn't get to something I had the concepts for but needed to play with to understand.

On the other hand, I wrote this on a day where a tech in my lab was upgrading an instrument machine (a computer that controls a data-generating scientific instrument), and in the process, upgraded Java. This lead to that corner of the lab to enter a time of complete shutdown while nothing worked.

I told someone that day, saying "one of my users updated Java", and without any further explanation, he knew exactly what the problem was, exactly how bad it could be. "They didn't", he said.

This is not a case of me hating Java as a language. I mean, I do, but nobody is asking me to write it, at least not in this context. With Neo4J, I there are modules such as RNeo4J, serving as an interface between the database and the language you're doing your work in. I don't care what language MySQL or MongoDB are written in; I just care that they'll store my data and give it back when I need it.

The one thing that distinguishes Java is "write once, run anywhere"; you write it and compile it so it runs in a VM, abstracting away all connections to underlying systems. Except, there are systems created years ago, where the software was written for a version of the JVM that has been replaced and abandoned a long time ago, where they even deploy computers running XP that were built for Windows Vista or even Windows 7. These exist to some extent because for schools of engineering and computer science, you have to teach the basics of computing using something, and somewhere along the line, the go-to something for introductory courses became Java. So, if you're making complex, computer-controlled scientific instruments, you're needing to design for what students know, rather than spend time and money teaching them a new language as well as the interface to your science. And, because once you sell it, you don't get money for upgrading the interface, so you just don't.

That is my biggest fear. That running a big program to run a big program will tend to choke a computer is an issue, but not as big an issue in this case. It'd run on an older computer, but it's a far newer computer than I started to develop my Java hate on, decades ago. I mostly think that, in context of modern, well-backed projects like Neo4J and Cassandra, I wouldn't end up where I can't upgrade the JVM because it'll break my tools and but every time I use the mouse, a popup shows up saying I'm several major versions behind, and I couldn't download and store the "right" version for my software if I wanted to.

Those are the two Javas: The bright shiny one that promises a good future, and the previous version that keeps you stuck in the past.

2011/01/21

Java Interface issue that makes no sense to me

There's a Java tool I have to use, called Blast2GO. It's a Genomics thing and I'm very sure that program itself is not the problem, but it is the only reason I'm using Java. We run this on data wholesale, so we're waiting with bated breath for them to release a command-line interface or API for it, but until then, there's the GUI. And if you're repeating a GUI interface a couple dozen times in a row (easily), it becomes more and more likely that you'll forget something.

So, we're trying to automate it. We're using Sikuli. In a way, Sikuli is a wonder. It uses computer vision libraries to find and click things in a GUI environment. It has allowed us to automate much of the interface, which is a wonder.

In another way, it's totally wrong. GUIs are not a pipeable environment, and if you're going to automate something, command-line scripting is the simplest way. Stupid interface issues pop up rarely that way, while my wrangling with Sikuli is all about handling stupid interface issues.

And the most stupid, the most unsolvable stupid interface issue is this: I run Blast2GO on a Solaris server because that's where the data lives. So, I use X Windows to redirect the output onto my local machine. And right now, wherever I run it from, I lose the ability to navigate menus via arrow keys and move through open and save windows via tab. And, for the life of me, I have no idea why. But whenever I run it on those servers, I can't use those keys. This makes the scripting much harder.

Any idea why Java would be doing this to me? Is it a Solaris issue? A Java issue? An X Windows issue? Help!

2010/06/08

Need Help Automating a Java GUI App

When being passed to me, it was described as an "impossible task".

We get big ugly data in a digital form. There is a big Java GUI app that munges it and gives the data in understandable PDFs and tab-delimited formats, which we can then use, or pass to our clients to use.

We want to give the clients the same thing each time, and when there are lots of steps, it's easy for people to forget a step, which makes things inconsistent.

Obviously, we would love to put this in a batchable setup, but we don't really have any way to program with the underlying libraries. So, we have the Java GUI tool. Sucks to be us.

But the goal of automating this mess is still with us.

s/goal/impossible task/mx

I'm looking at a page of tools for testing Java GUIs, but I don't strictly want to test this GUI. I want to bend it to my will. I want to master it like a Jedi masters the wills of the weak-minded. I want to consistantly, first-time every-time, have it follow my every whim, even while I'm miles away and asleep.

To put it bluntly, I want to batch-slap that thing.

Any pointers? I'm running Ubuntu and Gnome right now, but if I can get something to work, I can get a Windows or KDE or Solaris or maybe even Mac to run it on. If I can get it to work.