Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Q for Herbert : Java 5 wish list

 
George Harley
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Static imports. Something that makes really good sushi.
[ August 25, 2004: Message edited by: Dirk Schreckmann ]
 
Herb Schildt
Author
Ranch Hand
Posts: 253
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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?
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 253
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I could go for some really good sushi...
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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....
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic