Dave Butler

Greenhorn
+ Follow
since Jul 19, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Butler

Hi

Quick google search led to this link:

http://forum.java.sun.com/thread.jsp?thread=329241&forum=54&message=2459095

Reports the same error code, discusses the problem, hope it helps

Dave
15 years ago
Homer,

Depending upon your definition of reality, last time I checked I was for real. I think. Or was that just an illusion? Thanks for your concern, I guess you are a "I care about real people" sort of person. Well done!

To your other points. Yes, he did make a six-figure salary (and benefits). And yes, he did have difficult to find experience and skills. And no, my post wasn't any sort of bait (or so I thought). And I repeat, this recruitment happened a while back. He has since moved on to pastures new.

The point I was trying to make, perhaps too obliquely, is that under current legislation if a qualified US citizen (or resident alien) is available for a given position you CANNOT sponsor an H1B. You have to advertise. And you do get a shed load of resumes. (You also must pay at least the going rate for the job; anyone paying 80% of the going rate to an H1B is breaking US law.)

In a perfect world, if one of the local candidates is suitable, they get the job. However, determining who and who is not qualified is subjective. So if a company really wants to get their hands on that certain special someone they will. For example, if you decide you need to hire the leader developer of whatever, and he happens to be French, you go get him. Regardless, done properly, it is a long, drawn out and expensive process.

I did a stint in the UK. Four years ago it was not uncommon to see listings on the UK job boards for "multiple programmer jobs - Silicon Valley". Not so many now though. I guess there are more than enough of us home-grown developers to fill the available berths. For now.


Dave
15 years ago
We recruited a UK citizen a while back. It was not a cheap option - lawyers (and you have to have one because like every other law in the US, immigration law is complex) do not come cheaply, relocation is very expensive, AND you have no guarantee that your shiny new employee won't hop off to someone else (this is not India!).

Supply and demand rule. For a while now, supply has outstripped demand - one of the hoops an employer has to jump through for gaining approval for an H1B application is to provide proof that no suitably qualified local US citizen was available for the work. Standard practise is to advertise. Guess what happens - you get an avalanche of impressive looking resumes.

So, until demand begins to outstrip supply, forget about H1B visas in the IT field. Moreover, if memory serves me correctly, IT guys are in competition with nannies and nurses. Congress only increased the quota because of the huge IT demand of the late 90s, and haven't wasted much time in reducing it again. Does anyone expect those heights to return anytime soon?
15 years ago
Use a servlet to write the JAD - then you can put whatever you like in the UID attribute

Best Regards

Dave
15 years ago
Here's one way of doing it: hash a passcode and store it as a custom attribute in the JAD file. In the MIDlet startup code, get the user to enter the passcode, hash it and compare to the JAD attribute's value. For a secure solution use MD5. And consider avoiding annoying the user by flagging a successful entry of the passcode in an RMS store (and check that flag on subsequent application starts). All of this adds a few KBs to MIDlet's JAR size.

As a suggestion, use numbers for a passcode - users understand the concept of a PIN.


Hope this helps

Dave
15 years ago
You can also set up Eclipse to handle J2ME development.

It is really simple: remove the reference to the JRE in the Libraries tab of the Java BuildPath for your J2ME project and replace it with the midpapi.zip (from the WTK104/lib directory) or the midpapi10.jar/midpapi20.jar (from the WTK21/lib directory).

Then call up antenna tasks via ant and you are off!

Dave
15 years ago
This woke up a couple of neurons. If they serve me correctly, we had that error a while back when using Antenna 0.9.11.

Everything was fine with Antenna 0.9.10/WTK1.0.4/J2SE1.4.2_03 on Linux (SUSE 9.0). But moving to Antenna 0.9.11 caused the error. At the time the little digging around I did suggested that with 0.9.11 Jorg (Antenna's author) changed the WtkPreverify Ant task to have a new JAVA_HOME variable to try and fix some strange preverification issues that had something to do with the bin/jar executable. I don't know if the current Antenna 0.9.12 has the same issue, because, err, I'm (still) happy with 0.9.10, and I'm leaving well enough alone!

Since you find that preverificiation via WTK works, you might try using Antenna 0.9.10 and see if that fixes the problem.

Hope that helps - came across this in January - but still remember the frustration. I can't even remember if I fired off an email to Jorg (oops)

Dave
15 years ago
That's what we do - we deserialize preference properties from a specific RecordStore to a Hashtable, and then serialize from the Hashtable when saving (using DataStreams so all the key:value pairs end up in a single record). If the RecordStore doesn't exist - no worries, we just handle the null when trying to read a specific preference from the Hashtable.

We avoid any problems with having more than one record by reserving a specific RecordStore for preferences and using other RecordStores for non-preference data. We haven't yet found the need to specifically assert the presence of only one record...

All of this functionality sits in a small class that only exposes a getProperty(key), a setProperty(key, value) and a save() method, so the rest of the app has no idea there's a RecordStore involved. We initialize the preferences Hashtable when constructing the class during MIDLet startapp(), and make sure the preferences get saved during shutdown.

Hope this helps
15 years ago
Hi,
Nope - you can't write a text file, but there are work-arounds:

1. Use resource bundles (read-only at runtime)
2. Use custom attributes in the JAD/JAR (RO at runtime)
3. Use a network connection and cache into an RMS (RW at runtime)

All 3 work, other there are some gotchas:

1. The MIDP 1 spec defines the RMS size as 8 KB (yup 8 KB), although the phone manufacturers usually give you a little more to work with - typically Nokia is 20 KB. The MIDP2 spec ups the minimum to 30 KB, but again manufacturers generally provide more.
2. Bear in mind resource files get packaged into the JAR - and there is a limit on JAR size. Best advice for MIDP 1 is around 50 KB, but some phones are less, some a more. "3" phones are a particalur pain.
3. We have also found a combined JAR + RMS size limit. Can't remember what it was because we work with a 35 KB JAR/20KB RMS limit.
4. Use an obfuscator.
5. Haven't found any particular problems with using custom attributes, but we haven't tried to max out JADs so don't know the edge of the size envelope.

Best Regards

Dave
15 years ago