Other

A Baffling Android Security Update Policy

/ Neil Wilson

Google is maddeningly schizophrenic when it comes to security. They were early adopters of two-factor authentication for their online services, and they offer multiple ways for obtaining that second factor (including at least TOTP, SMS, voice call, and U2F). Yet you can’t always require two-factor authentication when logging into a Chromebook, and it doesn’t seem like there’s any two-factor authentication scheme for logging into mobile devices. I’d love the option to require both a passphrase (or at least a reasonably long PIN) and a fingerprint, but enabling the fingerprint reader for any purpose (even if you just want to use a fingerprint as a second factor in an app) automatically makes your phone unlockable with just a fingerprint. That’s insane.

Their lack of decent VPN support for Chromebooks also boggles the mind. Unless you’re willing to jump through some very ugly hoops (like using Crouton to set up a Linux sandbox, diving deep into Chrome OS configuration internals), you’re limited to L2TP, which is vulnerable to man-in-the-middle attacks. For devices that are intended to be used on the go with a network connection, presumably through some WiFi service that you don’t control (and therefore have a much greater risk of having someone snoop on your communication), good VPN support is absolutely critical. And even if you can get a working VPN and you’ve got a Chromebook that supports running Android apps (which I’ve got to admit does make Chrome OS much nicer), good luck getting those apps to use the VPN for their communication.

But today I encountered something that seems to take dumb to a new level. On Monday, Google released an Android Security Bulletin about new security vulnerabilities, including “a Critical security vulnerability that could enable remote code execution on an affected device through multiple methods such as email, web browsing, and MMS when processing media files.” So in theory, someone could send you a text message with a media attachment and take over your phone. That seems like a pretty big deal. So I went to see if there was a system update for my phone (a Google Pixel XL), and there was. So I clicked to download it, and I got an error message saying “This update can be downloaded via a WiFi network only until May 6. To continue download, connect to a WiFi network.”

What? This doesn’t make even the tiniest bit of sense. Why is this critical security update only available if you’re connected to WiFi? Why does Google care if I want to use my mobile data to download the patch? And what’s special about May 6 that all of a sudden will make it okay for me to download it then? It’s not like it costs Google any more money if the data ultimately ends up on the phone via 3G/4G/LTE than it does via WiFi. Even if I were using Google’s Fi service for my mobile data (and I’m not), I’d have to pay for the data that I used because Google Fi doesn’t have any kind of unlimited data play (it’s a flat rate of ten dollars per gigabyte, and it would actually be in their best interests to get people to use as much data as possible).

I can absolutely understand warning the user about using mobile data for a potentially large file (this update was about 60 megabytes) and wanting to get the user’s okay before starting the download. That would be a good thing. If you have a mobile data cap, or if the size of your bill depends on how much data mobile data you use, then, of course, you’d want to be warned about doing something that could use a significant amount of data. But this wasn’t a warning message that I could simply dismiss and get on with the download. This was an error message that told me that I just plain couldn’t get the update unless I connected to WiFi or unless I wanted to wait (and remain vulnerable) for several more days.

In the interest of security, I did kowtow to this stupid demand, and I downloaded the update over WiFi (secured by VPN). But if I’d been traveling somewhere where I had good mobile data coverage but WiFi wasn’t readily available, then I’d have been stuck either needing to find somewhere I could leech (or pay for) a connection, or remain vulnerable for a few more days (during which time I’m sure there would be plenty of bad guys trying to reverse-engineer the update and figure out how to exploit the vulnerabilities that it fixes).

Seriously, Google. Do security better.

The Problems with Twitter’s Automatic URL Shortening

/ Neil Wilson

At the beginning of 2010, I decided to start writing up my thoughts on all of the first-run movies that I see in the theater. It’s debatable about whether those reviews are any good, but I know that at least some people read them. All of my reviews from the last year and a half are available at http://www.viewity.com/.

