Alexander Schunk's Blog

OpenJDK: Partial Classes in Java?

OpenJDK: Partial classes in Java

While i was working on a Visual C# project build with Visual C# Express 2005 i was flying over the C# syntax features. One interesting thing is the possibility to define so called partial classes that is a class definition that is distributed over several sources files. Yes you are reading right, source files.

Microsoft did introduce this to make distributed team developed more easier by allowing distributed teams to work on the same class yet with their own defintions. The complete class will be generated when the appliction is compiled.

To understand what this means lets look at this code:

public partial class EmployeeA{
 //defintions
}

public partial class EmployeeB{
//definitions
}

Now image that the class EmployeeA is developed by team A and class EmployeeB is developed by team B. They can use this is as their basis for work and then merge these two distinct classes into one class called Employee when compiling the app.

I dont know how hard it is to implement something in Java but i think its a nice feature also if have GUI apps for example. The Visual C# designer makes huge use of this so you will always find partial classes when working with Visual C#.

Decimal data type

Another interesting thing is that C# has a decimal data type to define decimal values i.g. for currencies. In Java you have to use the Locale class for this.

Comments

• Note: the definition of EmployeeA and EmployeeB are hold in different source files as already mentioned. All type informtion must be available to compile the class.

  Posted by: alexanderschunk on November 08, 2007 at 05:54 AM

• I'm currently working on a C# project and know exactly what you're referring to. It's heavily used by Visual Studio for GUI and ASP.NET projects.
  One advantage of Java over C# is that source files in packages are organised into a directory structure. But in C# (for partial classes, amongst other reasons) , a source file can be stored anywhere you want in the compiler's path, and not only can it contain partial classes, it can also contain multiple public classes. Furthermore, the name of the source file doesn't need to match the name of any of the classes it contains.
  In short, a nice idea that can be easily abused, and which could break a lot of invariant assumptions in existing Java code. If it were ever to be implemented, it shouldn't be done at the expense of code organisation in the filesystem.
  Now, C# properties are nice, simple, and expressive, without any of the mad syntax or other useless "let's do it just because we can" ideas kicking around just now... There are some other good ideas (and some bad ones too) but I'm going off-topic here...
  - Chris

  Posted by: chris_e_brown on November 08, 2007 at 06:38 AM

• Well. I have always found it useful not to need to wrestle with things like Classpath - basically i would prefer having my app run anywhere without worrying wheather its in the classpath or not.. I think it should be possible to get rid of the classpath when deploying an app for different platforms. Classpath should only matter when compiling an app.

  Posted by: alexanderschunk on November 08, 2007 at 06:48 AM

• Partial classes in c# were pretty much created so that the visual designer can hide all the ugly boilerplate ui creation code away from the stuff that the user writes.

  There are far more elegant solutions to that (ui definition) problem, i think, like the Apple nib system, or JavaFX, or Adobe's Flex xml files.
  

  Posted by: goron on November 08, 2007 at 07:06 AM

• Actually, I would vote for exactly the opposite: sealed classes like scala offers. You can find more information on these here.

  Posted by: zero on November 08, 2007 at 07:24 AM

• Hmmm you give an example which is wrong, it won't compile.
  You will have twice the declaration

  public partial class Employee {
  //defintions
  }

  but in two different source files (say EmployeeA.cs and EmployeeB.cs).
  This is possible because unlike Java, C# doesn't enforce the name of the file to be the same as the name of the class/interface (or the contrary)

  Posted by: mrb_visu on November 08, 2007 at 07:48 AM

• Well i used the different class names to highlight the fact that they are defined in different classes. Anyway i found it a nice idea to have a class definition like that, however i did not mean to use it anywhere in your GUI application where its possible but just where it makes sense.

  Posted by: alexanderschunk on November 08, 2007 at 08:01 AM

• They are not defined in two different classes, this is one class defined in two different files, which is totally different IMO.
  Especially since with you explanation, it looks like the compiler is doing some kind of magic by finding that EmployeeA and EmployeeB are in fact one single Employee class. Or, as it looks like too much vaudoo, the user would have to tell the compiler. But it's none of both of course.
  In C#, classes and files are uncoupled ...
  However I do agree with you that it could be a nice feature to have in Java ...

  Posted by: mrb_visu on November 08, 2007 at 08:36 AM

• Man,... partial class is a feature created to easily decouple GUI and business code, thinking on visual studio easyness to generate UI code and hide it from the programmer. This in any case is nice, because it's (as already said) a definition just to split the definition of a class among 2 files.

  Conceptually, i.e. in UML, you are mixing business and UI logic into the same class. It goes against best practices, MVC, and all techniques learned by ourselves into our classes and books of Software Engineering. In my opinion, thank God Java doesn't have these feature, and I think it never will be a Java feature.

  Posted by: faibo on November 08, 2007 at 09:51 AM

• Actually i did not mean to use partial classes for GUI development only but for the case of distributed development. I would not say that Java should take over all C# featurs in their full consequence but having a sort of leighthweight implementation as it happened with Generics.
  Nobody wanted Generics in Java but its there and i dont know how many people want closures in Java but it will be in Java 7.
  A lightweight form of partial classes in Java for distributed development over the network would be helpful given the restrictions of class usage in Java compared to C#.

  Posted by: alexanderschunk on November 08, 2007 at 10:00 AM

