Actually it's not. Because if the app has not been tested to compile and run cleanly in a 64-bit LP64 environment then you will have no end of problems.
I spent a lot of time porting over open source apps to Solaris when it got 64-bit support. There are a lot of things that can go wrong.
Oh and antoher thing: If you just recompile your 32-bit app in an LP64 environment, it is quite likely that the app will run slower, becuase it has to shuffle a lot of data around.
Sice JDK 1.2 there is the strictfp declaration that can be applied on methods which needs the precicise IEEE floating point.
If this is indeed the grandparent posters problem, he's using strictfp on all his methods. I doubt he does, since few people even know of its existance.
However, I also do not believe the numbers he was posting. It did have that trollish odour to it. I would very much like to see his test code. There must be something wrong with it.
It's arguments like yours that caused MS to remove the checked exceptions in C#, and that is very bad.
In almost all cases, maybe 95%, there is a real reason to catch a checked exception. Not catching the exception is an error, and should be flagged as such by the compiler.
For example, in C after calling certain functions (IO functions for example) you must check the return code for errors and act on it. Too often have I seen people only checking the return code from the open() but not from the subequent read() for example. Having these methods throw a checked IOException is a very good things, because it makes you deal with the error.
Just because handing errors is freaking boring doesn't mean you don't have to.
Also, there are RuntimeExceptions which doesn't need to be caught.
There is a very simple rule of thumb that should be used when deciding wether to use a checked exception or a RuntimeException: If the potential exception can be thrown from a perfectly bug-free program, then it should be checked. For example: A perfectly correct program without a single bug can still receieve an IOException when reading from a file, because its out of the applications control. Obviously this must be a checked exception.
On the other hand, a NullPointerException is unchecked because it is possible to write the code in such a way that you are guaranteed that they are never thrown.
Now, this rule does not always work perfectly and at times like that it can be a bit painful. For example, InputStream.read() is declared to throw IOException. However, this means that you need to deal with IOException even when reading from a ByteArrayInputStream. These cases doesn't come up that often (if it does to you, you really should think about the quality of the code you are writing) and in the case when it does, it can be wrapped in a simple:
Another annoying quirk is why Integer.parseInt() is declared to throw an unchecked NumberFormatException while NumberFormat.parse() is declared to throw the checked ParseException?
Re:Can I have an infinite budget to write the code
on
Java Faster Than C++?
·
· Score: 1
Well, it is. Try the latest versions of Java (1.4.2 or 1.5) and you'll notice how much more responsive the app is. Note that JDK 1.5 uses OpenGL for Java2D rendering which makes it a hell of a lot faster.
Nice and all, but who's going to use it?
on
RF-Blocking Wallpaper
·
· Score: 2, Interesting
I mean, if you have such sensitive data that you need to install this, why not simply use copper cables, and spare yourself the hassle (and sleepless nights in case the cat tears the wallpaper).
I find this statment very strange. Even the most extreme anti-java people usually agrees that if everything else sucks, at least it has an amazing class library.
I can agree that there are some stupidities in the class libraries, but there are no standard class libraries for any language that even comes close.
Re:Can I have an infinite budget to write the code
on
Java Faster Than C++?
·
· Score: 1
SWT is really a pain in the arse to code for compared to Swing. The main reason SWT was developed was to create a higher performance low-level UI for Java.
Unfortunately, SWT is a pig these days. Like I said, it's terrible to code for and since Swing is actually faster than GTK+ now, there isn't much reason to use SWT.
Show me a developer who use both SWT and Swing who still prefers to use SWT. If they exist, they are very rare.
Oh, and of you really want to use the GTK+ widgets in Java, there's a much better project, the JavaGNOME project.
I never investigated. It's somehting about the choice of colours and icons I suppose. I have never written a line of Delphi so I can only answer for what I see.
Other languages which makes use of object-orientation do not exhibit what you suppose is the cause. In systems like scheme and lisp for example, there are no primitives at all.
Lisp certainly has primitives. They are more integrated in the system, but they are still primitives.
They are primitives just like they are in Java. If they weren't, you'd be able to have two variables ponting to the name number, and then change it using (setf). You can't do this.
I haven't noticed much (if any) savings (this is on Linux 2.6.5, don't know about windows). I currenly have 3 Java progrmas running using 511MB, 288MB, and 276MB (the first one is eclipse) according to both gtop and ksysguard.
There could be a lot of shared memory there, you really can't tell wether that happens using only the tools you mentioned.
IIRC Solaris has a command called pmap which can be used to see this. My Linux box seems to have that command too but it doesn't seem to do anything.
Startup times are pretty good with java these days too. Running a hello world (which should consist of pretty much only startup) takes 0.150 seconds on 1.4.2 and 1.116 seconds on 1.5.
This is on an Athlon XP2400+ machine running Fedora Core 2 (kernel 2.6.5).
This is obviously a lot slower than a C program (no surprise there) but it's still fast enough to give you an "instantaneous feeling" when running an application.
Have you used the latest versions? 1.4.2 or even 1.5? In fact, Swing feels faster than GTK on my current machine. I have not made any benchmarks, but it's just the feeling I get. In any case, to me that is proof enough that Swing has finally become "fast enough".
Java's memory footprint is currently too large to allow numerous java programs of a moderate complexity (and size) to be running simultaneously on the desktop. Until Sun gets VM sharing going, we will not see Java attain a strong desktop presence.
I'm still not sure what you have against IDEA. It allows you do reconfigure pretty much everything. Writing a plugin I very easy if you really want configurability. It also allows you to specify which app to start when reading javadoc documentation, although the live popup of javadocs are usually more than enough. Oh, and you don't have to use the mouse.
You still didn't adress the fundamental problem with most development tools: They work with text, not code. How do you go about when you want to rename a single method? Or you want to pull a member from a subclass to a superclass and making the callers use a reference to the superclass instead? Or even simple things like extracting methods?
Before starting to use IDEA, I didn't think anything could drag me away from XEmacs, which by your standards ought to qualify as acceptible.
It was only after trying IDEA I realised that creating a development tool that goes beyond the simple editing of text and instead let it know about the code structures themselves. It is this that makes the "rename" symbol work. In normal editors, changing the name of a method can be next to impossible, of the name is a common one so that a search and replace doesn't work.
The ironic part is that VisualAge for Java (which is the name you were looking for) was the first Java development tool to actually have this "work with the code, not the text" capability. This has been refined in both Eclipse and IDEA, but IDEA simply does it better and faster.
That's your opinion. A lot of us feel the exact opposite.
Choice is good, when there is something to choose between. In XFree case, there really is no reason to stick with it, since X.org is the same, and has better leadership.
Slashdot Mirror
I spent a lot of time porting over open source apps to Solaris when it got 64-bit support. There are a lot of things that can go wrong.
Oh and antoher thing: If you just recompile your 32-bit app in an LP64 environment, it is quite likely that the app will run slower, becuase it has to shuffle a lot of data around.
If this is indeed the grandparent posters problem, he's using strictfp on all his methods. I doubt he does, since few people even know of its existance.
However, I also do not believe the numbers he was posting. It did have that trollish odour to it. I would very much like to see his test code. There must be something wrong with it.
Here's a tutorial on the use of strictfp.
In almost all cases, maybe 95%, there is a real reason to catch a checked exception. Not catching the exception is an error, and should be flagged as such by the compiler.
For example, in C after calling certain functions (IO functions for example) you must check the return code for errors and act on it. Too often have I seen people only checking the return code from the open() but not from the subequent read() for example. Having these methods throw a checked IOException is a very good things, because it makes you deal with the error.
Just because handing errors is freaking boring doesn't mean you don't have to.
Also, there are RuntimeExceptions which doesn't need to be caught.
There is a very simple rule of thumb that should be used when deciding wether to use a checked exception or a RuntimeException: If the potential exception can be thrown from a perfectly bug-free program, then it should be checked. For example: A perfectly correct program without a single bug can still receieve an IOException when reading from a file, because its out of the applications control. Obviously this must be a checked exception.
On the other hand, a NullPointerException is unchecked because it is possible to write the code in such a way that you are guaranteed that they are never thrown.
Now, this rule does not always work perfectly and at times like that it can be a bit painful. For example, InputStream.read() is declared to throw IOException. However, this means that you need to deal with IOException even when reading from a ByteArrayInputStream. These cases doesn't come up that often (if it does to you, you really should think about the quality of the code you are writing) and in the case when it does, it can be wrapped in a simple:
Another annoying quirk is why Integer.parseInt() is declared to throw an unchecked NumberFormatException while NumberFormat.parse() is declared to throw the checked ParseException?It will, however, convert to rods per cubic furlongs
Well, it is. Try the latest versions of Java (1.4.2 or 1.5) and you'll notice how much more responsive the app is. Note that JDK 1.5 uses OpenGL for Java2D rendering which makes it a hell of a lot faster.
I mean, if you have such sensitive data that you need to install this, why not simply use copper cables, and spare yourself the hassle (and sleepless nights in case the cat tears the wallpaper).
Just because windows hides all it's magic in that blob of binary data called the registry doesn't mean it's any easier.
It might be that the grandparent post were referring to the foreach construct in 1.5, which allows you to do stuff like
I can agree that there are some stupidities in the class libraries, but there are no standard class libraries for any language that even comes close.
Unfortunately, SWT is a pig these days. Like I said, it's terrible to code for and since Swing is actually faster than GTK+ now, there isn't much reason to use SWT.
Show me a developer who use both SWT and Swing who still prefers to use SWT. If they exist, they are very rare.
Oh, and of you really want to use the GTK+ widgets in Java, there's a much better project, the JavaGNOME project.
I never investigated. It's somehting about the choice of colours and icons I suppose. I have never written a line of Delphi so I can only answer for what I see.
And not to mention Java apps, but that's a problem on anything but MacOSX.
Interesting. Before I upgrade the next Fedora box, I'm going to benchmark this before and after the upgrade.
They are primitives just like they are in Java. If they weren't, you'd be able to have two variables ponting to the name number, and then change it using (setf). You can't do this.
Are you running 2.4?
IIRC Solaris has a command called pmap which can be used to see this. My Linux box seems to have that command too but it doesn't seem to do anything.
This is on an Athlon XP2400+ machine running Fedora Core 2 (kernel 2.6.5).
This is obviously a lot slower than a C program (no surprise there) but it's still fast enough to give you an "instantaneous feeling" when running an application.
Have you used the latest versions? 1.4.2 or even 1.5? In fact, Swing feels faster than GTK on my current machine. I have not made any benchmarks, but it's just the feeling I get. In any case, to me that is proof enough that Swing has finally become "fast enough".
Learn spelling. It's "grammar".
You still didn't adress the fundamental problem with most development tools: They work with text, not code. How do you go about when you want to rename a single method? Or you want to pull a member from a subclass to a superclass and making the callers use a reference to the superclass instead? Or even simple things like extracting methods?
Are you saying that your employer don't play for your tools?
It was only after trying IDEA I realised that creating a development tool that goes beyond the simple editing of text and instead let it know about the code structures themselves. It is this that makes the "rename" symbol work. In normal editors, changing the name of a method can be next to impossible, of the name is a common one so that a search and replace doesn't work.
The ironic part is that VisualAge for Java (which is the name you were looking for) was the first Java development tool to actually have this "work with the code, not the text" capability. This has been refined in both Eclipse and IDEA, but IDEA simply does it better and faster.
Choice is good, when there is something to choose between. In XFree case, there really is no reason to stick with it, since X.org is the same, and has better leadership.
Why not just use Postgres and be done with it? Better and it's really free. :-)