Last Thursday, I saw (but did not particularly enjoy) J.J. Abrams’ new movie Super 8, and last night I finally got around to writing my review of it, which I posted at http://www.viewity.com/reviews/super-8.html. I use Squarespace to host the reviews, and one of the services it provides is the ability to define a shorter URL that can be used to reference the content. I took advantage of this and created the path “/Super8” instead of “/reviews/super-8.html”. Squarespace also offers support for using multiple domains with the same account, and I have “vwty.us” in addition to “viewity.com”. What this ultimately means is that going to “http://vwty.us/Super8” will take you to “http://www.viewity.com/reviews/super-8.html”.

Whenever I post a new review, one of the ways I let people know about it is by Twitter. The whole reason that I offer the shorter version of the URL is that Twitter limits posts to a maximum of 140 characters, and at 21 characters, the short version of the URL is less than half the size of the 43-character long form. This gives me more space to say something about the movie in addition to merely providing the link, and I try to give at least a hint about whether I liked it. For Super 8, the tweet that I composed was:

Super 8 is super underwhelming. http://vwty.us/Super8

However, what actually got tweeted was:

Super 8 is super underwhelming. http://t.co/TZ43SmY

I will grant you that what Twitter actually made available on my behalf is a whopping two characters shorter. However, it is also much worse than what I had originally written, for many reasons.

First, it’s completely unnecessary. As I mentioned before, Twitter places restrictions on the length of your tweets, but I wasn’t anywhere near that. What I originally wrote was 89 characters, which means that I could have written up to 51 more characters before running out of space. I could have even used the original 43-character URL if I had wanted to and still had plenty of space left.

Second, Twitter’s change dramatically obscures the URL. From the URL that I provided, you can tell that it goes to the vwty.us domain (which is a brand that I control and want to be associated with), and the “/Super8” path gives you a pretty good idea what it might be about. On the other hand, with what Twitter actually provided, you can see that it goes to the “t.co” domain (which is known to be a redirect farm so you have no idea where the content actually resides), and the path “/TZ43SmY” tells you nothing about the content. The original URL is very useful. The shortened version is not.

Another significant problem is that the new URL shortener can have a dramatic impact on the availability of your content. Twitter has such a bad reputation in this area that their “fail whale” page is a well known Internet meme. Because a click on the shortened URL must go through Twitter’s servers before sending you to the ultimate destination, if Twitter is having a problem then it can make your content unavailable. As if by fate, when I clicked on the t.co link earlier this morning, I got exactly that failure page telling me that Twitter was over capacity. Nice. Even if it had worked, it still requires an extra HTTP request and more data over the wire, and an unnecessary delay in getting to the actual content.

The requirement to go through Twitter’s service creates even more ways that the content could become unavailable. It’s likely that tweets will outlive Twitter itself. They’re being archived in the Library of Congress (in addition to a number of other sites), and although future generations probably don’t care how I feel about a movie, there could be long-term value in tweets, and links contained in them. If Twitter goes out of business or is otherwise shut down, then their links won’t work anymore even if the content they referenced is still available. Also, it’s worth pointing out that the “.co” TLD is controlled by the government of Columbia, and that government can shut down such URLs at any time. The government of Lybia has done this for “.ly” domains, so it’s certainly not beyond the realm of possibility.

Twitter’s reason for providing this service is that it can “better protect users from malicious sites that engage in spreading malware, phishing attacks, and other harmful activity”. While this sounds noble, it is also completely ineffective against everyone except the most extreme idiots. They’ve already stated that they won’t shorten URLs that were already shortened using other services like bit.ly, so there’s nothing to prevent people doing suspicious things from using one of them for their posts. Further, there’s nothing to prevent me from serving up different content from my server when I can see that the request is coming from Twitter’s malware detection service versus some other content, so I could still serve up bad stuff to people following the links. On the other hand, the fact that they are trying to verify that content is safe introduces a very real possibility for false positives. My site could have completely legitimate and safe content, but if Twitter thinks that it’s bad for some reason then that may significant inhibit the likelihood of people to go there. Given the unacceptably high percentage of false positives I see from other services like this (e.g., Google mail’s spam detection frequently flags things that aren’t spam), this is far from an impossibility.

