You know, your post made me think of this construct:
using ( new MatrixVectorAlgebra() ) {
Matrix result = matrix * vector;
}
using ( new ExactMath() ) {
BigInteger i = 10 * foobar;
}
the algebra controls both how literals get translated, and the
meanings of all operators. Just throwing
On Aug 17, 2:08 am, Peter Becker peter.becker...@gmail.com wrote:
Has anyone ever wondered about the idea of replacing the JDK first?
Yes. I think the right way to go about it is to first define a
construct whereby you can create mirrors. The representation in memory
is one thing, but any calls
the googlegroups web interface tracks replies directly, and not via
the subject header. So, when someone forks a thread by replying, and
people start replying to both the original and the fork, you still
have 1 thread in the webinterface, and every other message has a
header with Title changed
Anytime you have a framework that calls upon a hook kind of deal to do
something, catching Throwable is warranted.
A servlet container should wrap the call to the doGet method in catch
Throwable.
Thread should call its Runnable.run() via catch Throwable.
The thing is that most APIs that
It seems to me that the biggest areas for growth with Enterprise
Java is either
into the space currently occupied by PHP et al, or the cloud computing space
which (though in early days right now) is arguably the next generation of that
and other market segments. In either case, what is needed is
I have been thinking about similar things, but then you get into the
question of combining multiple algebras with overlapping types. Or you
could have second-order constructs, such as creating your
MatrixVectorAlgebra on top of an algebra for the scalars. If you use
constructors as in your
Reinier Zwitserloot wrote:
On Aug 17, 2:08 am, Peter Becker peter.becker...@gmail.com wrote:
Has anyone ever wondered about the idea of replacing the JDK first?
Yes. I think the right way to go about it is to first define a
construct whereby you can create mirrors. The
The point I am trying to make is that GMail's approach seems completely
counterintuitive to me. I have used threaded news and mail clients for a
long time and all of them handle the renaming gracefully by displaying
the title of each message. Pretty much all of them used the references
in the
Peter Becker wrote:
While I agree that you can have shared state, the scenario I had was a
clean worker: some data goes in before the thread gets started, other
data comes out at the end.
System.exit is a bad idea generally since you don't really know who is
going to use your code in the
Again, laughable. There are technical reasons for and against
op.overloading for BigDecimal/BigInteger, all of which Sun has
considered in the past and none of which I am prepared to rehearse
here. There are also strategic choices to be made: if we work on BD/BI
overloading, we cannot work on
Jess Holle wrote:
Peter Becker wrote:
While I agree that you can have shared state, the scenario I had was a
clean worker: some data goes in before the thread gets started, other
data comes out at the end.
System.exit is a bad idea generally since you don't really know who is
going
You must be a blast to be around, what with all the laughing. Make
sure you stop to breath once in a while, Alex. I do feel we've come to
an understanding that the JCP, for reasons that are their own and may
well be very sensible, has no interest whatsoever in fixing java's
shortcomings in
For that we have Runtime().getRuntime().addShutdownHook() no? That's
what I used anyway with JSR-296, where Hans Muller had hardwired the
System.exit() call in the framework.
/Casper
On 17 Aug., 23:11, Peter Becker peter.becker...@gmail.com wrote:
Jess Holle wrote:
Peter Becker wrote:
The only sane way is this:
try {
.. your code here
} catch (Throwable t) {
for (int i =0; i 1000; i++)
java.awt.Toolkit.beep();
System.exit(-1);
}
Sometimes can use a Runtime.exec to delete the home directory for good
measure, but that means platform specific code.
On Aug 18,
I'm happy to see all the runtime exception advocates on here.
Definitely not the mainstream view. Smart crowd :)
I would love to see some example of how you guys write JDBC code.
JDBC code is usually the most heinous of all with all the SQLException
and resource handling crap you have to do.
You neglect to handle the checked exception declared by
prepareStatement no?
PreparedStatement stmt = null;
try{
stmt = connection.prepareStatement(sql);
final ResultSet rs = stmt.executeQuery();
try{
while (rs.next()){
// Stuff...
{
}
finally{
+ 2
Now that you've reminded me of java.awt.Toolkit.beep(); havoc will be made!
On Mon, Aug 17, 2009 at 8:47 PM, Michael Neale michael.ne...@gmail.comwrote:
The only sane way is this:
try {
.. your code here
} catch (Throwable t) {
for (int i =0; i 1000; i++)
No, i just let that go up. I really try to avoid the declare as null
then set thingy.
On Aug 18, 12:03 pm, Casper Bang casper.b...@gmail.com wrote:
You neglect to handle the checked exception declared by
prepareStatement no?
PreparedStatement stmt = null;
try{
stmt =
you do it exactly the same way I do (well I do that and surround the
whole thing with a try{}catch(SQLException e){throw new
RuntimeException(e)}.
First time I've ever seen anyone else handle resource closing this
way.
Usually I see something like (this is mostly real code):
Connection
Wether you catch the other SQLException i guess depends on the
situation. I just find this very useful, wether it's SQL or
otherwise..
Thing thing = getThing();
try {
thing.use();
} finally {
thing.close();
}
There is no need to create Thing thing = null; outside the block then
null
Or again, serialize the Exceptions and jettison them into the sun...
http://twitpic.com/ebeci
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to
there is a reason no other language ever written has checked
exceptions - checked exceptions are a bad idea.
On my first java project back in 1999 I remember adding in a checked
exception to a utility class. It has effects on hundreds of classes
and 1000s of method calls. I then decided it was
Someone should short-circuit javac, since
checked exceptions really is just a figment of its imagination.
I made this request on the Project Coin list and was very promptly
shot down. I really do wish someone would hack it into javac and have
and IDE switch to turn them off.
Dangerous issue, but IMHO that's the way it should be. Any language
construct that derails you from your primary path of thinking is more
of a derailment than assistance. Tools are more than capable of
detecting and warning of alternative paths and lets face it, you're
going to need unit tests
We've had many long threads on the checked vs unchecked debate. My
thought was that to take out checked exceptions was cheating and
simply avoiding an aspect of strong typing that was inconvenient. But
now I'm not so sure.
--~--~-~--~~~---~--~~
You received this
25 matches
Mail list logo
