FW: RE: Exception handling Was: Future JDK features 2 items
A definite +1 for multiple exceptions in a catch{} block.
I have had a number of times I have wanted to do this,
but have had to create a private method and refer all
catch{} blocks to it.
Dan Lydick
[Original Message]
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Date: 10/29/04 12:38:48 PM
Subject: Exception handling Was: Future JDK features 2 items
2/
How about just being able to do multiple Exceptions in one block?
try {
} catch(JMSException, RemoteException, SQLException e) {
}
or possibly even:
try {
} catch( (JMSException | RemoteException | SQLException) e) {
}
The last one is interesting as it could be a larger concept allowing
mixed-types; but from a finite set. Probably lots wrong with that idea :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features - performance and stability
I can't run Javadoc 1.5.0 on my Win98 SE box. Got null pointer exception on working 1.4.2 source code in the standard doclet(see below). Had to revert to Javadoc 1.4.2, but then it wouldn't pick up the language updates. Oh well, at least I have the 1.5.0 startup improvements should I choose to seriously go to 1.5. Dan Lydick [Original Message] From: Dain Sundstrom [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Date: 10/29/04 12:39:28 PM Subject: Re: Future JDK features - performance and stability Oh and the new GC bugs in 1.5 are totally annoying. -dain - java.lang.NullPointerException at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUse(Packa geUseWriter.java:180) at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageList(Pack ageUseWriter.java:124) at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUse(Packa geUseWriter.java:110) at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUseFile(P ackageUseWriter.java:99) at com.sun.tools.doclets.formats.html.PackageUseWriter.generate(PackageUseWrite r.java:78) at com.sun.tools.doclets.formats.html.ClassUseWriter.generate(ClassUseWriter.ja va:116) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet. java:92) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(Abstra ctDoclet.java:122) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.j ava:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sun wants Apache input on JDK futures
Although this enhancement to java.lang.Thread has not been shouted down, I have not heard any other comments, either. It proposes (1) a built-in orderly way to inform a thread to terminate itself and (2) a way to contol suspend/resume of a thread. All critique is welcome. Dan Lydick [Original Message] From: Noel J. Bergman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Date: 10/25/04 10:19:05 AM Subject: Sun wants Apache input on JDK futures Sun is the final stages of collecting requirements for the releases that will follow Tiger, which means the next 3 years. So here's your chance to tell Sun what you would like to see in J2SE versions 6 and 7. Once we gather all of the ideas, we can try to see if we can prioritize the list. ...snip... --- Noel My $0.02 worth, having just gotten started w/ JDK 1.5, but don't see these related features available: 1. The new java.lang.Thread.State class adds the capability to determine the current state of a given java.lang.Thread. However, the Thread class also needs to have a built-in equivalent to a mechanism that must currently be supplied by the user. In the bad old days, you used Thread.stop() to kill a thread. However, that would leave resource locks in place. Therefore, the common wisdom became for the user to declare a boolean that the thread could periodically poll and shut itself down in an ordered fashion after releasing resource locks and any other cleanup. I would like to see a mechanism built into java.lang.Thread that would to this on a language-wide basis. Perhaps a method with a parameter called 'Thread.setRequestedState(Thread.State reqState)' where a shutdown would call 'Thread.setRequestedState(Thread.State.TERMINATED)'. When that thread polls the requested state value (perhaps using a 'private ThreadState requestedState') using a method 'Thread.getRequestedState()', then it could initiate its shutdown sequence. 2. This is similar to the suggestion from Stefano Mazzocchi about suspending a thread and resuming. In this case, a thread could be suspended by doing a 'Thread.setRequestedState(Thread.State.WAITING)' followed by an un-suspend with 'Thread.setRequestedState(Thread.State.RUNNABLE)'. This would be functionally equivalent to Thread.notify()/notifyAll(), but would be thread-specific, not setting the state of some random thread or all threads. I say that is a syntactic improvement because Thread.notify() never tells the casual reader what thread will be made RUNNABLE again, even if there is only one possible thread that could get so marked. The full prototypes would be, for get req state: Thread.State getRequestedState() boolean setRequestedState(Thread.State newState) throws IllegalArgumentException When setRequestedState() succeeded, it would return 'true'. If it could not set that state, it would return 'false'. If anything but TERMINIATED, WAITING, or RUNNABLE were requested, it would throw IllegalArgumentException. Notice the distinct resemblance to '(Thread.State) Thread.getState()'. This returned the _current_ state, where the above discussion sets and gets the _requested_ state. Notice that, again refering to Mr. Mazzocchi's post, this approach would also work with JNI. All that is required is for the JVM to accept the requested states TERMINATED, WAITING, and RUNNABLE. Dan Lydick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: RE: Future JDK features 2 items
[Original Message]
From: Danny Angus [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: 10/26/04 3:17:32 AM
Subject: Future JDK features 2 items
1/ Ok don't flame me... Method pointers
But still, be sure to watch for flames from the
Purist Society! They _do_ have a point, ya know.
I *know* it is possible to accomplish all the delegation one might want by
using polymorphism, but this often leads to unncessary screeds of
boiler-plate,
so I still I believe there is a case for some kind of streamlining of
delegation by allowing it to be achieved on a method level rather than at
a
class level.
For instance it might make sense for a Class to provide several sort
methods, polymorphism would require this class to implement a different
interface for each one, function pointers could be used instead to have a
method take a parameter and return a refrence to the appropriate method
thereby correctly (IMHO) encapsulating the decision/conditions within the
class and not exposing it externally.
In order to support such a concept, there would
necessarily be a severe restriction on what such
a method pointer reference object could do and
how it was specified. The 'C' function-through-pointer
syntax might be very useful here, but, as Mr. Angus
says, return a _reference_ instead of a _pointer_.
Try this on for size, from ANSI 'C' syntax:
public (int methodName)(Integer parm2);
or,
public (int)(Integer parm2) methodName;
Notice that the argument names should be optional
since it is the object type that is important here.
I would prefer the first syntax since it looks more
like how it would be invoked, method name followed
by its parameters. It would be used like,
if (0 == comparableObjectIsParm1.methodName(parm2)) {...}
or generically,
pre
sampleCompareMethod(ImplementsComparable comparableObject,
Integer compareWith)
{
private (int compareMethod)(Integer);
switch(compareMode)
{
case 1: compareMethod = ParentClass.parentCompareMethod;
case 2: compareMethod = SubClass1.sub1CompareMethod;
case 3: compareMethod = SubClass2.sub2CompareMethod;
}
return(comparableObject.compareMethod(compareWith));
}
In a similar way, and probably not quite what Mr. Angus
is suggesting,
sampleCompareMethod(ImplementsComparable comparableObject,
Integer compareWith)
{
private (int compareMethod)(Integer);
switch(compareMode)
{
case 1: compareMethod = SomeClass.compareMethod1;
case 2: compareMethod = SomeClass.sub1CompareMethod2;
case 3: compareMethod = SomeClass.sub2CompareMethod3;
}
return(comparableObject.compareMethod(compareWith));
}
/pre
Notice again that the local variables do not need
to have a name for the formal arguments, just
their types.
Using such syntax provides a simple way to
build function-through-pointer tables.
The table would only care about the return
type, not in the parameter list. Here is
where the second form would be useful, namely,
for those that like their [brackets] to _follow_
the variable definition, although I will show
it in both forms:
public (int methodName)(Integer)[];
and,
public (int)(Integer) methodName[];
To me, the latter expression is easier to
identify as an array of (int method(Integer parm)
than the first one.
The overarching question here is, How does this
concept fit into the OO philosophy? That is for
the Java LEX/YACC-oids to figure out! Mr. Angus'
idea is a very practical one, if not very conventional,
and I have run across this issue before. Of course,
solving it until now involves a compareTo() method
in a bunch of subclasses in a normal setting, but
there have been times...
Dan Lydick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: RE: Future JDK features 2 items
[Original Message]
From: Bernhard Fastenrath [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Date: 10/26/04 2:09:02 PM
Subject: Re: FW: RE: Future JDK features 2 items
Dan Lydick wrote:
From: Danny Angus [EMAIL PROTECTED]
1/ Ok don't flame me... Method pointers
...
Your example can as easily use class references as it can be written
using method pointers.
Where's the advantage of a method pointer?
Maybe Mr. Angus wasn't going here, but behind my
concept was work I have done in C/C++ with arrays
of function-through-pointer for varied functionality
depending on context.
class ImplementsComparable {
}
sampleCompareMethod (ImplementsComparable comparableObject,
Integer compareWith)
{
}
This approach might do the job just as well.
What say you, Danny Angus?
If the parameters have different names it's likely they have different
types so
you would probably want to invoke methods with the exact same parameter
list,
which defeats your argument that not knowing parameter names is an
advantage.
The naming of C/C++ parameters in function prototypes is often skipped
as long as the type is known. Nobody cares except the implementation
of the actual method. The downside is that you have to know the
exact prototype in order to reference it, and prototype header files is
part of what Java is trying to get away from.
The main difference is that in the earlier piece of code methods are
wrapped
in inner classes, which amounts to about 30 additional characters you
have to
type: class FooBar { ... } implements I for each class, one
instantiation
for each class and a common interface.
Good point. Thanks for your observation.
Dan Lydick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sun wants Apache input on JDK futures
[Original Message] From: Noel J. Bergman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Date: 10/25/04 10:19:05 AM Subject: Sun wants Apache input on JDK futures Sun is the final stages of collecting requirements for the releases that will follow Tiger, which means the next 3 years. So here's your chance to tell Sun what you would like to see in J2SE versions 6 and 7. Once we gather all of the ideas, we can try to see if we can prioritize the list. I have created a wiki page to collect the information. Please DO NOT reply to this message. Instead, please use [EMAIL PROTECTED] (so that we have one open list) to discuss your ideas. PLEASE NOTE: In order for this information to have the most impact, Sun needs it by end of this week (October 29th). [The short time is not Sun's fault. They had asked earlier in the summer, but the ball got dropped. I just ran into the J2SE lead, who raised the issue again]. --- Noel My $0.02 worth, having just gotten started w/ JDK 1.5, but don't see these related features available: 1. The new java.lang.Thread.State class adds the capability to determine the current state of a given java.lang.Thread. However, the Thread class also needs to have a built-in equivalent to a mechanism that must currently be supplied by the user. In the bad old days, you used Thread.stop() to kill a thread. However, that would leave resource locks in place. Therefore, the common wisdom became for the user to declare a boolean that the thread could periodically poll and shut itself down in an ordered fashion after releasing resource locks and any other cleanup. I would like to see a mechanism built into java.lang.Thread that would to this on a language-wide basis. Perhaps a method with a parameter called 'Thread.setRequestedState(Thread.State reqState)' where a shutdown would call 'Thread.setRequestedState(Thread.State.TERMINATED)'. When that thread polls the requested state value (perhaps using a 'private ThreadState requestedState') using a method 'Thread.getRequestedState()', then it could initiate its shutdown sequence. 2. This is similar to the suggestion from Stefano Mazzocchi about suspending a thread and resuming. In this case, a thread could be suspended by doing a 'Thread.setRequestedState(Thread.State.WAITING)' followed by an un-suspend with 'Thread.setRequestedState(Thread.State.RUNNABLE)'. This would be functionally equivalent to Thread.notify()/notifyAll(), but would be thread-specific, not setting the state of some random thread or all threads. I say that is a syntactic improvement because Thread.notify() never tells the casual reader what thread will be made RUNNABLE again, even if there is only one possible thread that could get so marked. The full prototypes would be, for get req state: Thread.State getRequestedState() boolean setRequestedState(Thread.State newState) throws IllegalArgumentException When setRequestedState() succeeded, it would return 'true'. If it could not set that state, it would return 'false'. If anything but TERMINIATED, WAITING, or RUNNABLE were requested, it would throw IllegalArgumentException. Notice the distinct resemblance to '(Thread.State) Thread.getState()'. This returned the _current_ state, where the above discussion sets and gets the _requested_ state. Notice that, again refering to Mr. Mazzocchi's post, this approach would also work with JNI. All that is required is for the JVM to accept the requested states TERMINATED, WAITING, and RUNNABLE. Dan Lydick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sun wants Apache input on JDK futures
[Original Message] From: Noel J. Bergman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Date: 10/25/04 10:19:05 AM Subject: Sun wants Apache input on JDK futures Sun is the final stages of collecting requirements for the releases that will follow Tiger, which means the next 3 years. So here's your chance to tell Sun what you would like to see in J2SE versions 6 and 7. Once we gather all of the ideas, we can try to see if we can prioritize the list. I have created a wiki page to collect the information. Please DO NOT reply to this message. Instead, please use [EMAIL PROTECTED] (so that we have one open list) to discuss your ideas. PLEASE NOTE: In order for this information to have the most impact, Sun needs it by end of this week (October 29th). [The short time is not Sun's fault. They had asked earlier in the summer, but the ball got dropped. I just ran into the J2SE lead, who raised the issue again]. --- Noel My $0.02 worth, having just gotten started w/ JDK 1.5, but don't see these related features available: 1. The new java.lang.Thread.State class adds the capability to determine the current state of a given java.lang.Thread. However, the Thread class also needs to have a built-in equivalent to a mechanism that must currently be supplied by the user. In the bad old days, you used Thread.stop() to kill a thread. However, that would leave resource locks in place. Therefore, the common wisdom became for the user to declare a boolean that the thread could periodically poll and shut itself down in an ordered fashion after releasing resource locks and any other cleanup. I would like to see a mechanism built into java.lang.Thread that would to this on a language-wide basis. Perhaps a method with a parameter called 'Thread.setRequestedState(Thread.State reqState)' where a shutdown would call 'Thread.setRequestedState(Thread.State.TERMINATED)'. When that thread polls the requested state value (perhaps using a 'private ThreadState requestedState') using a method 'Thread.getRequestedState()', then it could initiate its shutdown sequence. 2. This is similar to the suggestion from Stefano Mazzocchi about suspending a thread and resuming. In this case, a thread could be suspended by doing a 'Thread.setRequestedState(Thread.State.WAITING)' followed by an un-suspend with 'Thread.setRequestedState(Thread.State.RUNNABLE)'. This would be functionally equivalent to Thread.notify()/notifyAll(), but would be thread-specific, not setting the state of some random thread or all threads. I say that is a syntactic improvement because Thread.notify() never tells the casual reader what thread will be made RUNNABLE again, even if there is only one possible thread that could get so marked. The full prototypes would be, for get req state: Thread.State getRequestedState() boolean setRequestedState(Thread.State newState) throws IllegalArgumentException When setRequestedState() succeeded, it would return 'true'. If it could not set that state, it would return 'false'. If anything but TERMINIATED, WAITING, or RUNNABLE were requested, it would throw IllegalArgumentException. Notice the distinct resemblance to '(Thread.State) Thread.getState()'. This returned the _current_ state, where the above discussion sets and gets the _requested_ state. Notice that, again refering to Mr. Mazzocchi's post, this approach would also work with JNI. All that is required is for the JVM to accept the requested states TERMINATED, WAITING, and RUNNABLE. Dan Lydick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