Finally, in the ultimate act of inanity, Twitter’s URL shortener can actually produce URLs that are longer than the original URL. For example, when I entered a URL of “http://t.co”, Twitter “shortened” it to be “http://t.co/IzZPmi2”.

I realize that Twitter will show an expanded version of the URL in its web interface, but that doesn’t work for alternate clients. For example, when I use Seesmic on my Android phone, I get the t.co version. And even if I’m using a client that automatically expands that URL, it will only work if the shortening service is available.

Great job, Twitter. This “feature” that I can’t disable has made my links less available, less recognizable, and more likely to be flagged as malicious content. I don’t need any more hurdles to have to get by for people to read the useless drivel that I write.

Please End MLB Blackout Restrictions

/ Neil Wilson

I’m a big baseball fan, and I love the St. Louis Cardinals. Since I live in Austin, about 900 miles away from St. Louis, I only get to Busch Stadium about once a year while I’m visiting family in Illinois. Whenever the Cardinals play the Astros (which was twice last year, and twice again this year), I make the trip to Houston to see them there. But that’s about the extent to which I can see them in person. Since their games aren’t televised around here as much as they should be, and since I’m often at work during most of the games, I don’t get to see them on TV much more than I do in person.

For the last two years, I’ve also subscribed to MLB.TV, which provides live video of the games while they’re in progress, and there’s an archive that gives you access to any all games played so far in the season (although it’s definitely not as fun watching a game that’s already been played because it’s impossible to keep from finding out who won). They also have a deal with Roku, so I can use it to watch the games on my TV, either live or already completed. At $120 per year, it’s expensive, but most of the time I think that it’s worth it. This week isn’t one of those times.

In my opinion, the only real down side to MLB.TV is the blackout restrictions that they impose. In theory, the blackouts are supposed to encourage people to go to the games, but in reality they’re just plain stupid. I can’t think of a single good reason for them to exist at all, and especially not when I’m already paying so much for the streaming service. However, it seems like their restrictions go far beyond what is reasonable. The restrictions include:

  • All games on Saturday afternoon are blacked out, no matter what.
  • All games on Sunday evening are blacked out, no matter what.
  • Some additional games are blacked out based on your location.

The first two of these are pretty frustrating, and I’ve been bitten by both of them already this week because the Cardinals played on both Saturday afternoon and Sunday evening, and I couldn’t see either one. However, the location-based restrictions seem to be even more frustrating. For me, because I’m in Texas, they basically prevent me from seeing any game in which a Texas team is playing. This week, the Cardinals are playing the Houston Astros, so I can’t see them. This is despite the fact that the game isn’t taking place nearly a thousand miles away, so there is no reasonable opportunity for me to see it in person (and even if they were in Houston, that’s still over three hours away from where I am).

I guess I’m one of the “lucky” ones, since I don’t live anywhere near my favorite team. If I did, then I might not ever be able to see them live, and I can’t see how anyone would justify the cost of MLB.TV if they couldn’t ever see their favorite team play live. And apparently these restrictions are even worse for people who don’t have any reasonable access to see any games at all. For example, people living in Des Moines, Iowa can’t see any games in which any of six teams is playing (Brewers, Cardinals, Cubs, Royals, Twins, or White Sox), despite the fact that Iowa doesn’t have any professional teams and Des Moines is over three hours away from the nearest of those cities and nearly seven hours away from the farthest.

Major League Baseball: I beg of you, please get rid of these restrictions. I promise you that you’ll make more money, and you’ll have happier customers. There are definitely people who won’t subscribe at all because of these restrictions, and others who opt for a much cheaper audio-only subscription since they aren’t subject to blackouts. It’s also a lot easier for people to support their teams (and spend money doing so) if they can actually watch them play. There are a lot of really good reasons to get rid of the blackouts and no good reason to keep them.

SLAMD 2.0.1

/ Neil Wilson / 1 Comment

