The Artima Developer Community
Sponsored Link

Java Community News
What's On Your Java SE 7 Wish List?

19 replies on 2 pages. Most recent reply: Jan 5, 2007 2:44 PM by Gregor Zeitlinger

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 19 replies on 2 pages [ 1 2 | » ]
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

What's On Your Java SE 7 Wish List? Posted: Dec 27, 2006 5:21 PM
Reply to this message Reply
Summary
Peter Ahé as posted a wish list on his blog for the next version of the Java programming language: SE 7. What's on your wish list for the next version of Java?
Advertisement

Now that Java SE 6 has been officially released, it is a good time to think about the future of Java. In Java SE 7 Wish List, Peter Ahé's wishes for these enhancements in Java's next version, SE 7:

  • Closures
  • Type Literals
  • Super Packages
  • Improved Type Inference
  • Shorthand Syntax for Declaring Local Variables
  • Shorthand Syntax for Declaring Properties
  • Type Aliasing
  • Array Syntax for Collections
  • More Factory Methods for Collection Classes
  • Self Types
  • Improved Compiler Diagnostics

What do you think of the items on Peter's list, and what is on your wish list for the next version of Java?


Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: What's On Your Java SE 7 Wish List? Posted: Dec 28, 2006 3:30 AM
Reply to this message Reply
I don't care about Java the language, but I wish JVM supported tail call optimization, and big integers where values which fit in a machine word minus a bit or two are unboxed.

This would make targetting JVM by compilers of some languages practical.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What's On Your Java SE 7 Wish List? Posted: Dec 28, 2006 12:31 PM
Reply to this message Reply
> I don't care about Java the language, but I wish JVM
> supported tail call optimization

I don't know about JVM support but Scala has tail optimization. Is their approach not acceptable for some reason?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What's On Your Java SE 7 Wish List? Posted: Dec 28, 2006 2:11 PM
Reply to this message Reply
Hmmm...

1. Shorthand delegation

class MyStringList implements List<String> {
    protected delegate List<String> _list = new ArrayList<String>();
    boolean add(String val) {
        // do something special
        return _list.add(val);
    }
}


Then the compiler generates the implementations for the methods defined in List where methods are not explicitly defined in MyStringList that simply pass the call along to _list.

2. Operator overloading controlled very strictly using generic interfaces.

3. Separate collection interface definitions for "readonly" collections that don't have mutator properties.

4. Shorthand for generating JavaBean properties that delegate get/set methods to another object

class MyProperty<T> implements Property<T> {
   public T get() { return _val; }
   public void set(T obj) {
   // check obj, send event notifications, etc...
   _val = obj;
 }
   private T _val;
}
 
class Foo {
   private property MyProperty<T> _name = new MyProperty();
}


That way behavior, such as value checking and event generation can be concisely generated. I'd like the arrow operator notation for it, too, but that's less important.

That's enough for now...

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: What's On Your Java SE 7 Wish List? Posted: Dec 28, 2006 2:18 PM
Reply to this message Reply
I'm curious how badly would it break compatibility to move an exception from being checked to being unchecked? Some exceptions seem to be wrongly declared as Exceptions rather than RuntimeExceptions in various places in the Java API. For example, one that I always catch and wrap after passing a constant "UTF-8" to is UnsupportedEncodingException thrown by java.net.URLEncoder's encode method. This extends IOException so moving it under RuntimeException would break code that is catching those as IOExceptions. But if something extends Exception that maybe ought not to, would it break much code to move it to RuntimeException?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Ok I have more... Posted: Dec 28, 2006 2:38 PM
Reply to this message Reply
5. Something like the Python "with" statement for RAII

http://docs.python.org/whatsnew/pep-343.html

6. A tagging interface that marks a class as immutable

-------------------

Basically, I think Java should be enhanced to more explicitly and concisely support common, widely understood OO design patterns. Likewise, I'm not a fan of adding features like closures that are much more foreign to the Java world. It's not that I have anything against closures. They're great in Lisp and Smalltalk (and I suppose Ruby). But they just don't fit with Java.

Anoop Kumar

Posts: 1
Nickname: anoopkumar
Registered: Dec, 2006

Re: What's On Your Java SE 7 Wish List? Posted: Dec 28, 2006 9:37 PM
Reply to this message Reply
I only wish Java realtime is enhanced - and performance made closer to native apps... Swing is one place I wish major improvements.. in speed.

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 6:21 AM
Reply to this message Reply
> I don't know about JVM support but Scala has tail optimization.

Scala only optimizes tail recursion, not tail calls in general.

