Jeremy D. Miller -- The Shade Tree Developer

Sponsors

The Lounge

Syndication

Recent Posts

Tags

View more

News

Blogs I Read

Archives

Advertisement

Jeremy D. Miller -- The Shade Tree Developer » Jeremy in Java Land
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Jeremy in Java Land

I'm coding in Java this week and next!  ...and I'm a bit uncomfortable.  The problem isn't really Java per se, it's mostly unfamiliarity with the existing architecture and the different toolset.  Here's what I think so far:

  • The language difference is...    ...not worth talking about.  I haven't coded in Java since 2001 and I'm not having any particular problem with the language because...
  • Jumping from ReSharper to IntelliJ and vice versa goes a long ways towards smoothing the transition.  ReSharper shortcuts don't entirely map 1 to 1 with IntelliJ, but close. 
  • I spoke too soon.  I'm definitely slower in Java.
  • IntelliJ is the Cadillac/Lexis/Mercedes of IDE's.  This pretty well follows for any JetBrains product, but IntelliJ is the flagship.  There's a heckuva lot of stuff packed in there out of the box that you have to piece together with VS.  The Visual Studio team has heard this before, but one more time -- "just make it like IntelliJ."  I know VS's feature set is primarily driven by the Mort persona, but I bet Mort would want IntelliJ stuff if he/she were familiar with IntelliJ's feature set. 
    • More accurately, I don't care about a lot of the stuff that VS has that IntelliJ is missing, but the reverse is not true.
  • I think Visual Studio looks better though.  Considering the fact that we stare at those things all day, that's not trivial.
  • JUnit 3 sucks in comparison with NUnit 2+.  Not even getting into the expanded stuff in MbUnit, just the basic mechanics are clumsy to me.  I've heard that the newest version of JUnit brings them into parity with NUnit.
  • Unfortunately, the architecture of the code is not conducive to using TDD.  I'm actually driving the Java service through .Net FitNesse tests running from NUnit that go through the .Net gateway classes on the client.  Ouch.  It's easy to get the Java service up in debugging mode, but this isn't an ideal way to develop.  The green bars are farther and fewer in between.  I'm getting uncomfortably familiar with the IntelliJ debugger.  Yes Virginia, TDD is faster -- even in the short run.
  • I don't particularly like CVS.  Not the out and out disdain I feel towards Visual UnSafe, but I still want Subversion.  More accurately put, CVS doesn't like me.
  • We're doing some interoperability between .Net and Java by sending xml messages (don't ask).  Xml serialization from Data Transfer Objects on our (.Net) end and JAXB on the Java server side both working off shared XSD's.  I'm gonna call this one a draw.  JAXB seems to give us more control over the XSD compliance, but it's clumsy to use. 
  • To the guys who built JAXB, would you please go read up on the Law of Demeter? 
  • My client's naming convention calls for private members to start with "_" like "_doSomething(arg1, arg2)."  My VB background pokes out here as I sometimes struggle to stop capitalizing everything in code.  I use upper case for publics and lower case for private and protected members in C# (with underscores for class fields).  No big deal.
    • I've always thought that you can look at C# code and tell whether the developer came from a VB or Java background pretty easily by their capitalization in the code.  Of course, you can spot a COBOL (insanely long monolithic methods) or a Fortran (didn't get the memo that output parameters are evil) guy in any language.  You don't have to spot Smalltalkers because they'll always let you know on a near daily basis.
  • The declared exception thing is annoying.  I really don't see it doing anything but cluttering up the code personally.  It's what you're used to I guess, because my client's Java guys think that C# not having checked exceptions is a shortcoming.  I suspect that declared exceptions lead to using exceptions as a flow control device and I think that's mildly evil.
  • Could we please get an industry standard for the shortcut keys for "step into", "step over", and "step outside"?  I swear that every IDE built starts by saying, let's take the debugging shortcut keys from product X and move them all over one key to the left.
  • Everytime I see GregorianCalendar or JulianCalendar in Java I want to start chanting.  And what's up with having a dozen different classes for dates and times?  One class too simple?
  • I'm going to ask for a raise now that I'm multilingual;)

 

End Result:

I'm happy to stick to .Net & C#, but it's been fun just to do something different and see how the other half lives.  Now, if I could just get on a Ruby or Python or Squeak or Haskell or Erlang project...

Posted 12-30-2006 10:39 AM by Jeremy D. Miller

[Advertisement]

Comments

Dave Donaldson wrote re: Jeremy in Java Land
on 12-30-2006 11:47 AM

Personally, I like the declared exceptions in Java and wish they were in C#. From an API perspective, the developer who has to invoke one of those methods knows up front what type of exceptions they could expect, and thus can write tests for those exception types. In .NET, we have to rely on XML comments to tell us, and if you can find a team that is good at writing XML comments *correctly*, please let me know ;-)

Jeremy D. Miller wrote re: Jeremy in Java Land
on 12-30-2006 12:10 PM

Dave,

How do you *not* know where exceptions are likely to happen?  And how often do you really look for a specific exception type?  And if you are, is it really a case of using the exception as flow control?  Or should the class throwing the exception have the resource cleanup encapsulated in itself?

For that matter, put me down for a professed aversion to the XML comments in both languages as well.  IMO, whatever good comes out of the auto-generated documentation is more than counteracted by all the noise in the code.

Jeremy

Ayende Rahien wrote re: Jeremy in Java Land
on 12-30-2006 4:05 PM

Just to add to it, one of the things that I really don't like in Java is all the dealing with Exception all over the place, simply because you must.

If I am trying to update my business object I don't CARE that the database is down, someone high above should deal with it.

Jeff Perrin - Sexier Than You Are wrote Jeff in Java Land
on 12-30-2006 6:19 PM

Jeremy over at CodeBetter.com just wrote a post about his experiences in Java Land , and since I've been

sneal wrote re: Jeremy in Java Land
on 12-30-2006 10:25 PM

The more I use Java, the more respect I have for Anders Hejlsberg - and the more I wish I was still programming in C# every day.  I very much dislike checked exceptions, lack of operator overloading, lack of properties, but I really hate the Java generics implementation (erasure) - no runtime type information?!

Bruce Eckel, author of Thinking in Java (see Resources), says that after years of using the Java language, he has come to the conclusion that checked exceptions were a mistake -- an experiment that should be declared a failure. http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html

sergiopereira wrote re: Jeremy in Java Land
on 12-31-2006 10:44 AM

Count me in as another developer that thinks checked exceptions are a hassle that promotes bad practices and is not as useful as it may sound at first. Can you imagine having to deal with that when changing your code and still think about version compatibility? If you don't know the method you want to call can throw some type of exception, then it probably isn't your responsibility to handle it anyway. IMHO try/finally should be way more frequent than  try/catch/finally blocks.