I have just released a new version of SLAMD, version 2.0.1. It is available for download at http://www.slamd.com/. The release notes provide a pretty complete list of the changes included in this release, but some of the most notable updates include:

  • The code used to generate graphs has been improved in a number of ways. Various font sizes and styles are now used to make elements of graphs stand out, and antialiasing has been enabled for the text. The thickness of lines in line graphs has been increased and a light gray background is used for the plot area to help make the lines easier to see, especially for light colors like yellow. Also, the default graph size has been increased from 640×480 to 800×600.
  • When scheduling a job, the job duration and/or statistics collection interval can be specified in a more human-readable format. You can still use the number of seconds like in the past, but you can also use more user-friendly forms like “6 minutes”, “1 hour”, or “1 day 12 hours”.
  • A new version of the NetStat resource monitor is available that provides a number of bug fixes and increased functionality. It is now possible to configure the set of interfaces to monitor and/or to have statistics aggregated across the monitored interfaces.
  • The HTTP GetRate job has been updated so that it provides the ability to authenticate to a proxy server.
  • A bug has been fixed that could cause a problem with the use of the HTTP client if the response does not include a Content-Type header.
  • A bug has been fixed in a number of LDAP-related jobs that could cause them to behave incorrectly if a value pattern was specified using a sequential pattern. That pattern could be repeated by all threads on the client, instead of having the same range shared by all threads so that each value was used by only one of the threads.
  • A bug has been fixed in a number of jobs that could prevent statistics from being collected if a cool-down time was provided but no duration or stop time was defined.
  • Jobs providing rate-limiting capabilities have been updated so that you can control the period of time over which the rate limiting is enforced. This can be used to help make it more reliable over time, with the trade-off of occasionally exceeding the rate limit for a brief period of time to make up for periods of slower activity.
  • New jobs have been added which can be used to perform asynchronous LDAP search and modify operations with multiple concurrent outstanding requests on client connections.
  • The LDAPDecoder tool has been updated to provide the ability to decode LDAP traffic from snoop or tcpdump packets in which LDAP messages do not exactly align with packet boundaries (e.g., packets containing multiple messages, and/or messages spanning multiple packets). Also, when generating a SLAMD script to reproduce the LDAP communication, it is now possible to exclude information about server responses.

A new “PlugProfile” Android app

/ Neil Wilson

Ever since I got my Droid working properly, it is by far the best phone that I’ve ever had. However, one notable deficiency is the fact that it lacks a good way to change ring profiles. There are a lot of applications in the Android Market that can help with this, but none of them did exactly what I wanted, so I decided to write my own.

Several years ago, I got an LG V phone, and it had a really nice and sensible feature that made it possible for you to change how it behaved when a call came in based on whether or not it was plugged in, and I used that to configure the phone to vibrate when it was unplugged (and presumably in my pocket) but to ring at maximum volume when it was plugged in (and obviously not in my pocket).

A couple of years ago, I traded in my V phone for a Blackberry. It didn’t directly support changing the ring profile based on whether it was plugged in or not, but it did support changing the profile based on whether it was in the holster. Since I carried the phone in my pocket and didn’t use the holster, that was good enough because I could put it in the holster whenever I plugged it in to achieve the same effect.

Late last year when I upgraded from the Blackberry to the Droid, it was an upgrade in nearly every way except ring profile management. The phone itself comes with basically nothing for changing the way it rings under different conditions. There are a lot of apps in the Android Market that try to address this problem, and there are some pretty inventive solutions like using information about your location or based on the time of day. However, none of these were a very good fit for my needs. I ended up using “Quick Profiles”, which just let you create different profiles and then manually switch between them, but that wasn’t ideal because I found that I frequently forgot to change the profile when unplugging my phone and putting it in my pocket in the morning and taking it out and plugging it back in in the evening, so it was frequently configured to ring when I didn’t want it to, or vibrate when I wasn’t around to feel it.

