John D. Mitchell's Blog

Refactoring Java?

In the spirit of If you could get rid of one thing from Java..., if you could, what one thing about Java would you "fix"? This question is as inclusive as you want to make it. You want Java "open-sourced"? Or you'd like generics implemented "properly" instead of via type erasure? Or you want Sun to fix the insane version numbering scheme for Java? Share it here.

"The aim of an argument or discussion should not be victory, but progress." --Joseph Joubert

Comments

• Syntax
  There's too much noise in Java programs. Java should look more like Python. It's the only sensible reason I can see for running off to dynamically-typed, scripting languages. Earlier this year I put some ideas in my weblog. It could probably do with a bit more syntax for builders/constructing object graphs.

  http://jroller.com/page/tackline/20040325

  Possibly I should do less talking and implement it.

  Posted by: tackline on September 01, 2004 at 04:44 PM

• I couldn't get the list down to one.
  I'd probably find myself tossing up between the following:

  
  Real closures, with a syntax that isn't insanely verbose.
  A more flexible type system, with type inference so we don't have to declare so many things that should be bleeding obvious to the compiler.

  Posted by: carlfish on September 01, 2004 at 04:57 PM

• Open Source VM
  So Java can truely run everywhere on any platform and any device.

  Posted by: dukefetish on September 01, 2004 at 07:12 PM

• Syntax
  I'm confused. Are you really just asking for a different *syntax* or are you really asking for Java to become a more dynamic language or both or what?
  

  Posted by: johnm on September 01, 2004 at 09:33 PM

