Has Java become too complicated?

  • Thread starter frustratedprogrammer
  • Start date
F

frustratedprogrammer

When Java first become popular I remember it being touted as having
all the nice features of C++ without any of the ugly bits. However as
time goes it seems to be gettiing more and more complicated. The first
backwards step was inner classes and now generics. What does the
future hold?

http://frustrationsofaprogrammer.blogspot.com/
 
I

impaler

When Java first become popular I remember it being touted as having
all the nice features of C++ without any of the ugly bits. However as
time goes it seems to be gettiing more and more complicated. The first
backwards step was inner classes and now generics. What does the
future hold?

http://frustrationsofaprogrammer.blogspot.com/


I personally like generics and inner classes have their purpose.
If the problems to be solved get more complex a language is suitable
to solve them if it requires the leas effort. From my point of view it
just simplified it further.

Why isn't assembly the simplest language? It has a handfull of
features only. The more features, the higher the level a language
gets.
Regards,
 
C

Chris Uppal

When Java first become popular I remember it being touted as having
all the nice features of C++ without any of the ugly bits. However as
time goes it seems to be gettiing more and more complicated. The first
backwards step was inner classes and now generics.

I agree entirely.

Evolving a language is a Good Thing, but it should evolve in the direction of
greater generality, power, and expressiveness -- not into a grab-bag of random
hacks and half-baked features.

I used to like Java a lot. I still retain some fondness for it, but I dislike
it more and more with each major release. It's reached the point where,
although I'm perfectly content to use Java if someone is paying me for it, I'm
very unlikely to choose Java for any of my personal projects.

-- chris
 
L

Lew

I personally like generics and inner classes have their purpose.
If the problems to be solved get more complex a language is suitable
to solve them if it requires the leas effort. From my point of view it
just simplified it further.

Obviously the OP does not understand inner classes, which have been around
since the beginning and exist in other languages. Among other things they
provide a sort of "poor-man's" closure mechanism. (Yes, I know it isn't up to
everything closures can do, but it is up to everything I've needed in practice.)

The OP also seems to think that generics have reduced the value of Java, where
most seem to think they have enhanced it.

Most people in my observation that are "frustrated" with one or another Java
feature don't understand it, are simply trolling, or both. There are assuredly
aspects of Java that could have been done better, but come on, citing generics
and inner classes as declines in the language?

Come to think of it, lots of people think generics could have been done
better. Of course, most of their ideas would have broken backward
compatibility; the current mechanism is a compromise. Still, generics
represents an improvement over Java 1.4 and earlier.

I see the future holding enhancements to Java that will help workaday
programmers build practical enterprise-scale, robust, maintainable systems
more effectively, while others will undoubtedly whine about this or that
putative theoretical or stylistic shortcoming.

It's all FORTRAN to me anyway.

- Lew
 
E

Ed Kirwan

Chris said:
I used to like Java a lot. I still retain some fondness for it, but I dislike
it more and more with each major release. It's reached the point where,
although I'm perfectly content to use Java if someone is paying me for it, I'm
very unlikely to choose Java for any of my personal projects.

-- chris

Out of curiosity: what language do you use, Chris?

(Every language has its star-burst, formative period, with fanatical
screaming and shouting from proponents; every two years or so something
detonates and spews astronomical amounts of radiation all over the other
languages jostling for position in the firmament; but if you filter all
that out, and listen really, really hard, you'll hear the faint but
constant droning that everything's heading in one direction: Lisp. I
took a peek at a Lisp program the other day and didn't understand a
word, expression, or open square bracket of it. The programming universe
is a strange place.)

..ed
 
A

Andy Dingley

if you filter all
that out, and listen really, really hard, you'll hear the faint but
constant droning that everything's heading in one direction: Lisp.

Scheme isn't.
 
R

raddog58c

(Every language has its star-burst, formative period, with fanatical
screaming and shouting from proponents; every two years or so something
detonates and spews astronomical amounts of radiation all over the other
languages jostling for position in the firmament; but if you filter all
that out, and listen really, really hard, you'll hear the faint but
constant droning that everything's heading in one direction: Lisp. I
took a peek at a Lisp program the other day and didn't understand a
word, expression, or open square bracket of it. The programming universe
is a strange place.)

Try taking the cdr of that program recursively until you reach the
atom at its center....

.....cuz if you list the pros and cons, defun of Lisp is in peeling the
onion until you have nil...

.....at that it will seem as simple as driving a car....

And incidentally, if Lisp is the future, then it's like Deja Vu all
over again....

http://www.lispmachine.net/
 
O

Oliver Wong

Lew said:
The OP also seems to think that generics have reduced the value of Java,
where most seem to think they have enhanced it.

Generics is controversial enough that I'd hesitate to use the word
"most". Certainly, *I* think Java 1.5 is better than 1.4... but I'm not sure
if *most* people do.

[...]
Come to think of it, lots of people think generics could have been done
better. Of course, most of their ideas would have broken backward
compatibility; the current mechanism is a compromise. Still, generics
represents an improvement over Java 1.4 and earlier.

Right. Generics was a good idea, but its implementation (type erasure)
was poor. As for the backwards compatibility thing, I might have been
sympathetic at the time, but apparently the 1.6 class file format is not
backwards compatible with the 1.4 format (and Java 1.5 used the 1.4 format),
and as far as I can see, 1.6 didn't add any really big new features over
1.5. So what gives?

- Oliver
 
C

Chris Uppal

Ed said:
Out of curiosity: what language do you use, Chris?

Smalltalk, when I can. Which I discovered after I'd been programming Java for
a couple of years (around the time of JDK 1.2 as I recall).

(Every language has its star-burst, formative period, with fanatical
screaming and shouting from proponents; every two years or so something
detonates and spews astronomical amounts of radiation all over the other
languages jostling for position in the firmament; but if you filter all
that out, and listen really, really hard, you'll hear the faint but
constant droning that everything's heading in one direction: Lisp.

;-)

I've never really got the hang of Lisp. I've played with it a bit, on and off,
as I've played with many languages, but I don't feel tempted to put a lot more
effort into becoming fluent. Each time I've tried it, I've been put off by the
quality of the support tools, the (to my eyes) labyrinthine complexities of the
Common Lisp libraries, and the nasty historical hangovers (true is 't, but
false is () ? False is a kind of list ?? OK, polymorphism, right, but...)

I can understand the Lispers' viewpoint that it subsumes /everything/, but I
don't fully agree, and I certainly don't agree that it subsumes most things
/well/.

-- chris
 
C

Christopher Benson-Manica

When Java first become popular I remember it being touted as having
all the nice features of C++ without any of the ugly bits.

As a C programmer at heart, it hurts to hear all those lovely C-isms
which still litter C++ referred to as "ugly bits" ;-)
However as
time goes it seems to be gettiing more and more complicated.