The model exhibited by the V phone was just about perfect for me, so I decided to go ahead and write an app to do that for Android. It was a pretty quick and painless process, and the app is now available for free in the Android Market with the name “PlugProfile”. It provides the ability to automatically set the phone to silent mode, vibrate-only mode, ring-only mode, or ring-and-vibrate mode based on whether it’s on battery, on AC power, or on USB power, and if ringing is enabled, you can set the volume from anywhere between 10% and 100% of the maximum volume in 10% increments. I have my phone set to use vibrate-only mode when it’s on battery, ring with 100% volume when it’s plugged into AC power, and ring with 50% volume when it’s plugged into USB (of a presumably nearby computer). It doesn’t mess with your ringtone, so if you’ve got different rings for different people, then that should still be preserved.

Another week with the Droid

/ Neil Wilson / 1 Comment

When I last posted, things weren’t looking so good for my use of the Droid, and I had pretty much convinced myself that I was going to have to swap it out for the Eris. Fortunately, I didn’t do that and instead decided to give it another shot. I did a factory reset to wipe everything and start fresh, and then I proceeded very slowly. Rather than installing the somewhere around 40 apps that I previously had all at once, I started to trickle them over a period of several days, and I also switched things up a bit by choosing alternatives to what I previously had when there was a feasible other option. I’m happy to report success this time, and I haven’t had a crash or reboot all week.

Now that it’s stable, my fanboi status is back in full force. I really love this phone. It’s really fast, the display is incredible, the already-good browser is much improved over the G1, and I’m even starting to accept the crappy keyboard (and I actually typed much of this post on it while standing in line to see Lars von Trier’s Antichrist). I’ve used the car mode and Google Maps Navigation a few times, and I’m very happy with it, and find it a significant improvement over the VZ Navigator app I was previously using on my Blackberry. The voice search has never misunderstood me, which is really impressive.

Last night, I finally got up the courage to try putting the UnboundID LDAP client on it to test it out and it works just as well as it did on the G1 (actually, quite a bit better because it’s faster and on a better network). I hope to give it a much-needed update and make it available in the market in the near future.

A Week with the Droid

/ Neil Wilson / 2 Comments

At the beginning of the year, I got an Android Developer Phone 1 (basically an unlocked version of the T-Mobile G1) and was using it on T-Mobile’s network. For the most part, I loved the phone but hated T-Mobile’s network. If only I could have an Android phone on Verizon’s network, things would be perfect. So I waited anxiously for any news to come and eventually the rumors started to trickle in. Finally, Verizon launched the Droid last Friday and I was there early before the store opened, second in line to get one. I was in love. It’s a much faster phone than the G1, with a better display, better battery life, better camera, more memory, newer version of the operating system, better maps and navigation, better everything. Well, it didn’t have a better keyboard (the G1 keyboard has five rows of buttons with one row dedicated to numbers, while the Droid’s only has four and you have to use the alt key to hit the numbers which is kind of annoying, and also the G1 keys are more separated and feel better than those on the Droid).

My love for the Droid grew over the weekend. I saw four movies (two each on Friday and Saturday), and it kept me company while I was waiting for them to start. I downloaded and installed several apps from the Android market, most of them free but some of them purchased. However, that’s when the problems started. On Sunday evening, I purchased the Better Terminal Emulator Pro application and instantly the phone rebooted, and as soon as it came back up, it rebooted again, before I could do anything at all. And it kept rebooting. There was nothing that I could do to stop it. I found that if you hold down the “s” key or the menu key (on the keyboard, not the one below the screen), then the phone boots into safe mode, but even that wasn’t enough because it still rebooted. Trying to attach it to my computer over USB (from Linux or Windows) was unsuccessful, since it wasn’t getting far enough to allow me to see the device or attach to it.

Clearly, I couldn’t do anything at all with the phone in that state, so my only option was to take it back to the Verizon store on Monday morning, and they replaced it for me. Because it was tied to my Google account, all of my contacts and apps synced down without any problems, so it wasn’t too much of a hassle to get the second one configured like I had the first one. I did most of it in the car before leaving the Verizon store to head into work.

