java going in the wrong direction (1.5)

L

les ander

I just read the "whats new" feature at

http://java.sun.com/developer/technicalArticles/releases/j2se15/

and I think that even though templates (generic) gives a lot more
flexibility,
I am not happy that so many new features are being added to java.
I know c++ and I really hate it because it is very hard to understand
(I don't care if it gives more flexibility)--maintainance is more
important.

just ranting
 
T

Thomas Schodt

les said:
I just read the "whats new" feature at

http://java.sun.com/developer/technicalArticles/releases/j2se15/

and I think that even though templates (generic) gives a lot more
flexibility,
I am not happy that so many new features are being added to java.
I know c++ and I really hate it because it is very hard to understand
(I don't care if it gives more flexibility)--maintainance is more
important.

I read that a while back (well, the first half).
Felt the same way.
But I eventually decided it is more a question of a poorly written article.

Here's my rant ^_^

http://forum.java.sun.com/thread.jsp?forum=4&thread=488882
 
T

TT \(Tom Tempelaere\)

les ander said:
I just read the "whats new" feature at

http://java.sun.com/developer/technicalArticles/releases/j2se15/

and I think that even though templates (generic) gives a lot more
flexibility,
I am not happy that so many new features are being added to java.
I know c++ and I really hate it because it is very hard to understand
(I don't care if it gives more flexibility)--maintainance is more
important.

just ranting

I disagree, I welcome those features (with open arms). I think they target
ease of development and maintenance. They make code less bloated, ergo more
readable. The features themselves are very straightforward imho, and a
natural extension of the java language. They will prove invaluable (imo).
And I don't think that there are a lot of new features. I only counted 6
major changes.

To motivate:
(1) boxing : finally produce readable code instead of boxing / unboxing code
(2) template/generics : finally produce readable code instead of
casting-code all the time when you work with collections
(3) improved for-loop : makes iterations over data more concise, and easier
to read; hides the iterator-code
(4) enums : finally! no more public static final int WHATEVER times 10 for
specifying a set of values

I have my doubts about the static import facility, and the unboxing of null
(what to do with that?).

Anyway, I'm a big fan of templates & generics, and I think Java will become
more widely accepted because of this feature. For instance, C++ developers
will have less difficulty making the transition to Java.

The only thing that I keep missing is a typedef utility.
 
D

Dale King

TT (Tom Tempelaere) said:
(4) enums : finally! no more public static final int WHATEVER times 10 for
specifying a set of values

I have my doubts about the static import facility,

The benefit is like you describe is less repetitive typing. They give
examples of members of the Math class, but that only saves 5 characters. Try
these lines on for size with static methods with longer names. See if you
can fit them in 80 character lines:

AffineTransform rotate45 = AffineTransform.getRotateInstance(
Math.toRadians( 45 ), x, y ) );

GraphicsEnvironment environment =
GraphicsEnvironment.getLocalGraphicsEnvironment();

And also with the enums you seem to like so well, how do multiple classes
use those enums without having to qualify them with the class name where the
enum is defined and with the type name of the enum. Without static import
you have to do something like:

ClassDefiningTheEnum.TheEnumType.theEnumValue

any time you want the enum value. With static import you can import the enum
type with:

static import ClassDefiningTheEnum.TheEnumType.*

and then you can just say

theEnumValue
and the unboxing of null
(what to do with that?).

I assume that should throw an exception.
 
T

TT \(Tom Tempelaere\)

Dale King said:
The benefit is like you describe is less repetitive typing. They give
examples of members of the Math class, but that only saves 5 characters. Try
these lines on for size with static methods with longer names. See if you
can fit them in 80 character lines:

AffineTransform rotate45 = AffineTransform.getRotateInstance(
Math.toRadians( 45 ), x, y ) );

GraphicsEnvironment environment =
GraphicsEnvironment.getLocalGraphicsEnvironment();

I was thinking of name clashes. But indeed there is less typing which is ok
for me.
And also with the enums you seem to like so well, how do multiple classes
use those enums without having to qualify them with the class name where the
enum is defined and with the type name of the enum. Without static import
you have to do something like:

ClassDefiningTheEnum.TheEnumType.theEnumValue

An enum is a special form of a class. Why implement it inside another class?
any time you want the enum value. With static import you can import the enum
type with:

static import ClassDefiningTheEnum.TheEnumType.*

Again, I fear for possible name clashes. But it is less typing indeed.
and then you can just say

theEnumValue


I assume that should throw an exception.

Cheers,
Tom Tempelaere
 
D

Doug Pardee

TT \(Tom Tempelaere\) said:
I have my doubts about the static import facility

Static import is a "lesser of two evils" situation. It is intended to
replace the even more evil practice of "implementing" an interface in
order to allow a class to access constants defined within the
interface without naming the interface.

An example is javax.swing.SwingConstants. Rather than type
"SwingConstants.LEFT" to access a constant, classes commonly claim to
"implement SwingConstants" and then use simply "LEFT" to access the
constant.

Now they can do an "import static javax.swing.SwingConstants.*;' and
remove the misleading "implements SwingConstants".

It also provides simpler access to utility methods, especially those
in java.lang.Math.
and the unboxing of null (what to do with that?).

Already decided. After considerable discussions, the final decision
was to throw a NullPointerException. From the proposed spec change for
JLS 5.1.8:
"If r is null, unboxing conversion throws a NullPointerException."

Specs for JSR-201's "Enumerations, Autoboxing, Enhanced for loops and
Static Import" are available for download at
http://jcp.org/aboutJava/communityprocess/review/jsr201/index.html
 
D

Dale King

TT (Tom Tempelaere) said:
I was thinking of name clashes. But indeed there is less typing which is ok
for me.

And more readable, because having one line line for the statement is more
readable than multiple lines.
An enum is a special form of a class. Why implement it inside another
class?

Becuase it usually is associated with the interface for some class. For
example as the parameter and/or return value for one or more methods for
that class, it makes sense to define it in that class.

Oops, got the order wrong it should be:

import static ClassDefiningTheEnum.TheEnumType.*
Again, I fear for possible name clashes. But it is less typing indeed.

Sure there can be name clashes and in those cases the compiler will not let
you use the name unqualified.
 
T

TT \(Tom Tempelaere\)

Doug Pardee said:
TT \(Tom Tempelaere\) said:
I have my doubts about the static import facility
[...]
An example is javax.swing.SwingConstants. Rather than type
"SwingConstants.LEFT" to access a constant, classes commonly claim to
"implement SwingConstants" and then use simply "LEFT" to access the
constant.
Now they can do an "import static javax.swing.SwingConstants.*;' and
remove the misleading "implements SwingConstants".

Yuck indeed. I wouldn't even dare trying something like that. And then the
import static comes in handy indeed.

[....]
Already decided. After considerable discussions, the final decision
was to throw a NullPointerException. From the proposed spec change for
JLS 5.1.8:
"If r is null, unboxing conversion throws a NullPointerException."

Can I download the java specs for 1.5?
Specs for JSR-201's "Enumerations, Autoboxing, Enhanced for loops and
Static Import" are available for download at
http://jcp.org/aboutJava/communityprocess/review/jsr201/index.html

Thanks,
Tom Tempelaere
 
S

Scott Ellsworth

I just read the "whats new" feature at

http://java.sun.com/developer/technicalArticles/releases/j2se15/

and I think that even though templates (generic) gives a lot more
flexibility,
I am not happy that so many new features are being added to java.
I know c++ and I really hate it because it is very hard to understand
(I don't care if it gives more flexibility)--maintainance is more
important.

I believe that generics and enums are going to make more maintainable
code, not less.

I have seen some truly evil templates in C++, but the Java generics do
not seem prone to the more egregious problems I saw there. There are
some flaws, like being able to downcast then upcast, but as Bjarne put
it about c++, we mean to stop accidents, not sabotage.

Enums, similarly, are something that are needlessly complex in current
java code. The new syntax is at least no more complex, and it will mean
only one preferred way to handle the problem going forward.

I do not have an opinion on the other new features as yet.

Scott
(e-mail address removed)
Java, Cocoa, and database persistence consulting for the life sciences
 
J

Jim

I was thinking of name clashes. But indeed there is less typing which is ok
for me.


An enum is a special form of a class. Why implement it inside another class?

Because this form of Enum is like String; Java knows about them, so
you can use an Enum constant in switch statements!
Again, I fear for possible name clashes. But it is less typing indeed.


Cheers,
Tom Tempelaere

Jim
 
?

=?ISO-8859-1?Q?Daniel_Sj=F6blom?=

TT said:
<snip about new Java features>
(2) template/generics : finally produce readable code instead of
casting-code all the time when you work with collections

Certainly welcome. But IIRC, the casts are still there in the bytecode.
Surely this could have been implemented without casts?
(3) improved for-loop : makes iterations over data more concise, and easier
to read; hides the iterator-code

Not very useful in my opinion. I'd rather see the java APIs taking more
advantage of the iterator concept. So, just put a forEach(Iterator,
Function) method in Collections instead. Oh, and give me first class
functions instead of lame syntactic sugar :)
I have my doubts about the static import facility, and the unboxing of null
(what to do with that?).

The static import OTOH is nice syntactic sugar. One feature that you
didn't mention is variable arguments. Moderately useful I guess, but the
rationale for this, implementing printf, is rather weak.
 
T

TT \(Tom Tempelaere\)

Dale King said:
TT (Tom Tempelaere) said:
Dale King said:
message news:aL_%[email protected]... [...]
And also with the enums you seem to like so well, how do multiple classes
use those enums without having to qualify them with the class name
where
the
enum is defined and with the type name of the enum. Without static import
you have to do something like:

ClassDefiningTheEnum.TheEnumType.theEnumValue

An enum is a special form of a class. Why implement it inside another
class?

Becuase it usually is associated with the interface for some class. For
example as the parameter and/or return value for one or more methods for
that class, it makes sense to define it in that class.

Usually, indeed. But up till now, you didn't have a choice. There were no
enums, and people coded them into classes (as static final). Now, java
designers decided to go one step further than the current view of what an
enum is. They made it a class. If the class definition is complex enough, or
if the class is used in different contexts (eg shared between client <->
server) then I would definitely make it a seperate class. But that all
depends on the situation.

[...]
 
T

TT \(Tom Tempelaere\)

Daniel Sjöblom said:
Certainly welcome. But IIRC, the casts are still there in the bytecode.
Surely this could have been implemented without casts?

As I read through the specs, I noticed that their intention was not to
change the JVM too much, instead force the compiler to produce existing
bytecode for new constructs/features. But to be honest, I do not know the
relation between Java code and the Java VM (which executes bytecode).
Not very useful in my opinion. I'd rather see the java APIs taking more
advantage of the iterator concept. So, just put a forEach(Iterator,
Function) method in Collections instead. Oh, and give me first class
functions instead of lame syntactic sugar :)