As it happens, my language Kogut uses quite a lot of tail calls which are not tail recursion and whose transformation to jumps is essential. Namely returning an optional value, or returning a "tagged union" which would normally be dispatched immediately after the call, is often expressed with CPS: the function takes continuations as additional arguments, which are functions to be tail-applied and specify how to proceed in each case. The syntax has special support for wrapping the rest of the scope in a function passed as the last argument.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 10:03 AM
Reply to this message Reply
> I'm curious how badly would it break compatibility to move
> an exception from being checked to being unchecked?
It would not break backwards compatability at all
- except for awkward cases where somebody catches RuntimeExceptions.

> Some exceptions seem to be wrongly declared as
> Exceptions rather than RuntimeException
No, all checked exceptions are wrongly declared as checked exceptions. Since this thread came up on Artima, I converted to making all my exceptions runtime exceptions with the result that
1) the code is easier to read
2) the code is safer (the likelyhood of swallowing exceptions is smaller)
3) stack traces are easier to understand - you only need to wrap cheched excpetions once (such as SQLException, which you cannot make runtime exceptions).

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 11:09 AM
Reply to this message Reply
> No, all checked exceptions are wrongly declared as
> checked exceptions. Since this thread came up on Artima, I
> converted to making all my exceptions runtime exceptions
> with the result that
> 1) the code is easier to read
> 2) the code is safer (the likelyhood of swallowing
> exceptions is smaller)
> 3) stack traces are easier to understand - you only need
> to wrap cheched excpetions once (such as SQLException,
> which you cannot make runtime exceptions).

Is that because checked exceptions are bad or because Exception hierarchies are poorly designed and error handling code is almost always a poorly crafted afterthought?

I agree that unchecked exceptions would make almost all of the code I've seen better, but I don't think I've ever seen a well-defined set of exceptions.

Look at the JDBC exceptions...SQLExceptions for everything? There's a big difference between loosing connectivity to the database (probably should be unchecked), malformed SQL or SQL that is invalid against the schema (again, probably should be unchecked), and constraint violations (should be checked). JDBC4 is a step in the right direction, but where's the method to, say, obtain the name of the constraint that was violated? The name of the table and/or column to which the constraint applies? Sure, it's in the message, but how do I programmatically use it? So there's another problem - lack of useful information inside of the exception.

So if we had well designed exception classes that contained useful information, would checked exceptions be so bad?

Victor Volle

Posts: 2
Nickname: vivo
Registered: Aug, 2006

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 1:03 PM
Reply to this message Reply
+1 on Closures
and I would love of getting rid of reading (writing is not really an issue) all the dumb getters and setters, so something like C#/Eiffels properties would be great

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 1:06 PM
Reply to this message Reply
> Is that because checked exceptions are bad or because
> Exception hierarchies are poorly designed and error
> handling code is almost always a poorly crafted
> afterthought?
That's not an either or question.
Checked exceptions are bad - period.

Both your exception handling code and your exception hierarchies should be centered around the one central question:

What is my failure strategy?

For most applications, fail-fast is probably the best choice. Fail-fast means that you don't try to recover from exceptions, you just report them - so that the bug can be fixed. You only ever catch exceptions (I'm not talking about try-finally), in one of the following situations
1) you are calling a legacy method (which declares checked exceptions)
2) you want to add context (such as line number of a parsed file) to an exception. In that case, you catch Exception, not a subclass, such as SQLException.

If your application needs to work even in the presece of errors, you need to catch exceptions in one (or a few) central place(s) per thread. In those places, you can retry an operation or roll back to some save point that you created earlier.
In this scenario, it is important that you do not try to deal with the errors in other places (it will only prevent the save point from being restored). Here, again, checked exceptions get in your way.

Regarding the fact that most exception handling code is crap:
Yes, it's crap - but the design of checked exceptions are partly to blame for that. It forces developers to write useless boilerplate code where it makes no sense.
Even worse, it sometimes prevents a consistent failure strategy. For example, if a library logs an error (instead of throwing an exception), you cannot implement fail-fast or roll back to some checkpoint.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 1:51 PM
Reply to this message Reply
> > Is that because checked exceptions are bad or because
> > Exception hierarchies are poorly designed and error
> > handling code is almost always a poorly crafted
> > afterthought?
> That's not an either or question.
> Checked exceptions are bad - period.

Well, I'm not convinced that they are inherently bad, just that they have been poorly applied.

> Both your exception handling code and your exception
> hierarchies should be centered around the one central
> question:
>
> What is my failure strategy?