Surely it was just a bad phone and everything would be fine with the new one. Unfortunately, that wasn’t the case. The battery in the new phone wasn’t fully charged, and as soon as I plugged it in when I got into the office, it rebooted. Fortunately, it only rebooted once and didn’t enter an infinite reboot loop like the last one, but I was nervous. One of the applications that had automatically synced was the Better Terminal Emulator Pro application that had seemingly triggered the problem on my first one, so I thought it would be safer to get it off the phone in case it did something to make things unstable. So I uninstalled and refunded the app, and instantly the phone rebooted, and it kept rebooting nonstop. Another trip to the Verizon store (a different store this time, mainly because it was closer to the office) over lunch and I got my third Droid. The problem app wasn’t ever on this phone, and things generally seemed to be OK., although I still noticed occasional reboots, especially if I got a text message.

Earlier today, I was working and signed up for an online service that needed to activated over the phone. I entered my phone number and waited for it to call, but nothing happened. That was when I noticed that my phone was again stuck in a reboot loop. Once again to the Verizon store. This time, I was determined to not let it happen again. I made sure that it was completely new hardware (e.g., so they didn’t move the memory card from my previous one to the new one) and I even used a completely separate Google account. I proceeded with extreme caution, and things were looking positive for a while. However, again since it was a new battery it wasn’t fully charged so I plugged it in to charge it, and fortunately it didn’t reboot. I sent it a text message and it didn’t reboot then either. So things were finally fixed, right? Nope. A while later I looked at the phone and noticed that it was once again stuck in a reboot loop. Fortunately, when I unplugged it, it stopped rebooting, and it started back up when I plugged it in again. So I left it unplugged and let it come back up, and then I sent it a text message and it rebooted right away.

At this point, I’m stuck. I really want to love the Droid, and when it’s not rebooting it’s an extremely nice device. But if it crashes when I plug it in to charge it, or when I receive a text message or a phone call, then it’s really not of any use to me. At this point, I think that my only recourse is to take it back and swap it out for the HTC Droid Eris (which is also on Verizon’s network and also launched last Friday). It’s not as nice a phone as the Motorola Droid pretty much all the way around (smaller screen with a lower resolution, less memory, no physical keyboard, not running Android 2.0), but HTC has more experience building Android devices than Motorola so hopefully it will be stable. So I’m off to the Verizon store again tomorrow, hopefully for the last time in quite a while.

Thank you, Don

/ Neil Wilson / 1 Comment

This weekend, Don Bowen passed away, nearly two years after being diagnosed with brain cancer. His battle certainly had its ups and downs, but his faith in God remained strong and was truly an inspiration to me, and I’m sure to many others. He has long been one of the men I admire most, and although it was sad to see him go, we can take comfort in the knowledge that he is truly in a better place, free of pain and full of praise.

I first met Don about ten years ago when we both worked at Caterpillar. I was fresh out of college and inherited responsibility for the Corporate Web Security (CWS) system, a web-based single sign-on environment built from scratch using a collection of Perl scripts, a web server plugin, and (at the time) Netscape Directory Server 3.11. Don had previously overseen the CWS project, and someone suggested that I talk to him to learn more about how it was put together. He gave me a pretty good grilling, and actually I came out of it a little scared of him. I can’t imagine what he must have done to the guys brave enough to try to date one of his daughters. Nevertheless, I must have done well enough because within a few months he asked me to join him at a startup in Baltimore (B2B Communications, later renamed to TidePoint Corporation), which I did.

Unfortunately, TidePoint fared about as well as many of the other startups around that time, and when it came to an end we separated for a bit when he went to the Burton Group and I joined Netscape Communications. However, we were reunited after only a few months when we both came to Sun Microsystems at about the same time (he actually called me and told me he was probably going to be joining Sun while I was there for my interview). And most recently, we helped to found UnboundID Corp., where despite his diagnosis days after forming the company, he was a tremendous asset to the company in many ways and I know we certainly wouldn’t be where we are today without him. Even after he was no longer able to work, he continued to stay involved and the last time I was able to have a meaningful conversation with him (about two weeks ago), he wanted to know what I was working on so he could continue to pray for me.