• Refactoring, eh?
  One of Martin Fowler's refactoring heuristics is to notice when code "smells bad".
  The fact that Swing rides on top of the AWT smells like an old shoe to me.
  Everyone who has ever forgot a 'J' at the beginning of a component type knows that
  you shouldn't mix heavyweight and Swing components, so why not bite the bullet and
  refactor the lot? The class hierachies and packages should be refactored to effect a proper
  split between the two (and I won't cry if all the old AWT were deprecated...)

  Another refactoring: drop those things that have been deprecated since 1.X (X==3?)
  

  Posted by: drlaszlojamf on September 02, 2004 at 04:29 AM

• Separate Java into Modules, Fix the crazy versioning, and Release modules as they are ready
  I think the big problem to fix is the 18-24 month release cycle for java. This long cycle has two grim side effects: some things (xml libraries) get included before they're really finalized, and other things (major api bug fixes) have to wait for the next release.

  I think the way to fix the problem is to separate java into modules, and put each module on its own release schedule.

  This approach invites .dll hell into our fold. So before we do it, we need to figure out a good way to handle different versions of the same .jar, and have the compiler or .jar tool enforce it (somehow).

  J2EE I think provides a good example of how to bundle up different parts of things in a static way. J2SE could take the same approach -- bundling up the modules every two years or so into a major release and recommended starting point. We do need to hang on to this simplifying idea. Those of us who need the latest things could pull in the latest new modules and use them. (We'd also have the option of playing class loader context games and mixing and matching the modules, st/ the new behavior is isolated from the rest.)

  By defining the rules, Java could also make it clear how parties outside the JCP should interact with the platform to keep their own work compatible.

  Hope that adds something,

  Dave

  Posted by: dwalend on September 02, 2004 at 05:06 AM

• Speaking of lists...
  If the question were how to refactor Java.net, I'd vote for fixing the CSS so bullet lists in comments don't show up with those crazy balloons!

  Posted by: jimothy on September 02, 2004 at 05:57 AM

• Lots of stuff
  Some bigger, some small.

  1. Little things - Like change the switch statement so that each case automatically ends in break - if you want to continue past your current case block, you do that explicitly.

  2. Properties - implement real properties in the language, rather than using the getter/setter convention. Even with a wonderful ide, you gain nothing by having those get/set methods in your code rather than having a "property". Especially since 80% of those get/set methods simply get or set the value.

  3. Anonymous inner classes - give them readable syntax. The current syntax is pretty arcane.

  I really like how, in java, I'm spending more time thinking about how what I'm supposed to write is supposed to work (conceptually), rather than thinking about the "best way to do it" in my code, and I hope we can keep it this way.

  I could probably think of more, but hey - I need to get back to "real work".

  Posted by: paulrivers on September 02, 2004 at 10:48 AM

• PS
  Oh, and don't get rid of type safety in the code - it's the only thing that makes the code I wrote last week and the code someone else wrote a year ago readable.

  Posted by: paulrivers on September 02, 2004 at 10:49 AM

• Process, not implementation.
  My wish for change is in the process; so the actual code fixes I sent to the swing team would not get a "Yeah; thats great!" and never hear from it again.

  I have to implement a whole new titledBorder class just because a 2 line patch is being ignored by Sun (for almost 2 years already).

  I'll probably keep wishing until there is a mature open source Java version out :)

  Posted by: zander on September 02, 2004 at 12:07 PM

• major upgrade
  Hi,

  I would change a lot should I have to change anything to Java. In fact, I would keep every feature from the language itself but would rewrite every API from the ground up and especially AWT/Swing using new features and having the benefits of the experience from the previous code. Better integration would probably lead to a 30 to 50 percent less classes.
  Of course the resulting code would need a compatibility layer to enable old code to run on the new plateform.
  Actually I think that open sourcing the language could be a first step towards such an effort.
  Will that ever happen ? I have doubts about it. Although, I recognized that there is not that much deprecated classes, nasty workaround for bad 1.0 design. Much the opposite.
  Should I refactor Java, I think I would first concentrate on J2EE which on the opposite seems ill designed to me.

  Cheers.

  Posted by: virtualcall on September 02, 2004 at 01:29 PM

• Syntax
  I entirely mean syntax. There's no need to be more dynamic. I think Martin Fowler explains more clearly than wot I done (particularly the last paragraph):

  http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
  

  Posted by: tackline on September 02, 2004 at 02:26 PM

• Concolidate
  I'd like you to put off the new feature trail for a release or two and catch up with the back log. Start by fixing all bugs, including the ones that might break some old code. 1.3 is old now!

  Backwards compatibility is good, but every now and then a line in the sand has to drawn and fought for. Just make sure to have good documentation of old and new behavoiur and we developers will adapt.

  I believe that if you have some old code that is <= 1.3 you'll probably run that on an old specific JVM as well. Most developers that write software "for the people", where it's hard to specify the target JVM, can easily recompile their product to work with new JVM:s. Or if they don't, they loose market cuts.

  
  Also in short:
  1) Make a bug report JWS-app that is good and easy to use. Microsoft's auto-bug-report is maybe too much to ask, but somewhere in between that and the current (ancient) Bug Parade would be acceptable.

  2) Widen the textarea that I write this in right now. It's like only 300 pixels!! Who ever designed that should not get any afternoon tea for a week!! ;)

  3) Since you (Sun) proclaim that Java on the desktop IS important and HTML IS old and slow, why not make some WebStart applications on you own site!? It only seems logical, as Spock would have put it. ;)

  4) Increase fidelity. Need I say more? Hire some designers/developers, like Karsten Lentzsch?

  5) Get rid of the AWT layer. Yes, it has to be done at some point... That would make the Component tree A LOT more clean (just look at the source code) and would problably reduce the chance of bugs in the not so distant future after that.

  6) Start making money. I'm a share holder God Damn It! ;)

  Cheers,
  Mikael Grev

  Posted by: mgrev on September 02, 2004 at 06:29 PM

• Syntax
  So, if all you want is different syntax, is there some reason that you can't use one of the myriad existing languages that targets the JVM?

  Posted by: johnm on September 03, 2004 at 08:17 AM

• Open Source VM
  I'm confused by your statement. There are already open source implementations of the JVM for an awful lot of different devices and platforms. Can you be more specific?
  

  Posted by: johnm on September 03, 2004 at 08:19 AM

• major upgrade
  Should I refactor Java, I think I would first concentrate on J2EE which on the opposite seems ill designed to me.

  So, if J2EE is ill designed then is it worth it or even realistically possilbe to actually refactor it or is it so bad that it needs to be thrown out and done back up more or less from scratch?
  

  Posted by: johnm on September 03, 2004 at 08:27 AM

• Syntax
  Because I want to stick with the Java semantics rather than that of some weirdo freak language. And when I read code I want it all to have the same syntax.

  Posted by: tackline on September 03, 2004 at 10:27 AM

• major upgrade
  Yes, I meant start again from scratch.

  Posted by: virtualcall on September 08, 2004 at 01:55 PM

• Another for process change I agree with zander, to bad Sun can't figure out how to leverage the Java community to fix bugs.

  Posted by: emeade on December 10, 2004 at 09:36 PM

This work is licensed under a Creative Commons License.