Small language changes

M

Mark Space

Sun appears to be soliciting some input from users for Java 7:

<http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7>


"I'm happy to announce that I'll be leading up Sun's efforts to develop
a set of small language changes in JDK 7; we intend to submit a JSR
covering those changes during the first half of 2009. However, before
the JSR proposal is drafted and submitted to the JCP, we'll first be
running a call for proposals so Java community members can submit
detailed, thoughtful changes for consideration too. We'll be seeding the
discussion with a few proposals we think would improve the language."


I thought some folks here might be interested in this effort.
 
T

Tom Anderson

Sun appears to be soliciting some input from users for Java 7:

<http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7>

Thanks for the tip. In principle, i'm very much pro-change. But then i
read the comments and see the things people are asking for, and i start to
think that no change is better than some change.

Of course, blog commenters are not a representative cross-section of
people making suggestions, and no suggestions will be taken on board
unless the mandarains at Sun like them. But still, most of the ideas
suggested are pointless, and many of them are actively harmful. Oh well.

tom
 
M

Mark Space

Tom said:
Thanks for the tip. In principle, i'm very much pro-change. But then i
read the comments and see the things people are asking for, and i start
to think that no change is better than some change.


I added a comment asking for annotations for thread safety. Worth a shot.

"How about some annotations for thread safety? I think these would
greatly enhance the documentation of the language.

The set from Java Concurrency in Practice would be acceptable.

@ThreadSafe
@NotThreadSafe
@Immutable
@GuardedBy(String)"
 
T

Tom Anderson

I added a comment asking for annotations for thread safety. Worth a shot.

"How about some annotations for thread safety? I think these would greatly
enhance the documentation of the language.

The set from Java Concurrency in Practice would be acceptable.

@ThreadSafe
@NotThreadSafe
@Immutable
@GuardedBy(String)"

Yes, those would be a good idea. There are potentially more that could be
useful, but that's a set that would be easy to get agreement on.

tom
 
L

Lew

Tom said:
Yes, those would be a good idea. There are potentially more that could be
useful, but that's a set that would be easy to get agreement on.

Do additions to the API count as language changes?

In the meantime, one can add such annotations locally without them
being part the official API.
 
J

Joshua Cranmer

Mark said:
"How about some annotations for thread safety? I think these would
greatly enhance the documentation of the language.

The set from Java Concurrency in Practice would be acceptable.

FindBugs already knows at least about @GuardedBy and @Immutable. I
believe @Immutable is coming into the language via another JSR anyways.

Granted, it would probably benefit most people to bring these
annotations into the core language itself.
 
M

Mark Space

Lew said:
Do additions to the API count as language changes?


No they don't. Joseph Darcy's blob makes that very clear.

In the meantime, one can add such annotations locally without them
being part the official API.


My hope is that with everyone using the same annotations, not various
local ones, then those annotations will eventually be treated specially
by the javadoc command, become part of the API, etc. But first they
need to get into the language.
 
L

Lew

Mark said:
No they don't.  Joseph Darcy's blob makes that very clear.

Mark said:
My hope is that with everyone using the same annotations, not various
local ones, then those annotations will eventually be treated specially
by the javadoc command, become part of the API, etc.  But first they
need to get into the language.

Annotations are part of the API, not the language.
JLS 9.6:
An annotation type declaration is a special kind of interface declaration..

So those annotations cannot be considered part of the language. They
are interfaces.
 
T

Tom Anderson

Annotations are part of the API, not the language.
JLS 9.6:

So those annotations cannot be considered part of the language. They
are interfaces.

So is SuppressWarnings not part of the language? How about the upcoming
NotNull?

I don't think it's productive to draw a hard and fast line between
language and library. In C, it might be possible, but in more
sophisticated languages like java, the line gets a bit blurry. Is
Throwable purely part of the library? Object? Class? I think classes like
that, and potentially some of the more fundamental annotations, straddle
the boundary.

Which is not, of course, to say that all classes are part of the language!
It depends on whether there are any special rules which apply to them.

