Archive for the ‘java’ Category

I was warned

Tuesday, August 13th, 2013

I was warned about getting back into PHP, but I didn’t listen, and now I have to solve silly problems created by the language trying to be ‘helpful’.


PHP doesn’t cast a string into an integer, unless it thinks it needs to, and vice versa.  If you are just working in PHP, that probably won’t bite you on the butt too often.  But if you need to integrate with another language, like say Java, because you are using PHP and selenium together in a BEHAT environment, you might get an error like,  Can’t convert java.lang.String to int

Which you have to solve by doing

function ITakeAnInt($mynumericstring)   // called with a paramter of  500;


  $mynumericint = $mynumericstring + 0;



Seriously, if you can think of a less silly way to solve the lack of an explicit cast function in PHP, I’m all ears.

Strange GWT compilation error resolved

Tuesday, April 16th, 2013

One of the projects at work is built using the Google Web Toolkit framework.  I have been focusing on other projects for a while, since well before we moved offices, so when I recently had to start working on the web side again, and my build was failing, my first assumptions were environmental, and in a way, it turns out I was right.


The error was,

<H>addHander(<H>,H) in cannot be applied to (<<?>>,

But, after much mucking about with version control settings, sure that there was some stale file issue at work, my co-worker pointed out that when dev had upgrade the GWT toolkit they build with, they also moved from building with java 1.6, to 1.7.  And sure enough, a couple of short upgrades later, and both of my build machines were happy again.  Or at least as happy as any test environment ever gets.

Java update quality control

Monday, September 17th, 2012

It’s a small thing, as bugs go, but I couldn’t help but notice that, when you uninstall Java 6_35, the uninstall window says “6_33”. little d’oh on Oracle’s part.

UTF-8 and od

Wednesday, June 13th, 2012

One of the many challenges of my current job is trying to create tests that will function the same, across 30+ flavors of UNIX-y-type systems. There are lots of seemingly simple things that just don’t work the same way for AIX, HPUX, Solaris, and the various Linuxi we support. Sometimes even on the same OS family, changing processor architecture leads to unexpected issues. Eventually I figure most of them out, or at least a way around the differences that are irrelevant to my testing.

Today’s challenge, validating UTF-8 support for filenames. Not entirely unexpected, piping UTF-8 strings through STAF via Java, into local system grep utilities isn’t providing consistent results. Entirely unexpected, the octal-dump program, ‘od’, is returning different results for the same source file, depending on the host machine, completely independent of my STAF issues.

64-bit IE9 testing

Thursday, May 31st, 2012

As part of the new project at work, I’m building a stable of every possible combination of browser and OS. Even with our fancy-schmancy virtual machine lab, it still takes an annoying amount of time, made more tedious by how it turns out that there are significant differences in how 64 and 32 bit IE9 handle certificates and java applets.

Under a 32-bit IE9, when you visit a website with a self-signed certificate, and java applet, you are presented with warnings, but are allowed to load the app. Under 64-bit IE9, you aren’t allowed to load the app at all. I continue to investigate.

UPDATE: Interesting, the problem goes away with java 7 installed instead of java 6. Of course I didn’t write the product requirements, so it really may have just shifted the problem along the road a bit =p

You are not helping

Thursday, April 5th, 2012

Me: I need you to move this call to fnX(), because it calls GWT.create, into the view layer, instead of the presenter layer.
Dev: Here, I replaced the call to fnX() with a direct call to GWT.create, still in the presenter layer.

When running under cargocpc, html is missing some ID fields

Friday, March 16th, 2012

Today’s inexplicable quirk:

I have a javaee webapp, deployed to a Jetty server, which I’ve written some HtmlUnit tests against. When I compile and start the app via “mvn jetty:run-war”, on my dedicated webapp-host machine, everything works great. When I compile and start the app via “mvn integration-test” on my development machine (where my maven project already has the cargocpc stuff integrated to spin up a temporary jetty server and deploy my war file to it…it works just fine for some other tests I’ve written), the webpage that it offers up is missing ID’s for some of the key elements, but not for other elements on the same page.

I could probably re-write the tests to find the elements I need via some other means, but I’d like to know what’s going on with their ID’s going missing first.