• 
  //possible Java partial class in File Employee.java
  public partial class Employee{
  
  private String name;
  private int zipcode;
  private double income;
  public Employee(String name, int zipcode, double income){
  //construction
  }
  //methods
  }
  //possible Java partial class in File Employee.java on another machine

  public partial class Employee{
  
  private String name;
  private int zipcode;
  private double income;
  public Employee(String name, int zipcode, double income){
  //construction
  }
  //methods
  }

  The compiler will have to know how to put these two classes together into one.

  Posted by: alexanderschunk on November 08, 2007 at 10:09 AM

• Mutiple people working on the same class? That's what SCM is for, no need to bake this into the language.

  Personally I think partial classes can make maintenence a nightmare. Imagine trying to do a code-review of a class file that's split into 5 different files.

  Posted by: atehrani on November 08, 2007 at 10:47 AM

• Good point. I think MS did invent partial classes to do without such tools like SCM :).

  Posted by: alexanderschunk on November 08, 2007 at 10:49 AM

• "Imagine trying to do a code-review of a class file that's split into 5 different files."

  And they can be written in any .NET language! So, imagine reviewing those files if they are written in VB .NET, C++/CLI and C#!

  Posted by: mas7871 on November 08, 2007 at 04:33 PM

• atehrani said: "Personally I think partial classes can make maintenence a nightmare. Imagine trying to do a code-review of a class file that's split into 5 different files."

  Have you ever used C++? Even without includes, it allows you to split a class in many files. Not only you must have a separate header file to declare the basic structure (at least if you want the class to be importable from other sources), but you can scatter method implementations into multiple sources. And yes, it is a nightmare, good riddance of that "feature".

  There are other solutions for the problem solved by partial classes, including:
  - IDEs/editors with code folding
  - IDEs/editors that will hide or highlight/write-protect sections of code that a re tool-generated, e.g. NetBeans
  - Refactoring, delegation, structural design patterns (Composite, Decorator and Observer all come to mind for the GUI code generation case)...
  Good programmers don't need hacks to counter "god classes". Unfortunately, tools that generate code are usually even more stupid than weak programmers. But in this age of dynamic runtimes and easy, inexpensive on-demand code generation, there's little excuse for tools that produce massive amounts of source code. This could could almost always be generated at runtime, without pestering the project sources. Ruby on Rails and JavaEE5 are going the right direction, with increasing on-demand code generation. C#'s partial classes are a step back - looks like progress, but it's in the wrong direction.

  Now, a different language feature that partial classes look similar to, is Mixins (see wikipedia). But partial classes is just a cheap mangling hack, it's only better than C++ with #include's because the mangling can happen at loading time (the VM puts together bytecodes from different, separately-compiled partial classes), while C++ must combine things at source compilation time, which requires availability of the sources. Mixins are a different creature, they're first-class entities in the typesystem (supporting dynamic bindings etc) and allow superior composition, being considered by many a good alternative to multiple inheritance of implementation, without the boilerplate of composition by delegation. Mixins are available for example in Python and Ruby. If we're going to copy this into Java, let's copy the proper stuff, not Microsoft's poor hack of it.
  

  Posted by: opinali on November 09, 2007 at 05:53 AM

• Hi,

  well in my opinion this can be very useful when using tools like gui builders. You can have one file for the code, that is automatically generated by the gui builder and another file for the code that is written by the developer. Then you have a very clean split and no risk that the developer is changing the generated code.

  But on the other hand I have to admit that it is harder to understand at the beginning. The variables of the gui are declared in the file of the automatically generated code. So the developer doesn't see all variables. IDE support is needed here.

  And another fact: With java this is hard to realize, because the java-files have to have the name of the included class. Don't know if this can be changed easily. It's a good thing to have the name of the file equal to the class that it includes. Maybe an extension is possible:

  classX$1 classX$2 etc. Because $ is not allowed in class names afaik.

  Greetings

  Mike

  Posted by: miketech on November 13, 2007 at 01:20 PM

• Hi again
  I thought about the partial classes thing again and I've found another advantage. It would be great, if one could write one class in different languages. Imagine the following: Using a GUI builder, that creates java code. Normally this code is embedded in the same file you are using to write your code for event listeners etc. So you have to use Java too. It would be great, if the generated part is in java in file1 and the own code in a second file where another language can be used. So I can e.g. use matisse to create the gui and write the listeners in groovy, jruby or whatever. And the mix of matisse + groovy could be really awesome!

  Greetings

  MIke

  Posted by: miketech on November 16, 2007 at 06:49 AM

• 
  It would be great, if one could write one class in different languages.

  
  That's exactly what .NET does. But could you imagine reviewing or modifying code on a project where there may be hundreds of classes separated in even more files written in three or four different languages? Imagine one file written in VB.NET calling functions from other files written in C# or managed C++. You would need all files for a class open at once!

  Posted by: mas7871 on November 26, 2007 at 10:46 AM

This work is licensed under a Creative Commons License.