Posts Tagged ‘Object Oriented Languages: Java’
Open Source Announcement: CleanSweep March 26, 2013 | 10:22 am

I just knocked out a generic implementation of a sweeper that leverages Java’s concurrency structures to provide a very pluggable background replacement for finalize(), which we all know is evil. It also works well for caching. You can find it over on GitHub under the name RobertFischer/CleanSweep. Instructions on its use are there, but it basically looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import com.smokejumperit.cleanSweep.Sweeper;
 
/* [...] */
 
    final Sweeper sweeper = new Sweeper();
 
/* [...] */
 
    Object it = new Object();
    sweeper.onGC(it, new Runnable() {
      public void run() {
        System.out.println("onGC action run!");
      }
    });

Functional (Meta)?Programming Stunts for Ruby and Groovy (and a Little Perl) June 24, 2008 | 11:04 am

After I learned OCaml, my coding mindset was totally distorted. I started writing Java code that looked like this:

  public Collection<foo> getCertainFoos() {
    return
      CollectionUtils.select(getFoos(), new Predicate() { 
         public boolean evaluate(Object o) {
            return SOME_CONSTANT.equals(((Foo)o).getProperty());
         }
      });
  }
</foo>

This is kinda ugly in Java, but it’s simply what comes out when I was thinking this in OCaml:

List.find_all (fun i -> SOME_CONSTANT = i#getProperty()) #getFoos()

I also started slapping final everywhere — see Yet Another Reason final Is Your Friend. A ubiquitous use of final actually gave some nice patterns (in the “macro” sense of patterns), but raised all kinds of eyebrows and made my code unmistakable. This lead up to a unique coding style which you can see in my most involved open source project, JConch. Meanwhile, my co-blogger was talking about “The Hole in the Middle” Pattern, which is also a lay-up within FP circles but required some backflips to implement in Java (functional interfaces) and C# (delegates).

It wasn’t until the advent of Ruby and Groovy, though, that functional programming skills really became easier to use. Basically, because of the inline closure’s succinct syntax (and ability to access non-final variables), I could suddenly do all kinds of really fun stuff. This “fun stuff” was exactly the kind of stunts I was pulling in Perl back in the day (see the BEGIN block in my Text::Shift code for a reasonably accessible example), and it was part of the reason I loved Perl so much at the time.

So, I thought I’d share some more of these cute stunts with you.
Read the rest of this entry

My Frustrations with REXML: Ruby’s Standard Library for Reading/Writing XML March 24, 2008 | 02:59 pm

Edit: Once you get the gist of this rant, jump to the comments for a slightly more reasoned approach. Or my follow-up post which attempts to re-open the dialog.


So, I’m trying to do a little bit of XML reading/writing. Nothing major — read in an XML, grab out some values, and then store the raw XML into the database. I’m doing pretty much the same thing in Groovy, and the XmlSlurper made that blissfully easy.

Since the core library comes with the REXML parser, I figured that it was a nice, stable library, and I’d roll with it. The interface wasn’t as nice as XmlSlurper, but it seems like it would do.

This was the start of the pain.

In fact, the pain pissed me off enough to share my frustrations with the world. Hopefully someone finds this useful, and they can avoid the pain and suffering I put up with. And yes, I could spend the time I’m griping going through and fixing up all the bugs, but I shouldn’t have to for a language as mature as Ruby. Core libraries are supposed to be stable, reliable beasties. If I wanted to spend all my time debugging half-baked implementations or rolling my own solutions, I’d never leave Ocaml — I come to Ruby for the community support. That’s supposed to be the big advantage.

Anyway, here we go:

Problem #1 came along when I tried to parse XML. First of all, the API documentation completely sucks — if you look at the top level REXML package, it’s totally worthless. If you manage to figure out that it’s REXML::Document that you probably want, you’re still not much better off. If you check out #new, which is really what you probably want, you’re rewarded with one word: “Constructor” You also have some “@param” tags that ran together and tell you things like the second argument, called “context”, should be a Hash of the context. That clears up a lot! And, seriously, if you’re telling me that it should be a Hash in the documentation, why aren’t we just doing implied static typing and being done with it?

Anyway, I retreated to Google, found the REXML tutorial, and managed to figure it out from there.

But then I kept having this annoying bug: when I called Element#text(), it was not only ignoring my instructions to leave entities alone (i.e. don’t turn “&lt;” into “<”), but it then seemed to go through and attempt to re-parse it, because it was complaining about unbalanced tags! Principle of Least Surprise my ass(1)! I’m not sure why the second part of that was happening, but the first part is apparently documented, so I stopped using the easy-to-read convenience method and went to Element#write.

This is where the real pain began. See, Element#write is broken. Deprecated and broken, actually. But the tutorial still tells you to use it. The solution is to use their Formatter approach. Except — ready for it? — that’s broken, too! No, I’m not kidding. In this language core library, both versions are broke! The solution is for me to reach in and make a change to the core library so that we avoid a null. In the standard Ruby deployment, using the standard core XML processing library, there is no way to write out XML. It is impossible because of bugs in the library.

The worst part?

THAT STUPID BUG IN THEIR CORE LIBRARY WOULD HAVE BEEN FIXED WITH STATIC TYPING(2). Even more if you have a type system which can check nulls for you. Null pointers/”nil when you didn’t expect it!” errors are totally solvable problems. The fact that our industry hasn’t moved past this painful left-over from C is driving me crazy. The next person who tries to tell me that dynamic typing is the best thing since sliced bread is going to get an earful. It is a flat-out wrong position, and I’m done hearing otherwise from anyone.

(1) As much as I’d love to claim that quote, it actually comes from Paul Cantrell’s excellent exploration of closures in Ruby.
(2) Or with the right test and a CI server guarding the production-bound branch. But that’s apparently not happening…which is where static typing comes in.

GroovyCacheMap February 17, 2008 | 05:45 pm

Since it was easy enough to do, I just created a GroovyCacheMap, which takes a Groovy Closure (see info at “Closures“).

Someone with a Groovy background wanna make sure that it’s sufficiently groovy-esque for users, and start fishing for those really horrible surprises?

I should really be working on the pipelines. But there’s a lot of annoyance there, and I miss being productive.

Installing RMagick on Ubuntu: Problems I Encountered Doing “gem install RMagick” November 25, 2007 | 10:19 am

So, I finally got RMagick installed on Ubuntu. Here are some greatest hit error messages I got while trying to do so:
"configure: error: C compiler cannot create executables"
configure: error: Can't install RMagick. Can't find Magick-config or GraphicsMagick-config program.
in `require': no such file to load -- mkmf (LoadError)

The answer is that you need to install the following packages:

  • g++ (Yes, even if you have gcc installed)
  • imagemagick
  • libc6-dev
  • libmagick9
  • libmagick++9-dev
  • libmagic9-dev
  • ruby1.8-dev

Once that’s done, then do the gem install RMagick.

AntFit Needs To Fork For The Classpath To Work November 20, 2007 | 12:50 pm

As long-term readers already know, I am a big fan of Fit automated through Ant — AntFit. One example of my Fit/AntFit code is online, although I’m surprised the company I wrote that for let my co-worker release it, and it’s without details or explanation.

One thing I am writing to warn people about, though, since it’s eaten a lot of time both times I used it, is that the the “Fit” Ant task provided by AntFit must fork if you want it to respect your classpath nested attributes. If you don’t have the fork=”true” property, you’re going to be in for a world of pain.

So just fork it. Save yourself the hassle.

Projects Update: Gem Work and AdLib I/O October 11, 2007 | 05:59 am

Anyone out there have experience getting a Gem plugged into RubyForge’s system? I’m having a bit of trouble, and I’m looking for some help: I’m offering compensation to the amount of my eternal gratitude and a beer. Drop me a line via Jabber at “[email protected]” or leave a comment here with your actual e-mail address in the e-mail field.

Also, I’m implementing Java-style streams in Ocaml as part of the AdLib project that Brian and I are working on. Stay tuned for more information: I should have some code soon.

My Newest Insight into the Generics Controversy May 17, 2007 | 11:42 am

Okay, I’ve had some quality time with Java5 at my newest gig, and I’m starting to understand the great controversy behind Java generics. There was a particularly painful insight I just had that has officially flipped me from stalwart supporter to reluctant supporter, and I’d like to share that with the world so they don’t have to hunt this bug down themselves.

The particular insight runs as follows. Assume that you have a class FooBar that takes parameterized type T. And assume you have a method that looks something like this:

    public T create() {
        final Object created = makeIt();
        try {
            final T out = (T) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Now, if I have a Foobar<Integer> object kicking around, and call create() in such a state that it makeIt() returns the String “42″, what would you expect to come out of create()?

Well, my thought was as follows.
Reduction 1:

    public T create() {
        final Object created = "42";
        try {
            final T out = (T) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 2:

    public Integer create() {
        final Object created = "42";
        try {
            final Integer out = (Integer) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 3:

    public Integer create() {
        try {
            final Integer out = (Integer)"42";
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 4:

    public Integer create() {
            return null;
    }

So, I’m thinking the answer should be null.

What I forgot is that Java implemented generics through type erasure (cite). So the reductions actually look like this:

Reduction 1:

    public T create() {
        final Object created = "42";
        try {
            final T out = (T) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 2:

    public Object create() {
        final Object created = "42";
        try {
            final Object out = created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 3:

    public Object create() {
            return "42";
    }

And that method — that one which the compiler dilligantly guarantied would only be used in places where it returns Integer objects — just returned a String.

Seriously.

I’ve got the unit tests to prove it.

EDIT: Oh, yeah, and there’s no way to go from <T> to something like T.class.

Implementation Exposure Through Inheritance February 17, 2007 | 12:45 pm

There’s a bit of ugliness with object-oriented development which I keep encountering, so I’m wondering if any of the locals out there have a better solution.

Specifically, my problem is that the inheritance relationship seems to be conflating two purposes in at least Java and CSharp. On the one hand, it is defining a one-way interoperability relationship: that is, a class X that inherits from Y means that wherever you could use a Y before, you can now use X, as well. In Java, this kind of relationship can be seen with BigInteger inheriting from Number: wherever a Number is called for, a BigInteger could be used. On the other hand, there is also the implementation work: a class X that inherits from Y means that class X uses the underlying implementatin of Y. This kind of relationship can be seen with Properties inheriting from Hashtable: Properties is simply choosing to inherit from Hashtable because that’s the underlying implementation.

And the conflation of these two very different purposes is complete: there is no way for X to say “I am meeting all the same contract as Y, but I am using my own implementation.” You can perform the inheritance and override all the methods, which works great until the inherited code contract changes, and now (with no compiler warning) you’ve exposed an underlying method which is built off a completely detached implementation. And that’s completely ignoring the fact that you’re still performing a full initialization on Y, even if you’re not ever going to use its faculties! For code that you control, you can always create IY, the Interface implementation of Y, but what do you do about code you don’t control. For a real work example which I have encountered, what if you wanted to implement your own BigInteger implementation (say, based on GMP?).

There’s also no way to say “I want to use all the methods of X in my implementation, but I don’t want to expose its methods to the outside world.” For a Java implementation interpretation, consider the ability to code a class as if you inherited it, but the underlying class methods all behave as private. The reason one would want to do this is because of encapsulation: what if Properties, for instance, wanted to change to get the free sorting provided by a TreeMap? Unfortunately, making the change to now inherit from TreeMap instead of Hashmap could break existing code: it’s been legal for years to work with Properties as though they were a Hashmap, and now you’re making that an illegal cast. This is likely another run-time bug that will be exposed without any help from the compiler, which means that it is a very dangerous change to be making. Yet this change can be made without any adjustment to the the conceptual entity that is “Properties”: what a properties represents is the same, and even the set of method signatures would be the same, but this new implementation could break code. The inheritance from Hashmap is just an implementation detail, yet it has become a key part of the API.

So how do you manage to keep the benefits of inheritance without exposing your underlying implementation? One solution that’s occurred to me is to ALWAYS have an Interface and a Factory for every class, but that’s a lot of noise to sidestep this programming language issue. There’s got to be a better solution — anyone got one?

C++ and Threading October 21, 2006 | 12:49 pm

Updated: Thanks to Captain Bedsock, link is restored.

I’m reading this post on the C++ committee’s dealings on threading, and, I am pleased to announce, there is absolutely no chance what so ever of anything sane, workable, or sensible accidentally arising from these precedings. That’s saracasm, but not by much. By the very nature of their responses, most of the people participating in this design meeting had no experience what so ever with multithreaded programs, and the problems that accompany them. Worse yet, they display a gross ignorance of compiler construction and optimization. Just who you want defining what is inarguably the most tricky aspect of an imperitive language (as the Java people found out the hard way).
Read the rest of this entry