Umm... No. Currently the security manager (at least in the Sun JVM, dunno about other implementations) is unique per JVM. While it is possible to create a Security manager that implements per-thread permissions, I haven't seen one yet.
Note that a true chroot jal is not possible with vanilla java, as there currently is no way to modify filenames from within the usual Java security apparatus.
Templates benefit a lot from the inlining that most compilers do, as template functions are ususally inlined in their invocation. for example, if you use a sort with a function as a template parameter, that function (if visible) will become inlined in the sorting function thus eliminating call overhead. These sorts of optimizations are not available in plain C, unless you write them yourself...
In any case, the object code is on the same architecture, so there is only so fast it can get....
Java templates are a joke, and it's not even funny. The only thing that Java Generics buy you is some more compile-time type safety checks, in all other respects they are syntactic sugar. The actual JIT compiler cannot take advantage of the templating information because that information has been stripped away and no longer exists in the classfile in an useable form. Effective performance difference is about minus zero.
C++ templates on the other hand can be super-opimized because the compiler knows the exact types of the participants and can inline aggresively.
Depends on what you mean by well-written. If you mean hand-unrolled loops, writing the same algorithm from scratch for each data type, reimplementing the datatypes for each use; then yes, you could say that C is faster than C++.
First is the user's perception: first impressions count, and the first impression a user gets is that the UI is dog-slow, because most code gets executed for the first time and the JVM JIT's it. After using the same programm for an hour, the UI will have become responsive (actually after the first minute or so of usage) but the user will still believe that it is slow.
Secondly, the Java JVM is very good at optimizing hot spots. The hot spots however do not present themselves in a GUI environment because typically the GUI code is composed of many little classes, all different, without specific hotspots that the JIT compiler can focus on.
There you go again, equating C with C++. If you read my post again, I am saying that C and Java will perform about the same. On any large-scale problem, C++ will outperform both, that is sure - but not for the reasons you mention. One word: templates. (And some people think the C++ templates are bad imitations of the real thing).
And for your information, most GUI front-ends appear slower in Java due to the JIT process....
Please do not be such an elitist. It doesn't suit you.
I may have not been very clear on my previous post. Java resolves the problem of DLL hell by bundling each dependent JAR (the library) with the application, which will provide stability (the version of the library used by the application won't change) at the cost of bloat (JARs are not shared across JVMs, sometimes a single JVM loads at the same time two versions of the same JAR, the same JAR is duplicated on disk in each application that requires it).
Version checking is never needed in applications, as the environment of the application is controlled by the developer(s). Version checking is needed in libraries, but that is seldom needed.
Minor correction: Usually, Java applications require only the JVM. Usually they come bundled with all their dependencies tailored to the specified programm. That is one part of the reason why they are considered bloated - a simple Java app may easily reach a 5-6 MB downloadable size. However this also minimizes dependency hell fore the user.
On the other hand, I have personally been bitten by hidden interface and behaviour changes in public API from ove version of a library to the other (not the JVM or core libraries). That is a problem, and sometimes a serious one, but it is due to teh authors of the libraries, and not the JVM itself (which is very stable and backwards-compatible).
Bzzzt - sorry, good try. Your comment would be valid if you s/C/C++/g, but I find that Java and C programs written by the same average programmer will tend to have the same performance.
Average time for transmission of an SMS: 1 sec (approx, computer-controlled). Maximum payload of an SMS: 160 characters (not bytes) Seconds in a month: 2592000 (avg) Maximum data transfer in a month: 414720000 characters, ~ 395 MBytes / month.
Too slow, and even then you will only use 0.2% of your free messages....
That's stupid. You will need at least a week to create a useable framework that handles the essentials. Nevermind that you will not perceive the length of it if you are just-in-time coding parts of your application.
Tell me, would you take a week to evaluate existing frameworks?
The main advantage of EJB as I see it is declarative security on a per method basis...
Yes, and when your security needs are more complex than the simplistic EJB model, you have to either use no declarative security (and write your own) or to apply ugly hacks around the deficiencies...
No, but we can certainly outjog them. The human and the wolf have an extra gait type (jogging), that will, in time, overtake any other walking or running animal. Of course, the fact that we are endurance joggers (when fit) helps too.
Re:Barring bad Bruce Springsteen jokes
on
Humans Born to Run
·
· Score: 2, Informative
I've read about an anthropologist who demonstrated that a non-couch-potato human could easily run down an antelope and kill her. The trick was that the human jogs after the antelope, which darts away a short distance and then stops. The human keeps jogging after the antelope, which darts away, then stops again. This goes on for several minutes, after which the antelope is so overheated it can barely stand on its legs, much less run away. Voila, dinner is ready.
Re:Getters/setters bad?
on
Holub on Patterns
·
· Score: 2, Insightful
Funny, I allways thought that GUI widgets were THE example of OO-ness....
Oh, it is feasible. The major problems are that the memetic impedance mismatch between a p2p network and the traditional chain of command, and the cost that will be quoted by any R/D shop...
Slashdot Mirror
In my last project I was forced to use MySQL due to hosting issues. I still believe that MySQL is the Access of the OSS dtabases (in a non-GUI way).
Let me guess: you are older then your sister by at least a year.
TCP is too low-level for security considerations.
SMTP was designed at a time when every connected computer had a sysadmin that was legally responsible for it.
POP has POP over SSL; while there is the option to use STARTTLS, I haven't used a POP server yet that used this.
HTTP... What't the problem with HTTP?
Umm... No. Currently the security manager (at least in the Sun JVM, dunno about other implementations) is unique per JVM. While it is possible to create a Security manager that implements per-thread permissions, I haven't seen one yet.
Note that a true chroot jal is not possible with vanilla java, as there currently is no way to modify filenames from within the usual Java security apparatus.
Templates benefit a lot from the inlining that most compilers do, as template functions are ususally inlined in their invocation. for example, if you use a sort with a function as a template parameter, that function (if visible) will become inlined in the sorting function thus eliminating call overhead. These sorts of optimizations are not available in plain C, unless you write them yourself...
....
In any case, the object code is on the same architecture, so there is only so fast it can get
Remember GIGO: no data, no predictions. I'd say that the quiality of the current data isn't good enough to predict where it will be in 25 years.
Java templates are a joke, and it's not even funny. The only thing that Java Generics buy you is some more compile-time type safety checks, in all other respects they are syntactic sugar. The actual JIT compiler cannot take advantage of the templating information because that information has been stripped away and no longer exists in the classfile in an useable form. Effective performance difference is about minus zero.
C++ templates on the other hand can be super-opimized because the compiler knows the exact types of the participants and can inline aggresively.
Hell, and I don't even like C++...
Depends on what you mean by well-written. If you mean hand-unrolled loops, writing the same algorithm from scratch for each data type, reimplementing the datatypes for each use; then yes, you could say that C is faster than C++.
But then again, C++ does these things for you....
Most Java GUIs are slow because of two factors:
First is the user's perception: first impressions count, and the first impression a user gets is that the UI is dog-slow, because most code gets executed for the first time and the JVM JIT's it. After using the same programm for an hour, the UI will have become responsive (actually after the first minute or so of usage) but the user will still believe that it is slow.
Secondly, the Java JVM is very good at optimizing hot spots. The hot spots however do not present themselves in a GUI environment because typically the GUI code is composed of many little classes, all different, without specific hotspots that the JIT compiler can focus on.
There you go again, equating C with C++. If you read my post again, I am saying that C and Java will perform about the same. On any large-scale problem, C++ will outperform both, that is sure - but not for the reasons you mention. One word: templates. (And some people think the C++ templates are bad imitations of the real thing).
And for your information, most GUI front-ends appear slower in Java due to the JIT process....
Please do not be such an elitist. It doesn't suit you.
I may have not been very clear on my previous post. Java resolves the problem of DLL hell by bundling each dependent JAR (the library) with the application, which will provide stability (the version of the library used by the application won't change) at the cost of bloat (JARs are not shared across JVMs, sometimes a single JVM loads at the same time two versions of the same JAR, the same JAR is duplicated on disk in each application that requires it).
Version checking is never needed in applications, as the environment of the application is controlled by the developer(s). Version checking is needed in libraries, but that is seldom needed.
Minor correction: Usually, Java applications require only the JVM. Usually they come bundled with all their dependencies tailored to the specified programm. That is one part of the reason why they are considered bloated - a simple Java app may easily reach a 5-6 MB downloadable size. However this also minimizes dependency hell fore the user.
On the other hand, I have personally been bitten by hidden interface and behaviour changes in public API from ove version of a library to the other (not the JVM or core libraries). That is a problem, and sometimes a serious one, but it is due to teh authors of the libraries, and not the JVM itself (which is very stable and backwards-compatible).
Oh please.... it's an ugly hack bolted onto the database, and the stitches are showing. MySQL is the Access of Linux.
Bzzzt - sorry, good try. Your comment would be valid if you s/C/C++/g, but I find that Java and C programs written by the same average programmer will tend to have the same performance.
Interesting. Do you have any links, references or citations ?
No. It's called understanding.
Hmmm... let's do some analysis here...
Average time for transmission of an SMS: 1 sec (approx, computer-controlled).
Maximum payload of an SMS: 160 characters (not bytes)
Seconds in a month: 2592000 (avg)
Maximum data transfer in a month: 414720000 characters, ~ 395 MBytes / month.
Too slow, and even then you will only use 0.2% of your free messages....
Bah. PrintScreen + OCR. Granted, it's more work, but then if you have hostile users you must keep them from pen and paper....
That's stupid. You will need at least a week to create a useable framework that handles the essentials. Nevermind that you will not perceive the length of it if you are just-in-time coding parts of your application.
Tell me, would you take a week to evaluate existing frameworks?
The main advantage of EJB as I see it is declarative security on a per method basis ...
Yes, and when your security needs are more complex than the simplistic EJB model, you have to either use no declarative security (and write your own) or to apply ugly hacks around the deficiencies...
we couldn't outrun quadrupeds
No, but we can certainly outjog them. The human and the wolf have an extra gait type (jogging), that will, in time, overtake any other walking or running animal. Of course, the fact that we are endurance joggers (when fit) helps too.
I've read about an anthropologist who demonstrated that a non-couch-potato human could easily run down an antelope and kill her. The trick was that the human jogs after the antelope, which darts away a short distance and then stops. The human keeps jogging after the antelope, which darts away, then stops again. This goes on for several minutes, after which the antelope is so overheated it can barely stand on its legs, much less run away. Voila, dinner is ready.
Funny, I allways thought that GUI widgets were THE example of OO-ness....
Oh, it is feasible. The major problems are that the memetic impedance mismatch between a p2p network and the traditional chain of command, and the cost that will be quoted by any R/D shop...
[Disclaimer: I am not an american]
Dude, chill out. To compare Gulf War II to World War II is... how should I put it... showing a lack of understanding of the scales involved...