*
The moose likes Java in General and the fly likes Q for Herbert : Java 5 wish list Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Q for Herbert : Java 5 wish list" Watch "Q for Herbert : Java 5 wish list" New topic
Author

Q for Herbert : Java 5 wish list

George Harley
Greenhorn

Joined: Sep 23, 2003
Posts: 6
Hi,

If you could remove any one of the new features from Java 5 what would it be ? What would you replace it with ?


Thanks,
George
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Static imports. Something that makes really good sushi.
[ August 25, 2004: Message edited by: Dirk Schreckmann ]

[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Herb Schildt
Author
Ranch Hand

Joined: Oct 01, 2003
Posts: 239
I wouldn't remove anything. Its all valuable. As I have stated on a different post, I personally don't have much use for static import, but I can see where others might.

As to what would I add? At this point, nothing! The changes are so significant that they need to shake out a bit before we start thinking of new things.

Also, on a more philosophical note, all languages seem to get bloated by features over time. I hope that this does not happen to Java.


For my latest books on Java, including my Java Programming Cookbook, see HerbSchildt.com
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Herb Schildt:
Also, on a more philosophical note, all languages seem to get bloated by features over time. I hope that this does not happen to Java.


Now you are just opening a can of worms for an all new discussion. Watch out Herb!


GenRocket - Experts at Building Test Data
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
I'd remove the metadata. I'd add the following changes:

- allow constructors to be synchronized

- remove the requirement for try blocks to be compound statements. In other words, instead of writing:



you could have:



which is in my opinion much cleaner and more compact.

Herb Schildt:

Also, on a more philosophical note, all languages seem to get bloated by features over time. I hope that this does not happen to Java.

Some might say it has already happened. It's really hard for regular users of the language to tell, because the bloat happens in small, digestible chunks.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Warren]: allow constructors to be synchronized

Errr... why? I don't think I've ever seen a usage where this would matter. I suppose if you're modifying static variables inside the constructor, you can put in a sync block using the Class object as monitor. Is that the sort of thing you're thinking of?


"I'm not back." - Bill Harding, Twister
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Warren Dew:
allow constructors to be synchronized

The only case I can think of where a constructor isn't synchronized is if the constructor itself initiates actions to cause another thread to call a method on the object being constructed. Is this what you'd like to avoid?

My gut feeling is that you should be able to easily code around this. Can you give an example, as it's possible I just don't understand what you're asking for.
Herb Schildt
Author
Ranch Hand

Joined: Oct 01, 2003
Posts: 239
Warren:

If I remember correctly (which I might not), I believe that very, very early versions of Java (possibly original 1.0 Betas) did not require blocks for targets of try/catch. Does this jog anyone else's memory?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[David]: My gut feeling is that you should be able to easily code around this.

My gut feeling is that programmers who even try this sort of thing in the first place need to be poked with sharp sticks.
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
I could go for some really good sushi...


I've heard it takes forever to grow a woman from the ground
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
David Harkness:

The only case I can think of where a constructor isn't synchronized is if the constructor itself initiates actions to cause another thread to call a method on the object being constructed. Is this what you'd like to avoid?

"Causes" is a complex concept in multithreaded Java applications.

A very standard, and in my opinion reasonable, thing to do in a Swing constructor is something like this:

Input_field.addActionListener(this);

But, you can't make it thread safe in the usual way by declaring the method synchronized, because constructors can't be synchronized.

By my understanding of the Java Memory Model, though, it's actually much worse than that.

Remember that the Java Memory Model does not require actions within a thread to be seen as sequential in other threads, only in the thread in which they occur. Here's the classic example (from JSR 133):

Initially, x == 0

Thread 1:

a = x; // statement 1a
x = 1; // statement 1b

Thread 2:

b = x; // statement 2a
x = 2; // statement 2b

What are the final values of a and b?

Obviously if thread 1 runs to completion first, a == 0 and b == 1. If thread 2 runs to completion first, a == 2 and b == 0. But it's also possible that, from the point of view of thread 1, statement 2b precedes statements 1a and 2a, while from the point of view of thread 2, statement 1b precedes statements 1a and 2a, with the end result that a == 2 and b == 1.

Now, let's look at the following:



Again, from the standpoint of thread 2, statement (substatement) 1b can appear to be executed before statement 1a. This causes X.x to receive be assigned a reference to the newly constructed object - before the object has actually been constructed! Statement 2b then throws a nullPointerException because X.x.i hasn't been initialized yet.

In the earlier case from JSR 133, things can be fixed by synchronizing appropriate methods. This case, though, can't be fixed that way, because constructors can't be synchronized. As a result, as I understand it, nothing in a constructor can ever be relied on to have happened from the point of view of another thread.

My gut feeling is that you should be able to easily code around this.

The way to code around this is never to use constructors, but to always use factories which call a synchronized initializer function instead. However, aside from missing the entire point of having constructors, this is (1) kludgier, and (2) dangerous, because someone writing a subclass may not realize or remember that the superclass constructor doesn't set up the superclass invariants as it really ought to (or indeed do anything at all).

If 'being able to code around' things was satisfactory, we wouldn't need Java 1.5 at all, would we?

Jim Yingst:

My gut feeling is that programmers who even try this sort of thing in the first place need to be poked with sharp sticks.

And that's exactly what it feels like, when you get bitten by a bug from having innocently put a statement in a constructor in a multithreaded application!
[ August 25, 2004: Message edited by: Warren Dew ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I'll concede there are ways to inadvertently make an object accessible to other threads without realizing it. I thought you meant people were trying to do this, intentionally.

constructors can't be synchronized

I'm still thinking about some of your other statements - but if you need synchronization here, couldn't you just put a synchronized block inside the constructor?
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Warren Dew:
- remove the requirement for try blocks to be compound statements. In other words, instead of writing:


which is in my opinion much cleaner and more compact.


I don't think try block in most cases would be with only one statement like this... And as well as the catch block...

IMO, the existing try-catch block system is good already....


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Herb Schildt:

If I remember correctly (which I might not), I believe that very, very early versions of Java (possibly original 1.0 Betas) did not require blocks for targets of try/catch. Does this jog anyone else's memory?

That's interesting ... do you know why they changed it?

To be honest, the requirement after the "catch" only bothers me aesthetically, as it's inconsistent with the lack of any such requirement after an "if". The requirement for the "try" block does bother me, though, as it often means I have to declare variables outside the block, even though I can't initialize them until inside the block.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Jim Yingst:

I'm still thinking about some of your other statements - but if you need synchronization here, couldn't you just put a synchronized block inside the constructor?

If only the problem in the Swing example existed, you could, I think, but then, what's the reason for not allowing constructors to be synchronized again?

Some early Java documentation talked about constructors not needing the synchronized keyword because they were "automatically synchronized", but then it was pointed out that they weren't. I think that perhaps originally, some people at Sun were thinking that construction was supposed to be complete in all threads before any thread could reference the object, but that's clearly not how people are interpreting the specs today.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Ko Ko Naing:

I don't think try block in most cases would be with only one statement like this... And as well as the catch block...

Interesting. Almost all my try blocks contain only a single statement. I agree that catch blocks tend to be longer.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Warren Dew:
Ko Ko Naing:

I don't think try block in most cases would be with only one statement like this... And as well as the catch block...

Interesting. Almost all my try blocks contain only a single statement. I agree that catch blocks tend to be longer.


Then I think you got a lot of try blah blah; catch blah blah; scattered throughout your code.... If I am not wrong, I guess putting an appropriate amount of codes into a single try black is better than creating a lot of try-catch, whenever you need to deal with exceptions..

Let's see others' opinions as well... Now we are into the topic of Good Programming Practices...
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Jim Yingst:

I'm still thinking about some of your other statements - but if you need synchronization here, couldn't you just put a synchronized block inside the constructor?

Me:

If only the problem in the Swing example existed, you could, I think, but then, what's the reason for not allowing constructors to be synchronized again?

I take it back - you couldn't. You can put a synchronized block inside the constructor, but it can't include the call to the superclass constructor - or at least my compiler won't let me do it. So if the superclass constructor registers with another object, as in the Swing example above, then another thread can synchronize on the object in between the call to the superclass constructor and the rest of the constructor before the object is entirely initialized.

(Of course, if I had my druthers, the call to the superclass constructor wouldn't be required to be at the beginning of the constructor; it would just have to be there somewhere.)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Q for Herbert : Java 5 wish list