Please pray for Don’s wife, their four daughters, his parents, and their myriad friends. I can’t imagine how exhausting things must have been for them, especially within the last couple of weeks, but it is a blessing to see and to experience the strong support network they have. We will miss his presence, but his memory will live on, and his eternity is secure.

SLAMD 2.0.0-20090712

/ Neil Wilson / 1 Comment

A new build of SLAMD is available for download from http://www.slamd.com/. The release notes provide a full list of the changes since the previous 2.0.0-20090227 release, but some of the most significant changes are listed below.

  • The process used to load classes has been updated so that if an attempt to load a class fails, it will re-try the attempt after substituting “com.sun.slamd” with just “com.slamd”. This makes it possible to view statistics collected from builds of SLAMD prior to the 2.0.0-20090227 release.
  • Two new jobs have been added which make it possible to perform LDAP searches using filters read from a file and LDAP modifications with target entry DNs read from a file. These jobs can be used if the target search filters or entry DNs do not follow a pattern that can be constructed like the other jobs provide.
  • A number of jobs have been updated to provide support for rate limiting. You can now specify the desired number of operations per second per client, and the clients will attempt to maintain that rate.
  • A number of shell scripts used to launch tools have been updated to fix problems that prevented them from working properly in some cases.
  • LDAP jobs have been updated to use the synchronous mode provided in the latest release of the LDAP SDK for Java. This allows them to be significantly more efficient and drive more load against LDAP directory servers.

Updating SLAMD Jobs to the New API

/ Neil Wilson

Since the latest update to SLAMD broke backward compatibility with previous versions, then anyone who has written their own custom jobs will need to update them to work with the latest release. Here’s what you need to do in order to achieve that:

  • The overall package structure has changed from “com.sun.slamd.*” to be “com.slamd.*“. For example, if you had previously imported “com.sun.slamd.parameter.ParameterList“, then you will now need to import “com.slamd.parameter.ParameterList“.
  • The former “com.sun.slamd.example” package, which holds most of the jobs provided with SLAMD, has been renamed to “com.slamd.jobs“.
  • The code has been updated to use generics, so any collections used within SLAMD have been generified. In order to avoid build warnings, you should use generics in your code as well.
  • All cases in the code in which the StringBuffer class was previously used have been replaced with the new StringBuilder class. The StringBuilder class can help improve performance because it doesn’t perform any synchronization the way that StringBuffer does.
  • Previously, the JobClass class, which is the base class for all SLAMD jobs, had a single getJobDescription() method which could be used to obtain the description for the job. That has now been replaced with the following two methods:
    • public abstract String getShortDescription() — This should return a short (preferably a single sentence) overview of the purpose for the job. It will be used in a few places in the administrative interface, including as a pop-up hint when hovering over the name of the job on the page listing the jobs available to be scheduled. This method must be provided.
    • public String[] getLongDescription() — This may be used to return a more detailed description of the sentence. It should return a string array, and each element of the array will be treated as a separate paragraph in the administrative interface. If this method is not provided, then the short description will be used.
  • The JobClass class formerly provided a destroy() method that allowed you to provide code that would be used in an attempt to forcefully kill a job. Because the JobClass class extended Thread, it overrode the deprecated Thread.destroy() method, which could generate build warnings. I have renamed the JobClass.destroy() method to be destroyThread() to eliminate this conflict. I also made JobClass.destroy() final so that you can no longer override it in job classes.
  • The former com.sun.slamd.example.Base64Encoder class has been removed. The ability to perform base64 encoding and decoding is now provided by the com.unboundid.util.Base64 class in the UnboundID LDAP SDK for Java.
  • The former com.sun.slamd.example.ValuePattern class has been removed. This capability is now provided by the com.unboundid.util.ValuePattern class in the UnboundID LDAP SD for Java. The com.sun.slamd.example.NumericRange class, which had been used by the old ValuePattern implementation has also been removed.