OT: .NET and Java

[Jordan S.]

Does Java have anything equivalent to the .NET base class libraries? Or is
Java mostly "just another OOP language".

My motivation for the question: just trying to understand why the .NET
version of the Pet Shop required thousands FEWER lines of code than the Java
version. See the 2nd chart in this page:
http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10

Thanks!

 

[pvdg42]

Does Java have anything equivalent to the .NET base class libraries? Or is
Java mostly "just another OOP language".

My motivation for the question: just trying to understand why the .NET
version of the Pet Shop required thousands FEWER lines of code than the
Java version. See the 2nd chart in this page:
http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10

Thanks!

The answer to your first question is that the Java SDK comes with the Java
API, a large collection of classes available for use with Java, the
language. Actually the Java API class library and the .NET Framework class
library are quite similar in some respects. Both are inheritance hierarchies
with a class called Object as the cornerstone of the hierarchy.

That said, I'll give you my *opinion* on possible reasons why so many more
lines of code were needed in Java:
1. Most Java IDE's I've seen are not nearly as sophisticated as Visual
Studio when it comes to supporting drag and drop development of the GUI,
thus Java developers had to write more GUI code.
2. Because Java is the "write once, compile once, run anywhere" language
(lot's of caveats to that marketing hype), the GUI development involves
complications like layout managers that simply are not (usually) a worry
factor in Visual Studio.
3. Based on experience teaching Java, VB and C#, the Java API classes do not
expose as rich or as sophisticated an interface as do the .NET Framework
classes, thus leaving more work (code) for the using developer. (After all,
major portions of the Java API are much older than the .NET Framework).

Take the opinions for what they are worth

 

[Jon Skeet [C# MVP]]

The answer to your first question is that the Java SDK comes with the Java
API, a large collection of classes available for use with Java, the
language. Actually the Java API class library and the .NET Framework class
library are quite similar in some respects. Both are inheritance hierarchies
with a class called Object as the cornerstone of the hierarchy.

That said, I'll give you my *opinion* on possible reasons why so many more
lines of code were needed in Java:
1. Most Java IDE's I've seen are not nearly as sophisticated as Visual
Studio when it comes to supporting drag and drop development of the GUI,
thus Java developers had to write more GUI code.

That's true. However, Eclipse in particular is significantly better
when you *are* actually writing code than Visual Studio is, IMO. (These
days I believe it has a drag and drop visual designer, but I haven't
used it.)

As I spend most of my time writing code rather than dragging and
dropping, I'd rather have a decent editor than a decent designer.

2. Because Java is the "write once, compile once, run anywhere" language
(lot's of caveats to that marketing hype), the GUI development involves
complications like layout managers that simply are not (usually) a worry
factor in Visual Studio.

They're "not a worry" so long as you don't care how your form gets laid
out when you resize it (or when you change display language). Java's
layout managers allow you to relatively easily write UIs which can
easily be resized. .NET has this capability, but it's not as advanced
and tends to be ignored when using the designer, which tends to rely on
absolute positions.

As far as I can tell, WPF (aka Avalon) is closer to Swing/AWT than it
is to WinForms in terms of layout. (And thank goodness, say I.)

3. Based on experience teaching Java, VB and C#, the Java API classes do not
expose as rich or as sophisticated an interface as do the .NET Framework
classes, thus leaving more work (code) for the using developer. (After all,
major portions of the Java API are much older than the .NET Framework).

I think there are pros and cons both ways. Java got close to a
reasonable separation of "point in time" from "point on the calendar"
but only after a few attempts (leaving a huge deprecated API) and its
methods of manipulating it are painful. Java's character encoding
support is much harder to use than .NET's. Java's (W3C) XML APIs are
foul, although there are plenty of open source alternatives.

The latter is a very important point - there's much more community and
open source involvement in Java, IMO, partly due to its age. That's why
important projects like JUnit, Ant, Hibernate and Spring are ported
from Java to .NET rather than the other way round.

When developing a website, for example, with .NET there's effectively
just one big player: ASP.NET. In Java, there are (off the top of my
head):

Struts
JSP
Tapestry
Java Faces
Spring Web Flow
Plain servlets

- and that's just for starters. The downside is that you need to pick
carefully, and all the technologies have their limitations. The upside
is that at least you get a choice.

 

[Randolpho]

I agree with Peter about the original question... Java's API is just
not as rich as .NETs is. Which is why I dropped Java a couple years ago
for .NET.

However, I feel the need to address Jon Skeet's comments:

That's true. However, Eclipse in particular is significantly better
when you *are* actually writing code than Visual Studio is, IMO. (These
days I believe it has a drag and drop visual designer, but I haven't
used it.)

As I spend most of my time writing code rather than dragging and
dropping, I'd rather have a decent editor than a decent designer.

I'll admit that I haven't used Eclipse since 3.0.2, and I agree that
3.0.2 is much better in terms of intellisense and refactoring than,
say, Visual Studio .NET (2002), but Visual Studio 2005 knocks the
blocks off Eclipse 3.0.2. Eclipse is now in, what, 3.1.2? It may be
better than VS2k5, but more likely they're about on par. Add to that
the huge benefits of the VS2k5 designers, and I'd rather use VS than
Eclipse any day of the week.

They're "not a worry" so long as you don't care how your form gets laid
out when you resize it (or when you change display language). Java's
layout managers allow you to relatively easily write UIs which can
easily be resized. .NET has this capability, but it's not as advanced
and tends to be ignored when using the designer, which tends to rely on
absolute positions.

As far as I can tell, WPF (aka Avalon) is closer to Swing/AWT than it
is to WinForms in terms of layout. (And thank goodness, say I.)

I'll admit, .NET 1.0 and 1.1 were lacking some of the better
LayoutManager derivitives, like FlowLayout, but that's been addressed
in 2.0, and you've always had the ability to provide your own custom
layout by hooking the Layout event or overriding OnLayout.

 

[Jon Skeet [C# MVP]]

I agree with Peter about the original question... Java's API is just
not as rich as .NETs is. Which is why I dropped Java a couple years ago
for .NET.

There's very little I can (and want to) do in .NET which I can't do
with the built-in libraries + open source libraries, however.

However, I feel the need to address Jon Skeet's comments:


I'll admit that I haven't used Eclipse since 3.0.2, and I agree that
3.0.2 is much better in terms of intellisense and refactoring than,
say, Visual Studio .NET (2002), but Visual Studio 2005 knocks the
blocks off Eclipse 3.0.2. Eclipse is now in, what, 3.1.2? It may be
better than VS2k5, but more likely they're about on par. Add to that
the huge benefits of the VS2k5 designers, and I'd rather use VS than
Eclipse any day of the week.

Other than the designers (and class diagrams), in what way does VS 2005
"knock the blocks off" Eclipse even at 3.0.2?

Here's a small selection of my preferences in Eclipse:

1) Fantastic incremental compiler
2) Much better refactoring
3) Organise imports
4) Open type/open resource
5) Well-integrated unit testing
6) Better source control integration
7) Structured diff