Yes, but it depends on the type of failure. A program can "fail" because it contains flaws in its logic, because something out of its control has changed in its environment, because it was setup improperly, or simply because it received bad input from the user.

> For most applications, fail-fast is probably the best
> choice. Fail-fast means that you don't try to recover from
> exceptions, you just report them - so that the bug can be
> fixed.

What if it's not a bug but rather user input? Configuration done by an administrator? A transient unexpected state, such as a database being down?

> You only ever catch exceptions (I'm not talking
> about try-finally), in one of the following situations
> 1) you are calling a legacy method (which declares checked
> exceptions)
> 2) you want to add context (such as line number of a
> parsed file) to an exception. In that case, you catch
> Exception, not a subclass, such as
> SQLException.
>
> If your application needs to work even in the presece of
> errors, you need to catch exceptions in one (or a few)
> central place(s) per thread. In those places, you can
> retry an operation or roll back to some save point that
> you created earlier.
> In this scenario, it is important that you do not try to
> deal with the errors in other places (it will only prevent
> the save point from being restored). Here, again, checked
> exceptions get in your way.

Ahh yes, if an exception is thrown because user input caused a constaint to be violated in the database, two things need to happen:

1) The transaction needs to be rolled back and any resources cleaned up - and I agree that a centrally managed strategy is best for this (when possible)
2) The user needs to be informed what is wrong and how to fix it

What you are advocating achieves #1 and fails on #2. That's fine for errors that are beyond the user's control, but it's bad for ones that are under the user's control.

Transaction rollback, resource cleanup, etc. should be more orthogonal to the main application logic and really should be done as the stack unwinds, preferably using an RAII type pattern or under today's Java reality with try/finally.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 2:38 PM
Reply to this message Reply
> What if it's not a bug but rather user input?
If a user input leads to exception (which should be avoided where possible), you have to catch it, of course.

> Configuration done by an administrator? A transient
> t unexpected state, such as a database being down?
see error recovery (rolling back to save point).
Basically, it doesn't matter if it's an implementation error or a configuration error, you have to roll back. In contrast, it's good to know if the error is transient, to know if retry makes sense - that's where exception hierarchies help (like JDBC4)

> Ahh yes, if an exception is thrown because user input
> caused a constaint to be violated in the database, two
> things need to happen:
>
> 1) The transaction needs to be rolled back and any
> resources cleaned up - and I agree that a centrally
> managed strategy is best for this (when possible)
user input verification should NOT be done centrally - and it doesn't have to do anything with the failure strategy.

> 2) The user needs to be informed what is wrong and how to
> fix it
of course. Better yet, it should not be possible to enter malformed input (e.g. dates in the future).

> What you are advocating achieves #1 and fails on #2.
> That's fine for errors that are beyond the user's
> s control, but it's bad for ones that are under the user's
> control.
I don't understand your question

> Transaction rollback, resource cleanup, etc. should be
> more orthogonal to the main application logic and really
> should be done as the stack unwinds, preferably using an
> RAII type pattern or under today's Java reality with
> try/finally.
yes, but resource cleanup only a basic requirement for a "failure strategy".

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: What's On Your Java SE 7 Wish List? Posted: Dec 29, 2006 3:52 PM
Reply to this message Reply
> > Is that because checked exceptions are bad or because
> > Exception hierarchies are poorly designed and error
> > handling code is almost always a poorly crafted
> > afterthought?
> That's not an either or question.
> Checked exceptions are bad - period.
>
>
We shouldn't be afraid to ask. Is it not a backwards compatible change to Java to remove exception checking from the compiler and instead move it to a separate static analyzer? Trouble here is that I believe the VM checks it too, but nowadays they bump the version of the class file such that if the VM doesn't recognize the version it doesn't load it. Would this be possible?

I don't think checked exceptions are bad - period, because they have helped me sometimes. My feeling is the benefit of having them checked by the Java compiler in practice turned out largely to be not worth the cost. What could be done instead is to move this checking to a static analyzer that is NOT the compiler, which would give warnings. By default it would not warn if a RuntimeException or Error was not caught. But we could be able to configure the analyzer to not give certain warnings for Exceptions. For example, I could say don't warn me that UnsupportedEncodingException is not caught when calling URLEncoder.encode(String, String). I could say don't count this particular catch all clause at the top of my web app as "catching."

OK, that's now on my wish list.

Flat View: This topic has 19 replies on 2 pages [ 1  2 | » ]
Topic: Cross-Cutting Concerns with Spring 2.0 AOP Previous Topic   Next Topic Topic: Custom Bean Scopes with Spring

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use