Beauty is in the eye of the beholder, but I think generics actually
made Java look much more becoming. Inner classes are another story...
As with many things, just because a language *allows* you to use
certain constructs doesn't mean you *should*.
 
C

Chris Smith

Chris Uppal said:
I agree entirely.

I agree un-entirely.

Specifically, I object to the complaints about inner classes. I remain
convinced that inner classes are one of the most important advances in
OO C-family languages that have come about for some time. They are very
nearly as liberating for objects as lambda expressions are for
functions; things that are very neatly expressed with them are
simultaneously very clumsy without them.

That said, there are things about Java that seem less than appealing in
that they introduce new syntax for little or no reason. Some of them
were present in the original language (e.g., the access specifiers
copied from C++), and some were added later (generics, generics, and ...
oh yeah, I almost forgot generics).
 
C

Chris Smith

Ed Kirwan said:
(Every language has its star-burst, formative period, with fanatical
screaming and shouting from proponents;

I think this is misleading as it applies to Java. There was certainly a
fair degree of excitement and hype around the initial release; but a
large number of people also have legitimate reasons for a change in
opinion; the language has changed. We've reached the "too many cooks"
point. This time, the language itself wasn't designed by committee, but
the evolution since then certainly was.

In retrospect, the best thing for Java would have been if Sun had never
set up the Bug Parade. I'll admit that I'm not innocent; I thought it
was great! I set up a web page listing my proposals for adding to the
language. The problem is that I thought I knew everything; and now, a
mere six years later, it is clear to me that I didn't. But lots of
other people who lacked the same knowledge as I were able to vote for
their favorite features in the Bug Parade... and then Sun decided to
respond to community input. What a way to kill something that used to
be elegant and simple!
but if you filter all
that out, and listen really, really hard, you'll hear the faint but
constant droning that everything's heading in one direction: Lisp.

Whatever. Or at least so certain people would love for you believe.

In reality, Lisp is a rather poor *language* that embodies some very
good *ideas*. Ultimately its insistence, and the insistence of its
advocates, that the rest of the world should change to fit LISP is
ridiculous. It's amazing to me what passes for good sense in some
programming language communities.
 
C

Chris Uppal

Chris said:
Specifically, I object to the complaints about inner classes. I remain
convinced that inner classes are one of the most important advances in
OO C-family languages that have come about for some time.

IMO the /concept/ is OK, on average, but the implementation is less so. Or
rather, of the three different, and only somewhat related, sorts of nested
class, I think:

Static member classes. Concept is fine -- excellent in fact (not at all new,
but that's no shame). Slightly worried about the semantics with respect to
inheritance of/by member classes (which has been a longtime source of bugs in
the compiler -- indicating, to my mind, that this is more of a minefield than
it looks). More worried by the implementation of backdoor access to members.
Roughly as worried by the implementation of "protected" and "private" member
classes. I /really/ don't like all those extra methods and other hackery.

Non-static member classes. Concept OK, I don't see much benefit in extending
the static concept by having an automatically supplied reference to the outer
object, but it's not that big a deal. Complaints and worries, as for static
member classes, plus a dislike of the hackery needed to pass the outer
references to the member classes' constructors.

Inner classes (I hope I'm getting the terminology correct). There is a really
great concept there, but unfortunately they didn't choose to implement that
concept. Instead they choose to hamstring the idea by not allowing full access
to the local variables of the surrounding method. Dislikes: as for static
member classes plus:
+ The anonymous class syntax is a disgrace.
+ Given the hamstrung access to the outer variables, I think it would
have been better to have used a syntax to make it clear that the inner
class instance copies their values as it is constructed, rather than
constrain the outer variables.

And is there really that much benefit in inner classes over the classic closure
concept ? I'm not sure, though I'd be willing to argue the case either way.
Someday I must scan rt.jar to see how many inner classes implement more than
one method.

They are very
nearly as liberating for objects as lambda expressions are for
functions; things that are very neatly expressed with them are
simultaneously very clumsy without them.

The aim was laudable, I agree. I don't like what they actually achieved nearly
as much.

-- chris
 
A

Allan Valeriano

When Java first become popular I remember it being touted as having
all the nice features of C++ without any of the ugly bits. However as
time goes it seems to be gettiing more and more complicated. The first
backwards step was inner classes and now generics. What does the
future hold?

http://frustrationsofaprogrammer.blogspot.com/


Another endless discussion, just like the threads:

- Why does Java require the throws clause? Good or bad language
design?
- Java needs "goto"
- Help me!! Why java is so popular
 
C

Chris Smith

Chris Uppal said:
IMO the /concept/ is OK, on average, but the implementation is less so. Or
rather, of the three different, and only somewhat related, sorts of nested
class, I think:

Ah, yes. I confess to jumping from "inner classes" to "anonymous inner
classes". Nested classes are fine; probably ought to be expected.
Nothing revolutionary. Named inner classes are clumsy, honestly, and I
never use them. It is anonymous inner classes that I find quite
revolutionary among mainstream OO languages.
Inner classes (I hope I'm getting the terminology correct). There is a really
great concept there, but unfortunately they didn't choose to implement that
concept. Instead they choose to hamstring the idea by not allowing full access
to the local variables of the surrounding method.

I would like to see that decision reversed as well. Ultimately, though,
I don't think it's the main benefit of anonymous inner classes. The
revolutionary idea is that your choice of building abstractions no
longer has to follow the structural needs of code in terms of
implementing interfaces and such. The general idea of decoupling those
was pretty unprecedented among mainstream OO languages. As useful as it
would have been to be able to access local variables as well, that would
have merely added an implementation technique; it doesn't extend into
the design sphere.
+ The anonymous class syntax is a disgrace.

Is there something you'd prefer?
+ Given the hamstrung access to the outer variables, I think it would
have been better to have used a syntax to make it clear that the inner
class instance copies their values as it is constructed, rather than
constrain the outer variables.

Why? That's not required; it's simply a logical implementation
decision. The current syntax opens the door to removing that
restriction in the future without having some clumsy field-copying
syntax left lying about.
And is there really that much benefit in inner classes over the classic closure
concept ? I'm not sure, though I'd be willing to argue the case either way.
Someday I must scan rt.jar to see how many inner classes implement more than
one method.

Given that Java lacks first-class functions, I'd say it would have
complicated the language more to add them instead of anonymous classes.
Like it or not, classes are basically the only significant unit of
abstraction in Java; and that is part of its simplicity. As much as I
like languages with first-class functions, I don't know that I'd be
certain they are a good thing to add to Java. At a certain point, one
needs to let a language have its character, and pick a different
language if one wants a different character.
 
M

Mike Schilling

..
I would like to see that decision reversed as well. Ultimately, though,
I don't think it's the main benefit of anonymous inner classes. The
revolutionary idea is that your choice of building abstractions no
longer has to follow the structural needs of code in terms of
implementing interfaces and such. The general idea of decoupling those
was pretty unprecedented among mainstream OO languages. As useful as it
would have been to be able to access local variables as well, that would
have merely added an implementation technique; it doesn't extend into
the design sphere.

This is the use of anonymous classes which would be solved equally well by
method pointers, which are conceptually much simpler (or at least more
familiar from other C-base languages.) I find Sun's white paper extolling
the virtues of anonymous classes over method pointers quite unconvincing.
 
M

Mark Thornton

Mike said:
This is the use of anonymous classes which would be solved equally well by
method pointers, which are conceptually much simpler (or at least more
familiar from other C-base languages.)

More familiar yes, but not conceptually simpler. I think anonymous
classes are rather simpler in concept than method pointers in C++.

Mark Thornton
 
M

Mike Schilling

Mark Thornton said:
More familiar yes, but not conceptually simpler. I think anonymous classes
are rather simpler in concept than method pointers in C++.

I disagree, and that gets us nowhere, does it? :)

Assume we're introducing only the bound method pointer, that is, an object
that:

o - is typed just as a method is, with a specific "this" type, argument
types, and return type.
o - when created, is bound to a "this" object and a method name
o - does only one thing after being created -- call the method it was bound
to

I submit that, to anyone familiar with OO (in particular, dispatch of
virtual functions), the idea of an object that encapsulates a method call is
an obvious one. I submit further that there are no bothersome subtleties
here. Having written one test program that used these method pointers,
you'll know exactly how they work, and the answers to whatever questions
might be raised are obvious.

Q: What if the object gets collected?
A. The method pointer references it, so it can't be collected wile the
pointer's still live.

Q. What thread does the called method run on?
A. The same thread as the caller, like any other method.

Q. How many times can I use a single method pointer?
A. As many times as you like, just as you could call the method directly as
many times as you like.

Anonymous classes are, I submit a bit more complex. Yes, they're classes,
and that answers a lot of questions about them. But their access to the
private parts of their enclosing class (necessary, if they're going to be
useful callback handlers) introduces more complicated and somewhat arbitrary
behavior:

Q. But what use are they if they can only invoke public behavior on their
enclosing class?
A. Exactly. That's why they can access private parts of their enclosing
class too. And their enclosing classes can access their private parts too.

Q. Why that last part?
A. Umm, symmetry. And they can access final members of the block that
creates them.

Q. You mean, scalars and strings, that are truly constant?
A. No, objects too. Including mutable ones.

Q. So the anonymous class can access an object that might change out from
under it, but not an object *reference* that might change out from under it?
A. Exactly.

Q. And I can define static members of the anonymous class, to define
properties that all of the instances will have in common?
A. No.

Q. Why not?
A. Because. But you *can* define them as statics on the containing class,
further away from where they're used, and with nothing syntactic to indicate
that they're intended as part of the anonymous class.

Q. OK, I feel better. But it seems to me that the purpose of the
anonymous class is to make its methods as much as possible like methods of
its enclosing class, while allowing them to be run from a wider selection of
callers, for instance, via callback interfaces the enclosing class doesn't
implement.
A. Exactly.

Q. Then why not have a mechanism where the method *can* be part of the
enclosing class, and be called via something other than its name?
A. Because that would be complicated.
 
L

Lew

Mike said:
Q. And I can define static members of the anonymous class, to define
properties that all of the instances will have in common?
A. No.
Q. Why not?
A. Because. But you *can* define them as statics on the containing class,
further away from where they're used, and with nothing syntactic to indicate
that they're intended as part of the anonymous class.

It may have been simply to simplify the implementation of Java. Inner classes
are tied to the enclosing instance. Making static members visible only to
instances created within the enclosing object, but not to other objects of the
enclosing class, would have been difficult to implement and conceptually
difficult for many workaday programmers. Far simppler to allow only final
constant members to be static, as inner classes do, which renders moot the
question of visibility betweendifferent enclosing instances.

It occurs to me that many things left out of Java might seem very useful to
highly skilled programmers for certain corner applications, but that the
compromises may make life simpler for the gazillions of journeyman programmers
who do not have quite that deep a grasp on computer science. I do not know if
this is what Sun had in mind, and may not be enough to justify the
compromises, but it seems to make sense.

- Lew
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top