Skip to main content

Some new features for Java 7

22 replies [Last post]
karnokd
Offline
Joined: 2006-09-19

Hello,
I have the following suggestions for the next release of Java JDK:
1.) Simpler cast&assign
As in C# and Delphi it would be nice to have the following syntax for casting and assigning:
List list = obj as List;
where the 'as' operator might work as if:
List list = obj instanceof List?(List)obj:null;
2.) Extend the NullPointerException facility to allow better location of the cause.
For example let's see the following long method call:
Object obj = someobj.getValue().get(0).getFirstChild().getNodeValue();
which might throw NullPointerException in any of the dot operator place. If so, the RT should somehow explicitly point out where this happend in the previous line by telling not only the error line but the error character position of the causing dot operator (in this case the last one is a good candidate). This might ease the debugging and tracing through the code by allowing the developer to start at a specific code fragment, instead of looking for every part of the expression for potential null value.
3) Create annotation of javadoc tag for null result possibility
Additional to 2.) there might be a new annotation or javadoc tag for tagging a method if it can return a null as result. In an IDE or the compiler can then check by itself at the invocation site whether the result is checked against null before usage and issue a warning:
/** @null if key is not found */
public Object get(Object key) { return myHashTbl.get(key); }

Also marking a method as not null might note that the invoker should not expect a null to be returned.
/** @notnull if value is null then an empty string is returned */
public String toStr(Object value) { return value!=null?value.toString():""; }

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aberrant
Offline
Joined: 2006-02-02

Backquotes are considered in bad taste? D'oh .. I did a simple multi-line string literal hack and used backquotes because I thought "hay look backquotes are not used". Are these rules posted somewhere?

aberrant
Offline
Joined: 2006-02-02

I'll jump on this bandwagon.

I'd like the following:

Throwable listeners on threads. Listeners would be notified any time an exception is throw in a thread.

Example:

Thread.currentThread().addThrowableListener(new ThrowableListener(){
public void thrown(Throwable t){
t.printStackTrace();
}
});

Now even when code like this is hidden somewhere :

try{
... stuff
}catch(Exception e){
// do nothing
}

I can get some indication of whats going wrong. It might also be good for logging.

I'd also like to be able to implement interfaces with Enums. This was I can group standard operations.

public enum CutCopyPasteEnum implements ActionListener {
CUT{
public void actionPerformed(ActionEvent e) {
// standard CUT operation
}
},
COPY{
public void actionPerformed(ActionEvent e) {
//standard copy operation
}
},
PASTE{
public void actionPerformed(ActionEvent e) {
// standard paste operation
}
}
}

How about enums for reflection identifiers in addition to strings? This might be useful for binding.

class BeanThingie{
public String stuff;
public String getStuff(){
return stuff;
}
}

BeanThingie.METHOD_ENUM getStuffID = BeanThingie.METHOD_ENUM.getStuff();
Method stuffMethod = BeanThingie.class.getField(getStuffID);

and

BeanThingie.FIELD_ENUM stuffID = BeanThingie.FIELD_ENUM.stuff;
Field stuffField = BeanThingie.class.getField(stuffID);

It's even possible that the Emuns could implement common reflection methods like getValue() or invoke();

Object value = BeanThingie.FIELD_ENUM.stuff.get(new BeanThingie());

This may shift some of reflection stuff to compile time instead of runtime. Which for binding I think is a good thing.

I know, I know.. I broke the rules by not having a syntactic sugar request. Oh well I'll try harder next time.

karnokd
Offline
Joined: 2006-09-19

I don't know.
I would disallow the underscore character to be used in identifiers other than constants.

jaypeevoss
Offline
Joined: 2004-02-20

One enhancement that I would assume should be pretty easy to implement would be to allow more than one variable-arity argument for methods. Of course, delimiting would need to be modified in order to avoid ambiguities, but this could easily (and easily readable) done by ending any var-arg list which is not the terminal argument in a method call by a semicolon instead of a comma.

To make things clearer, an example:

Let a method be defined, e.g., as

[code]
public void foo(String s, Bar... bars, int i, Object... objects, Foo... foos) {...}
[/code]
This method could then be invoked like this:

[code]
foo("hi", bar; 42, ; foo1, foo2);
[/code]
or - if you don't like a comma immediately followed by a semicolon - in this way (still room for discussion):

[code]
foo("hi", bar; 42; foo1, foo2);
[/code]
Easy, isn't it? And zero new keywords, zero percent ambiguity, one hundred percent backward-compatibility.

Regards,
Jens

P.S.: BTW, would discussing enhancements like this in this forum create an actual chance for implementation, or would I need to create an "official" enhancement request somewhere?

karnokd
Offline
Joined: 2006-09-19

There might be a new enhancement - I know it's complicated:
Let the developer choose at design time (run time) the type of the Garbage Collector algorithm, and its parameters. As far as I know, there is currently one GC algorithm for the applications on the same JVM. Different application might benefit from different gc algorithms.
Maybe there is already a JSR for that?

Message was edited by: karnokd

Message was edited by: karnokd

charlesabreu
Offline
Joined: 2004-10-23

> 1.) Simpler cast&assign
> As in C# and Delphi it would be nice to have the
> following syntax for casting and assigning:
> [b]List list = obj as List;[/b]
> where the 'as' operator might work as if:
> [b]List list = obj instanceof
> List?(List)obj:null;[/b]

And what would you do in the null case?

karnokd
Offline
Joined: 2006-09-19

