My good friend Jason, one of the two talented developers that form micro-ISV LavaBlast Software, just put up a post about exciting happenings in the StatCVS and StatSVN world. Although I'm no longer really involved with those projects, I'm happy to see these developments, and want to give a kudos to guys like Jason Kealey and Benoit Xhenseval and all their collaborators for all the great effort they've put in.
As for myself, I'll be involved in more SVN-related tooling projects in the coming months, but I can't talk about that just now... :)
I need to reply to Jason's conclusion about coming back to Java development, though, especially the note about explicitly creating Integer objects:
"Personally, I enjoy loading up a recent version of Eclipse and working in Java once in a while because it helps me observe the best in both worlds. I much prefer coding in C# because of the easier string manipulation and the fact that everything is an object so you don't have to explicitly create an Integer object from your int to insert it into a collection. However, when working in VS.NET, I dearly miss the automatic incremental compilation feature that Eclipse runs when you save a file."
If it's been a little while since you've looked at Java, know that J2SE 1.5 brought a lot of great improvements especially in the Concurrent and Collections namespaces, as well as new language features. One such usability improvement is known as autoboxing, which means basic numeric types like int or float are automatically "boxed" into their object containers (Integer, Float, etc.) when required, like when adding an element to a collection, and "unboxed" when the native type is required. Just thought you'd like to know, Jason ;)
[It goes without saying that you should always be mindful of the performance impact of creating a bunch of temporary objects like this! Operations on Integers are always going to be slow-ish because they're immutable, and new objects are created for every value you use.]
2 comments:
The only problem is with projects such as StatSVN, we're still at 1.4, meaning we can't touch all the nifty stuff in 1.5 :(
(Benoit had fun removing our recently added StringBuilders!)
@jasonkealey: I don't know how valid a 1.4-compatible restriction is in 2008.
Here in the message routing / message queueing industry, we've certainly had to ask the question before the switchover, and even fairly conservative financial-services clients we deal with had no problem with requiring 1.5 JRE in early 2007, when our APIs dropped 1.4 compatibility. Now in 2008 it should be an even easier sell.
Post a Comment