These are things I use day-in, day-out. (In a typical day of actual
coding, I would use every single one of them several times. In a
typical day using VS, I would hardly touch a designer, even if I used
designers instead of hand-coding UIs.)

Yes, 3.1.2 is better than 3.0.2 (and significantly) - but all of the
above were available back in 3.0.2. (Eclipse had better refactoring
than VS2005 does significantly before VS.NET 2002 came out. It's a
constant source of amazement to me that MS dropped the ball on
refactoring for so long.)

See http://msmvps.com/blogs/jon.skeet/archive/2005/12/22/79631.aspx for
a longer post about all of this.

I'll admit, .NET 1.0 and 1.1 were lacking some of the better
LayoutManager derivitives, like FlowLayout, but that's been addressed
in 2.0, and you've always had the ability to provide your own custom
layout by hooking the Layout event or overriding OnLayout.

Yes, but it's been a pain until now - and in particular, it's not
*encouraged* by the designers. I prefer to write UIs by hand, just
because the code the designer generates tends to be so awful. Hopefully
XAML will vastly improve things on that score.

 

[jeremiah johnson]

I agree with Jon on all of this, and I'll add something here. Eclipse
is plain better than visual studio (any version) when you're doing the
coding. Visual stuff in Eclipse is not as easy as it is in Visual
Studio, but that is just how the languages were designed. Note: I
rarely write GUI applications in either language.

Eclipse has features that VS still doesn't have, and as Jon said,
Eclipse has had features that VS has been lacking for years and years.

Eclipse's compiler can partially compile a class. Even if your code is
syntactically incorrect inside a method, the Eclipse compiler will
happily compile around it. As long as you don't use that method,
everything will be fine. Things like this make eclipse awesome - you're
told about the error, but Eclipse assumes that you know what you're
doing and finishes the job.

The eclipse compiler can work through circular class dependencies
automatically also.

Eclipse compiles when you save to disk, rather than when you press
CTRL+SHIFT+B as in VS. Any files you save are compiled, and if any bits
of those files that other classes depend on (such as method signatures
or return types) were changed, the dependent classes are recompiled too.

The code formatter is far better in Eclipse. I can strictly enforce
coding standards at work this way. Checkstyle exists for Eclipse; same
reason.

Eclipse has JUnit and Javadoc built-in. No need to download, install
and configure NUnit or NDoc.

built-in CVS integration.

code templates - new classes or methods can have a template applied so
things like javadoc or whatever you want are automatically entered for you.

editor templates: type 'sysout' and press CTRL+SPACE and you get
System.out.println(); with the cursor between the parenthesis. I still
haven't found anything like this in VS, but I suspect its there.

Folks say that Eclipse is slow.. but I've never had a slow Eclipse
installation. I use WSAD at work with 512mb and while the initial load
time is usually around a minute, the rest of the operations are quite
snappy. I don't know what JRE you guys are running, but I'd upgrade if
you haven't already.

I could go on and on. VS feels like notepad when you're used to
Eclipse. It does to me, anyway. I avoid Visual Studio now unless I
*need* to use it.

If someone would come out with a free C# plugin for eclipse that would
be ideal.

about Java... personally I like Java more than C#. Not long ago it was
the other way around. I admit that I'm far less experienced with either
language than Jon so I'll let his opinions on the language design issue
rest. I have no desire to challenge them anyway.