Java value types Vs .NET

I seem to recall an interview in the past that stated that everything in Java is a reference type, and the leap that the .NET (VM) made was in having both value and reference types, hence is faster than Java.

Nevertherless, I happen to have regurgitated this phrase in a conversation, and found that the internet appears to be against me, but I am sure that there is something about Java being a pretty much 100% OO language because of this. Am I wrong?

In Java all the primitives are value types (int, float, double, boolean, etc.)

Incorrect Vesuvius. Last time I looked at Java it also didn't have the nice transparent boxing and unboxing of value types that C# has. Also, maybe Bass can clear up whether Java generics supports value types, e.g. List<int> as you can do with .NET and without using a boxed representation underneath and whether it even supports generics at the bytecode and run-time level (i.e. without type erasure).

No Java generics do not support value types. However Java does autoboxing and unboxing. So you can do stuff like:

List<Double> nums = new ArrayList<Double>();
...

for (double num : nums) {

...

}

I don't think that in Java you can make your own value types (struct). Also in .Net there is no difference between int and Int32; they're just aliases, whereas in Java there is a difference between int and Integer (the first is a value type, the second a boxed representation of the same). Also, functions like toString() can only be called on the boxed representation.

@Sven Groot: That sinking feeling of eating humble pie, but, the inability to create your own value types perhaps could have been my misinterpretation.

One thing I hate about Java is you cannot method(ref int) which is extrememly horrible when I really need ref parameter. And yes, int is value type and if you want to update the value, you need ref. But, cursed Java cannot do it.

@magicalclick:

What is wrong with something like this? Integer is a ref type.

private void foo(Integer i) {
  i = 6;
}

@Sven

There is no "toString", but there is String.valueOf(prim) where prim is a value type, so you don't have to "new" anything to convert a primative to a string. It is possible that this ends up creating an object and calling toString in most Java implementions internally.

Isn't there also some issues with reflection in Java wrt value types? Maybe I'm wrong but I remember hearing something like that a long time ago. Or maybe it was just that reflection in Java wasn't as complete as it is in .Net.

@BitFlipper:

By default the Java compiler minifies parameter and field names. So if you do reflection on a parameter name and it was "pizza", you might find that Java will return "a" instead. This is mitigated by compiling in debug mode.

Also, in C# you can extend value types like int or System.Drawing.Color using extension methods.

In Java people do similar things using static imports. It's not quite as 'object-oriented' as extension methods, but I think when used intelligently it makes code look really succinct (eg: in the case of JUnit).

2 hours ago, exoteric wrote

Also, in C# you can extend value types like int or System.Drawing.Color using extension methods.

I'd like C# more if you could import namespaces, but not extension methods. So you'd have to do "using System.Linq.Enumerable;"

as opposed to just "using System.Linq;" and getting intellisense-pollution.

You don't need a language extension for that. Just factor extension methods into separate namespaces. By the way, in LINQPad you can hide extension methods with a short-cut combination when doing auto-complete. This is probably again a case that calls for "don't change the language, change the tool", where people often ask for a feature in the language when really the tools should be able to accomodate the feature.

3 hours ago, Bass wrote

In Java people do similar things using static imports. It's not quite as 'object-oriented' as extension methods, but I think when used intelligently it makes code look really succinct (eg: in the case of JUnit).

It's good that Java got static imports so you don't need to write Math.bla all the time. Extension methods, on the other hand, usually come with natural auto-complete (Intellisense) support so you automatically see what methods apply to a value of a given type.

That said, you could probably cook up some nice auto-complete tool support for static imports so they act like extension methods: dot into a type and you see static imports as well. Select the static method and it rewrites from bla.method() to method(bla).

You can autocomplete on static imports by hitting SHIFT-SPACE in Eclipse. I think Visual Studio uses the same exact shortcut actually.

Eclipse can also rewrite a Static.foo() to foo() automatically by hitting CTRL-SHIFT-M.

1 day ago, Bass wrote

@magicalclick:

What is wrong with something like this? Integer is a ref type.

1 2 3

privatevoidfoo(Integer i) {   i = 6; }

I use int.

Just so you know, it is not only for consistancy. While most people use int, not Integer, there is more to it. If you are going to do uint[ int.Max ], you would waste memory on pointers. And this is crucial for stuff like BioInformatics.

Of course, it is kinda pointless to use Java on BioInformatics. Everyone has tried on Java gave up and switch to C++ due to massive performance issues.