Re: Future JDK features 2 items
On Oct 27, 2004, at 4:15 PM, Bernhard Fastenrath wrote: method pointers? closures? Is anybody going to suggest self-modifying java assembler code as a language feature? I don't really see how you got from method pointers and closures to self-modifying code (I see that as a bit of fear mongering). Is the goal to break Java and render it useless? In my opinion we can live without closures. You didn't have to attach for a bit longer. I actually love closures, and think it would be a great addition to Java. I spend a lot of time tracking down poorly written try/finally blocks in people's code where they don't properly close DB connections, IO streams, Jar files, and even delete their temp files. A good closure library would virtually eliminate this type of programming errors. Now I still doubt Sun's ability to pull of this feature after seeing the junk in 1.5, but if I got to choose only one major language feature to add it would be closures. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features - performance and stability
+10 -dain On Oct 28, 2004, at 1:24 AM, Danny Angus wrote: This is a bit of a rant, I know but... One thing I would like to see Sun do, from the point of view of my previous role at work, would be to devote more effort to improving the stability and performance of the Hotspot VM on all platforms. From what I can see are a number of defects in the Hotspot VM that seriously affect the capapacity of many server products to achieve high uptimes and high throughputs. Is this experience borne out by anyone else here? Could we see some clarification of the garbage collection and optimisation mechanisms? It seems to me that there are a very large number of poorly documented options for garbage collection and optimisations which are neither specification features nor implementation features, but are in wide use by many people who are struggling to maintain high levels of service in the real world in the face of defects and failure of the JVM to behave as documented. One example is the permanent generation size, Sun tell us that allocations in the permanent generation will continue up to the maximum size of the permanent space, at which point further allocations will be from the tenured heap space. Seems sensible so far. However it appears that requests for permanent allocation trigger a full garbage collection when they cannot be satisfied in the permanent generation, this leads to the JVM thrashing and effectively defeats the notion that tenured space could be used as an overflow. The fact that this was not documented is almost as serious because it removes some of the imperative which might otherwise encourage us to profile not only hepa usage but also permanent generation requirements. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. *** *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deciding on Java futures?
Noel, How can we find out whats already planned by Sun. For instance, I'm sure us Commons Math folks would all like to see the Nist/Java Grande rectangular matrices issue finalized and implemented. http://jcp.org/en/jsr/detail?id=083 But its difficult to see if this is stalled or dead at this point. Seems the issue is not that Sun needs more ideas, seems they need better execution on the those that already do exist in the JCP. Theres a severe bottleneck here where if there isn't a lead at Sun to channel the JCP into the standard, then it just sits there, festering and dying. My fear is that the same would happen to any of Jakarta's efforts to do the same. Ultimately, I wonder why Sun is going around their own designed community process to interact with Apache concerning these sorts of questions? Who's spearheading this from Sun's side? Is this evidence that JCP is a failing process? -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What does implementation vis-a-vis, for example, JSF mean?
When someone talks, e.g., about an implementation of JSF (JavaServer Faces (JSR-127)), does this mean an implementation of the specs in the JSR? So, are the binaries at Sun an implementation in this sense? Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What does implementation vis-a-vis, for example, JSF mean?
Hi, When someone talks, e.g., about an implementation of JSF (JavaServer Faces (JSR-127)), does this mean an implementation of the specs in the JSR? So, are the binaries at Sun an implementation in this sense? yes, the RI is developed by SUN. In Apache there is also one. MyFaces moved from SF.net to Apache Incubator. see: http://cvs.apache.org/viewcvs.cgi/incubator-myfaces/ and: http://incubator.apache.org/projects/myfaces.html HTH, Matthias Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features - performance and stability
On Fri, 29 Oct 2004 08:11:03 -0700, Dain Sundstrom [EMAIL PROTECTED] wrote: +10 I make that 10 trillion. Did I hit a nerve there Dain? ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exception handling Was: Future JDK features 2 items
On Fri, 29 Oct 2004, Dain Sundstrom wrote:
I actually love closures, and think it would be a great addition to Java. I
spend a lot of time tracking down poorly written try/finally blocks in
people's code where they don't properly close DB connections, IO streams, Jar
files, and even delete their temp files. A good closure library would
virtually eliminate this type of programming errors.
1/
How about the Perl6 finally system where you can attach a try/catch to
variables?
In Perl 6 it's:
my $p = P.new; POST { $p and $p.Done; }
or
my $p is post { .Done } = P.new;
So in Java it could be something like:
Connection conn = ds.getConnection(); finally(conn) { conn.close(); };
Connection conn = ds.getConnection() @ { conn.close(); };
Connection conn = ds.getConnection(); conn @ finally { conn.close(); };
Biggest problem is that I can't see a way to write that nicely.
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
On Oct 29, 2004, at 8:43 AM, Danny Angus wrote: On Fri, 29 Oct 2004 08:11:03 -0700, Dain Sundstrom [EMAIL PROTECTED] wrote: +10 I make that 10 trillion. Did I hit a nerve there Dain? ! Yes! One thing that has been bugging me for years it the URLClassLoader on windows, locks the jars it loads, and the only way to release the lock is to reboot the vm. It would be nice to have some way to release the lock. Also we have been running into problems with NIO since it came out. It is incredibly unstable and you endup tweaking code for each platform. Oh and the new GC bugs in 1.5 are totally annoying. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
On Fri, 29 Oct 2004 13:35:04 -0400 (EDT), Henri Yandell
[EMAIL PROTECTED] wrote:
On Fri, 29 Oct 2004, Dain Sundstrom wrote:
I actually love closures, and think it would be a great addition to Java. I
spend a lot of time tracking down poorly written try/finally blocks in
people's code where they don't properly close DB connections, IO streams, Jar
files, and even delete their temp files. A good closure library would
virtually eliminate this type of programming errors.
1/
How about the Perl6 finally system where you can attach a try/catch to
variables?
In Perl 6 it's:
my $p = P.new; POST { $p and $p.Done; }
or
my $p is post { .Done } = P.new;
So in Java it could be something like:
Connection conn = ds.getConnection(); finally(conn) { conn.close(); };
Connection conn = ds.getConnection() @ { conn.close(); };
Connection conn = ds.getConnection(); conn @ finally { conn.close(); };
Biggest problem is that I can't see a way to write that nicely.
2/
How about just being able to do multiple Exceptions in one block?
try {
} catch(JMSException, RemoteException, SQLException e) {
}
+1 That could save a lot of tedious repetition
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deciding on Java futures?
How can we find out whats already planned by Sun. I asked that exact question, and was told that they don't want to bias our input by telling us what is already on the plan. FWIW, I know that some of the things are already on some plans there. There is a big meeting on Monday to address futures. I'm sure us Commons Math folks would all like to see the Nist/Java Grande rectangular matrices issue finalized and implemented. http://jcp.org/en/jsr/detail?id=083 I don't see anything on the JSR-083 site that says that the Expert Group has produced or finalized anything. But to the general point ... Theres a severe bottleneck here where if there isn't a lead at Sun to channel the JCP into the standard, then it just sits there, festering and dying. My fear is that the same would happen to any of Jakarta's efforts to do the same. Ultimately, I wonder why Sun is going around their own designed community process to interact with Apache concerning these sorts of questions? They aren't. This request is coming from the J2SE lead. Sun has been speaking with many partners for months to do preliminary research for planning the Mustang (J2SE 6) Umbrella JSR. They explicitly hope that the ASF will participate on that Expert Group. This is preliminary work before setting up the JSR. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Prioritizing
There has been a lot of good discussions. Now we need to prioritize the list. I have, as a strawman, started a prioritized list at the top of the page. I put Continutations at the top, since it had the most votes, and added a few others. Obviously, I'm not going to add everyone's item. Add your own, and add your name to others that you like. That will give us an idea of popularity. I'm open to other suggestions. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: Exception handling Was: Future JDK features 2 items
try {
} catch(JMSException, RemoteException, SQLException e) {
}
+1
(We used to have something like that in Smalltalk)
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