IMO they are useful, because the intention is much clearer. Coding a for
loop using explicit iterators is tedious.

Again, IMO, I would have preferred other iterators. Iterators like they are
used in STL (C++). There is no special for-loop but the way to go about that
is (pseudo-code):

tyepedef std::vector< std::string > stringVector;
stringVector sv; /*...*/
for( stringVector::iterator iter = sv.begin(); iter != sv.end();
++iter )
{
// iter points to current element in vector
// *iter is a reference to the current object
}

But I guess that is a matter of style. The algorithm-header defines a
template function 'foreach' which allows executing a function for each
element in the collection.

[...]
One feature that you
didn't mention is variable arguments. Moderately useful I guess, but the
rationale for this, implementing printf, is rather weak.

Indeed moderately useful, and a chance to introduce bugs that can't be
checked at compile time. This seems like a feature that is targeted towards
new Java developers that have C++ knowledge.
 
T

TT \(Tom Tempelaere\)

Scott Ellsworth said:
I believe that generics and enums are going to make more maintainable
code, not less.

I have seen some truly evil templates in C++, but the Java generics do
not seem prone to the more egregious problems I saw there.

Agreed. C++ allows more complex template code (eg partial specialization,
template template parameters, non-class type template parameters (int, char,
pointer, ...), along with rather complex lookup rules. C++ does not allow
the "T extends ..." construct as in Java. This is a question of style.
There are
some flaws, like being able to downcast then upcast, but as Bjarne put
it about c++, we mean to stop accidents, not sabotage.

I don't see how that relates to templates. What stops you from downcasting
and then upcasting?
Enums, similarly, are something that are needlessly complex in current
java code. The new syntax is at least no more complex, and it will mean
only one preferred way to handle the problem going forward.

Complete agree here. Imho, it is better than in C/C++.
 
C

Chris Uppal

TT said:
As I read through the specs, I noticed that their intention was not to
change the JVM too much

Or at all. That's very important. The stability of the JVM (spec) is central
to building and maintaining momentum for Java. If they lost track of the
importance of total backward comapatibility then (in my opinion) Java would die
rather fast.
But to be honest, I do not know the
relation between Java code and the Java VM (which executes bytecode).

Please don't take this personally, but that's a good example of the problems
that I see with all this new stuff being added to Java. It breaks the link
between what Java is doing (or pretends to be doing) and what the JVM is doing.
As a result it gets harder and harder for ordinary programmers to understand
(as I believe they should) what's really going on, increases the complexity of
the system for those who *do* know what's really going on, and leads to a
proliferation of awkward corner-cases where the whole system (the Java compiler
+ the JVM) does not behave as a naive understanding would lead one to expect.

-- chris
 
C

Chris Uppal

les said:
I am not happy that so many new features are being added to java.
I know c++ and I really hate it because it is very hard to understand
(I don't care if it gives more flexibility)--maintainance is more
important.

I'm inclined to agree.

Sun are bowing to community pressure (I assume) in this, but I don't think the
community's well-advised.

They are adding significant complexity to the language, and (worse in my view)
adding enormously to the complexity of the mapping from Java-the-language to
the underlying reality, which is the semantics of the JVM.

Other people have disagreed with your point, but I think they are focussing on
the trees, not the wood. Its true that the new stuff will allow simpler
expression of some idioms, and as far as it goes, I agree that that's a good
thing. Unfortunately it's bought at the expense of an increase in the
complexity of the system as a whole, and I don't think the extensions justify
that.

You can't add simplicity *afterwards*, yet that's just what Sun are trying to
do.

(My only reservation in this, is that Java was already so complicated, though
not in the same ballpark as C++, that maybe most of the damage had been done
already, and so the extensions may not make things much worse. We shall
see...)

-- chris
 
T

TT \(Tom Tempelaere\)

les ander said:
I just read the "whats new" feature at

http://java.sun.com/developer/technicalArticles/releases/j2se15/

and I think that even though templates (generic) gives a lot more
flexibility,
I am not happy that so many new features are being added to java.
I know c++ and I really hate it because it is very hard to understand
(I don't care if it gives more flexibility)--maintainance is more
important.

just ranting

I would really love to have the new BigDecimal class. I was wondering: is
this going to be in the new version? It still seems to be in draft phase.
When I work with BigDecimal now, I can't help feeling like I'm walking on
eggs.
 
D

Dale King

TT (Tom Tempelaere) said:
Dale King said:
TT (Tom Tempelaere) said:
message news:aL_%[email protected]... [...]
And also with the enums you seem to like so well, how do multiple classes
use those enums without having to qualify them with the class name where
the
enum is defined and with the type name of the enum. Without static import
you have to do something like:

ClassDefiningTheEnum.TheEnumType.theEnumValue

An enum is a special form of a class. Why implement it inside another
class?

Becuase it usually is associated with the interface for some class. For
example as the parameter and/or return value for one or more methods for
that class, it makes sense to define it in that class.

Usually, indeed. But up till now, you didn't have a choice. There were no
enums, and people coded them into classes (as static final). Now, java
designers decided to go one step further than the current view of what an
enum is. They made it a class.

Right but that doesn't mean that just because it is a class it should be a
top-level class.

Keep in mind that every top-level public class must be declared in a
separate source file. Making every enum a top-level class would create a
whole bunch of little files that hold nothing but the enum. That creates a
lot of "conceptual weight" for something that may be nothing more than named
constants. You can certainly do some things with enums that warrant making
those top-level classes, but usually that won't be the case. Luckily with
static import that is no longer a problem.
If the class definition is complex enough, or
if the class is used in different contexts (eg shared between client <->
server) then I would definitely make it a seperate class. But that all
depends on the situation.

And typically it would be part of the server class.
 

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,755
Messages
2,569,537
Members
45,022
Latest member
MaybelleMa

Latest Threads

Top