• Lawrence Tierney (google)

    Self documenting - I like it.

    I mean runTask(), what more could you need?

  • bvs23bkv33 (unregistered)

    run, run, run your task gently down the stream

  • MiserableOldGit (unregistered)

    Unnecessary recursion, no comments, reinventing the wheel with 3 or 4 sides .... he has all the makings for a long and fruitful career churning out code somewhere. He's just forgotten to add in some enterprisey XML.

  • 🤷 (unregistered)

    Yes, if only computers where build to run things automatically, just imagine how much time we could save!

    At my current job there is one program, that is scheduled to run hourly (at least my predecessor got that one right), it then checks a database table if there are any tasks to run at this specific hour. Sometimes the day is important as well (0 begin Monday, 1=Tuesday, etc.).

    After the check to the "what should I run" table is complete, it checks another table, which users should be notified. It does the check with an ID it got from the first table and checks it against the second table, which is structured like this:

    ID | Email

    And yes, that means that the same mail adress can be in that table a dozen times, depending on how many tasks the user is notified about.

    Even worse, sometimes the mail adress is hardcoded into the program, which makes errors like "why does user x still recieve that e-mail?" a bit hard to solve.

  • Steve_The_Cynic (nodebb) in reply to MiserableOldGit

    3 or 4 sides? More like he's reinvented the wheel, and it's a rod with the axle welded on at 45 degrees about a quarter of the way along.

  • snoofle (unregistered)

    I particularly liked the special case job for Wed that also accidentally ran on Mon and Tue to produce an identical output file, and nobody noticed for two years because they never checked for it until Wed.

  • MiserableOldGit (unregistered) in reply to snoofle

    Reminds me of the Y2.0014167K bug I uncovered at one place ... they had a monthly batch thingy processing insurance instalment payments that just did something like this to get a notional payment date ...

    datevariable=cdate(monthnumber & "/" & yearnumber)

    VB4 (I think it was) would accept nn/nn and use the second nn value to work out what to do. So while that second nn was counting up through the 90s, the system simply took nn/nn to be mm/yy and would then for, say 02/99 you'd get 01 Feb 1999 in your date variable.

    2000 was fine, but roll round 2001 ... 01/01 did become "01 Jan 2001", then 02/01 it took to mean 02 Jan of some year, for which it then used the current year, "02 Jan 2001". So this went unnoticed, because the payment had been taken and credited against the customer account and apparently the date didn't really matter, yet.

    These subscriptions were an annual cycle April to March, so come round to April, all the payments go in as 04 Jan 2001 and so everyone appears to have missed their first payment for 2001/2. No human noticed, but an automated process did, and so come the monthly run for May it submitted a request for 2 month's payments, dumped it in 05 Jan 2001, (and through some other bug of fixing the problem twice, also reran the April request) and when the phones melted with people noticing the cheeky grab, the call centre was adamantly telling them they had not made their payments for two consecutive months, while the customers were moaning they'd been charged four times.

    It was actually me (when I found the bug) asked Finance to check the affected customer accounts for 2000/1 ... "Why have they overpaid for last year by so much? How is it that possible?". How indeed.

    That place was veritable Pandora's box of fucked up assumptions embedded in code.

  • Appalled (unregistered)

    I'm lost (as usual). Like great, the class is a munge.

    But who the hell invokes the damn thing and when and how? Windows Task Scheduler? Some wacko C# thread spawned elsewhere that wakes up every 5 seconds?

  • Steve_The_Cynic (nodebb)

    Unrelated WTF but present here: why does a calendar know what the current date and time are?

  • Phlip (unregistered) in reply to Steve_The_Cynic

    In Java, the "Date" class represents a particular point in time, a glorified unix timestamp. Meanwhile the "Calendar" class represents a particular date and time on a clock, in a specific timezone. So, say, noon Pacific and 3PM Eastern would give you identical Dates, but distinct Calendars. (Fun fact: the method to convert a Calendar to a Date is Calendar.getTime(). Because what else would you call it?)

    Or, at least, that's what I remember of it. It's been a long time since I've used Java, and I think I heard stories of a third standard date class since then. But then, this the language which has both a "URI" and a "URL" class with wildly different APIs (and converter functions that throw exceptions in both directions because neither is a subset of the other), and both "File" and "Path" to represent filenames... and on and on.

  • comments.Count.ToString + "th" (unregistered) in reply to Appalled

    I want to know this as well! I really hope it's Task Scheduler!

  • snoofle (unregistered)

    The program itself was a stand alone Java application. It was run manually at some time each day. The idea was that the program would run whatever tasks were necessary for that day. I have no idea why a time component was used as the program could only be run during business hours by somebody at-work, so time-of-day never comes into play.

    So. Many. Failures.

  • nasch (unregistered)

    URIs and URLs is not a Java thing.


  • herby (nodebb)

    This might have been implied but "cron is your friend". Unfortunately Windows isn't!

  • Simon (unregistered) in reply to Steve_The_Cynic

    Because the classic Java date APIs were designed by a deranged individual (or possibly a committee of such individuals) believed to have escaped from Arkham.

    The first version (java.util.Date) was simple and easy to use, but also seriously flawed. The second attempt (java.util.Calendar) was complex and hard to use and still flawed, so most developers kept using the first, which was at least easy, used third-party libraries, or just wrote their own Data classes (which in any other situation would be a WTF, but in this case just good sense).

    The third attempt (Java 8's java.time.*) basically adopted most of the design from the most popular third-party library, and it does address most of the flaws from the previous attempts... parts of it are still kind of unintuitive, but it's probably the best date/time API I know of...

  • foxyshadis (unregistered) in reply to nasch

    Then you'd assume then that Java's URI class is just a more generic superset of its URL class, perhaps the URL class was even an Impl of a URIInterface abstract class... and you'd be completely wrong. They're incompatible in every way, despite so many overlapping features.

    Sun had many brilliant engineers, none of whom had the slightest idea of how to communicate with each other, their users, or create a good API themselves, throughout its entire existence. It pains me to say it, but being bought out by Oracle was actually one of the best things that ever happened to Java. (The original HotSpot being the other.) Too bad about all the other Sun, Apache, and MySQL projects, though.

  • Steve_The_Cynic (nodebb) in reply to Simon

    "Because the classic Java date APIs were designed by a deranged individual (or possibly a committee of such individuals) believed to have escaped from Arkham."

    That can be said about much of Java. I used to work with a guy who had previously worked with one of the guys guilty of having created Java. I shall not mention any names, nor what exactly my ex-colleague said, mostly because it might attract accusations of libel - I personally don't know the other guy, and know this stuff only by what my ex-colleague said(1) - but it wasn't good. It did go a long way to explaining why Java is like it is.

    (1) That's not quite true. My colleague had a large codebase at home that was, in origin, partly his and partly the work of this other guy. I pointed to a particular function, and asked why this function was recursive. It in no way needed to be recursive, of course, which was why I asked. His response was enlightening. It was apparently one of the remaining parts of the other guy's contributions, and this person was ... overfond ... of recursion.

  • D-Coder (unregistered)

    "Sometimes, the boss' kid or nephew was asked to get ambitious and solve a problem. When the inevitable happens, they call me to bail them out."

    Nitpick: Selection error. The solutions that actually worked adequately don't get to Snoofle.

  • dkf (nodebb) in reply to nasch

    URIs and URLs is not a Java thing.

    True… but the distinction for Java is rather different. The Java URL class supports downloading, but has an equality test that is truly awful. (Two URLs shouldn't be equal if they point to the same server because of virtual hosting, nor should an equality test ever involve actually talking to the network!) By contrast, the Java URI class has a mostly sane equality test (in so far as any URI could support equality sanely) but you can't really do very much else with it except for converting it to a URL.

  • Supersonic Tumbleweed (unregistered)

    Lemme guess. He didn't know about the break statement?

  • Joseph Osako, Jr. (github) in reply to Steve_The_Cynic

    The recursion thing is hardly surprising; many of the Java devs were old Lisp hackers. James Gosling had previously worked on a version of Emacs, including a Lisplike language called Moklisp, so he would have felt a lot more comfortable with recursion than most people. Too bad he didn't think to include support for tail call optimization in the JVM, but I'm not sure that was his call to make - someone probably overrode him on the topic.

    So Java was basically a bunch of Lisp hackers being asked to re-design Smalltalk to use C-style brace syntax and strong explicit typing, while looking as much like C++ as possible, all for a language meant to be used in embedded systems. The contradictions in this pretty much ensured a lot of WTFery in the language.

  • jerepp (unregistered) in reply to Simon

    "Because the classic Java date APIs were designed by a deranged individual (or possibly a committee of such individuals) believed to have escaped from Arkham."

    ... see there is where you are wrong... they just outsourced to Arkham to save money, nobody escaped.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Whoever wrote this code clearly had cronic problems.

  • Scarlet_Manuka (nodebb) in reply to Lawrence Tierney

    I mean runTask(), what more could you need?

    Reminds me strongly of MS Access VBA - in which, rather than having a sane object model with every object having its own appropriate set of methods, practically everything of importance had to be done using Application.DoCmd().

  • markm (unregistered) in reply to Supersonic Tumbleweed

    @Supersonic Tumbleweed: It's not clear whether he didn't know about the break statement or just didn't need it. However, it is clear that he didn't know about the if statement, or was unaware of comparison operators other than == and != (or whatever these are in Java).

  • GWO (unregistered) in reply to Joseph Osako, Jr.

    I don't know where you get the idea that the principle target of Java was embedded systems.

    No one designing for an embedded system in the 1990s would even think of using mostly-heap memory management and a mandatory garbage collector. You can get away with it now because a lot of today's embedded systems are more powerful than the PCs of 1995. But running a 32-bit JVM on an embedded system in 1995? Don't make me laugh.

  • doubting_poster (unregistered)

    My current employment also has their own invented cron wheel. To be fair, they can't depend on cron being there, the system uses automatic scalability code to setup new servers on various cloud services like AS3, which doesn't guarantee cron even exists. Also, the cron syntax is not very friendly to support personnel that have to schedule simple tasks and once you've implemented a more user friendly API, that's 90% of the work already.

  • Joseph Osako (google) in reply to GWO

    It was aimed at interactive television, which would certain have been an 'embedded system'. Furthermore, JavaME was a thing right from the outset.

    Addendum 2017-10-13 19:17: 'certainly'. Sorry, finger trouble.

  • Joseph Osako (google)

    Wicked-Pedo: https://en.wikipedia.org/wiki/Java_(programming_language):

    "James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991.[24] Java was originally designed for interactive television, but it was too advanced for the digital cable television industry at the time.[25] The language was initially called Oak after an oak tree that stood outside Gosling's office. Later the project went by the name Green and was finally renamed Java, from Java coffee.[26] Gosling designed Java with a C/C++-style syntax that system and application programmers would find familiar.[27]"

    Also, https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition

  • Joseph Osako (google)

    Even more: https://en.wikipedia.org/wiki/Java_(software_platform)#History

    "The Java platform and language began as an internal project at Sun Microsystems in December 1990, providing an alternative to the C++/C programming languages. Engineer Patrick Naughton had become increasingly frustrated with the state of Sun's C++ and C application programming interfaces (APIs) and tools. While considering moving to NeXT, Naughton was offered[by whom?] a chance to work on new technology, and thus the Stealth Project started.

    The Stealth Project was soon renamed to the Green Project, with James Gosling and Mike Sheridan joining Naughton. Together with other engineers, they began work in a small office on Sand Hill Road in Menlo Park, California. They aimed to develop new technology for programming next-generation smart appliances, which Sun expected to offer major new opportunities.[22]

    The team originally considered using C++, but rejected it for several reasons. Because they were developing an embedded system with limited resources, they decided that C++ needed too much memory and that its complexity led to developer errors. The language's lack of garbage collection meant that programmers had to manually manage system memory, a challenging and error-prone task. The team also worried about the C++ language's lack of portable facilities for security, distributed programming, and threading. Finally, they wanted a platform that would port easily to all types of devices."

  • kbalans (unregistered)
    Comment held for moderation.

Leave a comment on “A Case of Bad Timing”

Log In or post as a guest

Replying to comment #:

« Return to Article