Two possible options:
- return null
- same as the result of [b](obj instanceof List)?obj:null;[/b]
I'm not sure it's null or a NPE at the moment.

jmcmilla
Offline
Joined: 2004-05-04

Hello

1) If you really want this, you can make various utiliy methods, e.g.

public static List asList(Object object) {
return obj instanceof List?(List)obj:null;
}

2) That would actually be quite nice, I have no idea how possible it is for that to be implemented though. I think extra debug information would need to be added to the class when it is compiled. I'm sure if it could be implemented for NullPointerException if could be applied to other exceptions as well.

3) There is already a "Annotations for Software Defect Detection" JSR 305, which includes an @NotNull annotation, and tools like FindBugs and PMD already use versions of these annotations.

James

atehrani
Offline
Joined: 2004-01-14

1.) I do like it, but it's syntactical sugar.

2). Honestly you shouldn't be doing that many calls without checking for null. I know it may make your code more verbose. But it makes it more readable and more reliable.

3). This is actually being worked on. IntelliJ has a feature similar to this. Please look at JSR 305. We are working on annotations in order to help static analysis tools to find potential defects. We are open to ideas/comments.

Message was edited by: atehrani

karnokd
Offline
Joined: 2006-09-19

1.) Yes, of course it's only a syntax, we can live without it
2.) This NPE usually happens when I forget to initialize a field in my code, and get the exception during the test phase. It would be nice without debugging which member access caused it, when it's not so trivial.
3.) Thank you for the JSR, I'll look inside.

swpalmer
Offline
Joined: 2003-06-10

I like the @null annotation. Though I can see how it would get misused if the code is changed and the annotation is not. So it must only be a warning, but it is helpful, much like @Override

karnokd
Offline
Joined: 2006-09-19

But unlike @Override, it migth be possible to check whether it's rigth, just like the throws clause, just like @deprecated.
If @null/@notnull is omitted, you can't say anything sure about the method.
If it is flagged as @null, but none of the return paths contain a null or a used method flagged as @null it can be a warning too.
This feature would be useful for library developers and users. Not just looking at the (sometimes missing) javadoc for clues about returning null.
Of course, this might lead us to the AOP though.

But I think the proposed 2nd enhancement would do us much better. I'm sure it's not possible to report the complete expression in case of NPE, but at least the char offset would be good.
Or should I write each member access in a different line?

coding
Offline
Joined: 2006-06-21

If this
List list = obj as List;
Was this
List list = obj instanceof List?(List)obj:null;

If this was included in 7 I would stop preferring Java code forever. I'd rather get a ClassCastException than an NPE in an unrelated place in my code.

That's like begging for NPEs everywhere. NPEs typically come from lack of understanding state changes in the formal sense. Control your state rather than fixing your state later on down the code path.

karnokd
Offline
Joined: 2006-09-19

For example this might replace these kind of checks and spare one cast:
if (obj != null && obj instanceof List) { // cast 1
List list = (List)obj; // cast 2
...
} // no else
with
List list = obj as List; // cast 1
if (list != null) {
...
}
In C# and Delphi this was noticed from the beginning. Now imagene them in a loop of 1000000 iterations.

Let's hope the native XML support, the closures and others won't drive away too many Java developers.

forax
Offline
Joined: 2004-10-07

karnokd, the VM (at least hotstop) already recognized pattern like this
and doesn't check the type hierarchy twice.

So what you propose is a premature optimisation.

Rémi

karnokd
Offline
Joined: 2006-09-19

Thank you, I'm relieved.

ulfzibis
Offline
Joined: 2005-02-18

I would be nice to have this additional syntax.

I also would appreciate if we would have extended syntax for [b]switch .. case[/b] statements.

See:
-> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5012262
-> http://forums.java.net/jive/thread.jspa?threadID=504

mzbz
Offline
Joined: 2005-06-27

Hello,

the cast&assign idea is nice, but I would like to see it extended like this:

public int getSize(Object o) {
[b]using (o as Collection) {[/b]
return o.size();
[b]} else using (o as String) {[/b]
return o.length();
[b]} else {[/b]
throw new Exception("Unknown class " + o.getClass().getName());
[b]}[/b]
}

Advantages:

a) Less code because type checking happens automatically
b) Less variables, just re-use the existing name
c) Efficient execution because type checking and type cast can happen at the same time

cayhorstmann
Offline
Joined: 2003-06-13

That's all good and well, but you are forgetting an essential rule of the "I want this new language feature" game, namely to propose a syntax that doesnt require new keywords. After all, we wouldn't want to break all gazillions of lines of code that contain variables or methods called "as" or "using".

Reuse existing keywords in innovate ways. Or, if all else fails, use [b]static[/b]. You can use tokens such as : or * but using backquotes ` ` is considered in bad taste. And you should not use # because everyone has that reserved for some extra-special need.

How about

[b]case[/b](o : Collection) {
. . .
} [b]else case[/b] (o : String) {
. . .
} [b]else[/b] {
. . .
}

See, that wasn't so hard :-)

karnokd
Offline
Joined: 2006-09-19

Okay, I can live without new keywords. What about new NullPointerException location and the @null annotation/tag?

i30817
Offline
Joined: 2006-05-02

Wouldn't it be great to just remove null pointers?

Create a special Singleton object class NULL for each loaded class, that has for the return of each method and public fields another class whatever NULL. This would remove null pointer exceptions.

karnokd
Offline
Joined: 2006-09-19

We would loose the meaning of the NullPointerException: signal that you have forgotten to initialize a field or check for null.