I guess i was thinking that the compiler would treat the thread-safety
annotations specially in some way. Not changing the behaviour of the code,
but maybe enforcing some kind of rules about when they could be applied.
That would shift them towards the language-library border zone. I admit to
not having thought this through in any detail, though!

tom
 
L

Lew

Lew averred:
Tom said:
So is SuppressWarnings not part of the language? How about the upcoming
NotNull?

There was a reason why I asked if language changes were to be construed to
include API changes. First the answer was
Now it's
I don't think it's productive to draw a hard and fast line between
language and library. In C, it might be possible, but in more
sophisticated languages like java [sic], the line gets a bit blurry. Is

So is it "very clear" or "blurry"?

....
I guess i was thinking that the compiler would treat the thread-safety
annotations specially in some way. Not changing the behaviour of the
code, but maybe enforcing some kind of rules about when they could be
applied. That would shift them towards the language-library border zone.
I admit to not having thought this through in any detail, though!

Given the new "very clear" interpretation that certain API changes can be
construed as part of language changes, I agree with the points made.
 
S

Stefan Ram

Thomas Pornin said:
Actually, the C standard takes great care not to draw such a line.

Words in both C and Java are divided into keywords and identifiers.

(Roughly:)
The language defines the meaning of keywords, operators, punctuators,
separators, and so on;
the standard library defines the meaning of standard identifiers;
the programmer defines the meaning of other identifiers.
 
T

Tom Anderson

Words in both C and Java are divided into keywords and identifiers.

(Roughly:)
The language defines the meaning of keywords, operators, punctuators,
separators, and so on;
the standard library defines the meaning of standard identifiers;
the programmer defines the meaning of other identifiers.

Nice idea. But incorrect.

Given these two definitions:

public class Foo extends Object {}
public class Bar extends Exception {}

These two statements:

throw new Foo();
throw new Bar();

Are not equivalent in their legality, despite containing only the same
keywords.

Specifically, your definition defines the language as the syntax only,
whereas it also includes, fairly crucially, semantics.

tom
 
S

Stefan Ram

Tom Anderson said:
Are not equivalent in their legality, despite containing only the same
keywords.

To tell between the language and library does not mean to deny that
there are relations between the two.
Specifically, your definition defines the language as the syntax only,
whereas it also includes, fairly crucially, semantics.

What do you thing the word »meaning«, used thrice above, refers to?
 
W

Wojtek

Lew wrote :
... because the 'implements' keyword isn't clear enough.

It would be used to indicate which methods implement interface methods.
Similar to @Override for abstract. Yes I know you can use @Override for
implementations, but it is not manditory (at least not within Eclipse).
 
J

John B. Matthews

[QUOTE="Lew said:
I would like a manditory @Implements...

... because the 'implements' keyword isn't clear enough.[/QUOTE]

Well, we use @Override despite the clarity of the 'extends' keyword. By
like measure, I would consider an optional @Implements. While @Override
is surely clear and correct, I note that NetBeans distinguishes each
with a small circled 'I' or 'O' token to signify a matching signature.

Would there be a problem with writing this as a custom annotation?
 
L

Lew

Lew wrote :



It would be used to indicate which methods implement interface methods.
Similar to @Override for abstract. Yes I know you can use @Override for
implementations, but it is not manditory (at least not within Eclipse).

I get warnings about failing to use '@Override' for interface methods
in both Eclipse and NetBeans.

'@Override' already exists to show that interface methods are
overridden, so having another annotation to do the exact same thing
would be redundant.
 
L

Lew

[QUOTE="Lew said:
I would like a manditory @Implements...
... because the 'implements' keyword isn't clear enough.

Well, we use @Override despite the clarity of the 'extends' keyword. By
like measure, I would consider an optional @Implements. While @Override
is surely clear and correct, I note that NetBeans distinguishes each
with a small circled 'I' or 'O' token to signify a matching signature.[/QUOTE]

I had misunderstood the original suggestion. It didn't occur to me
that anyone would want '@Implements' to mean the exact same thing as
the current '@Override' annotation, so I wrongly concluded that they
wanted it to mean something different.
 

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,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top