Managers don't understand the details - they don't bother to learn that 5.0 is really 1.5, and they make decisions based on their high level views.
Its not really 1.5. Its Java 5.0, J2SE 5.0. Its not like 'Java 2, J2SE version 1.2, 1.3, 1.4..'.
Sun has hurt Java's name, and let its developers down, with this absurd naming move, a repeat of the shambolic schizophrenic 1.2/2.0 business years ago.
I don't hear of any mass movement away from Java because of the version number! Its not schizophrenic - its 5.0 throughout.
So now we have Java 2 Version 5????? Employers will want to know why developers haven't done any version 3 and version 4. And it will certainly confuse the crap out of them.
No, its not Java 2 version 5. Its Java 5. The split between the JDK/SDK number and the Java version number is no longer present.
but Sun needs to pull its head out of its ass before C#, PHP, and Python relegate Java to the scrap heap.
Why should they? Python hasn't relegated Perl or C to the scrap heap, neither has PHP.
These languages are being used for different purposes. For example, at the moment, C# seems mainly used as a Visual Basic replacement for client-side development under windows.
I'm sure a physicist will be along shortly to say if Titan also receives energy from tidal pumping in its orbit around Saturn - that keeps Io, Europa and Ganymede hot around Jupiter, and Triton hot around Neptune.
Unfortunately not. The situation around Jupiter is unusual in the Solar system. Much of the heating of Io, Europa and other moons comes from their interaction with each other: they are all large bodies locked into resonant orbits. The situation is different at Saturn. Also, Triton certainly isn't hot - the surface temperature is around -230 celcius, with geysers of liquid nitrogen.
There could very well be underwater vents, similar to here,
Its very unlikely. First of all, if there were any such vents they would produce heat which would be visible from infrared measurements of the surface. Secondly, the vents would not be underwater - the only thing liquid on the surface of Titan is probably ethane or methane. Thirdly, where would the heat come from? The Earth is big enough to have tectonic activity. Smaller bodies like Europa and Io are heated by tidal effects from Jupiter, but Titan is probably too far from Saturn for that effect to be significant.
but where Titan is concerned no one seems to think about contamination?
Because the surface temperature on Titan is way below freezing. When the Titan probe cools down after its batteries run out, any Earth life is going to be killed pretty quickly.
I think there are other issues as well - I guess I should read the article in more detail, but I would imagine that a single failure in the PC would bring down a whole 4-user system. Also, there are matters of user and resource management: Its all so much easier and simpler on a single server.
I don't know, but my impression is that there is an aspect of 'look - this is cool' to what they are doing, as against a true saving of cost. But even if this is the case, what they have done IS cool! I would LOVE to have 4 screens on my PC.
Good grief; its more scalable than dedicated X terminals which can only serve ONE display. ONE. (1).
I don't think it is scalable, in terms of price:
Firstly, as I said, the X-terminals need not be dedicated - you can use old, low-spec PCs, that may have some alternate use, as X-terminals. There is good freeware for Windows to do this.
Secondly, look at prices: The cost of a good monitor is around 200 (I'm using UK prices, but it will be proportionally the same). The price of keyboard and mouse is around 20. The price of the specified video cards is, on average, around 80. Total: 300.
If I choose my supplier carefully, I can get a whole desktop system for less than this, especially if I can get a discount for buying bulk.
Its not only more scalable to use X-terminals, its potentially a lot cheaper, which, after all, was the point of the exercise in the first place.
Observations that "this has been done before" are really missing an important point, that it's being done in a new way.
I think there is cynicism about this because it does not appear to be a scalable way of doing things; after all, there are only so many video cards you can plug into a PC, yet with dedicated X terminals, or even low-end PCs running X-servers, you could run a whole classroom off 1 reasonably specified Linux server. Managing that single server is probably going to be a lot simpler. With good broadband connections and ssh you could even let students access this single server from their home PCs, using an open source X-server like X/Cygwin.
Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.
After some thought, I'm rather troubled by this statement. I admit I was a bit rude in my comments, and I am sorry for it, but this is part of the nature of public forums.
What is NOT acceptable is threats, as in your statement, although its hard to see what the possible consequences could be (except for people being rude back to me!).
I've got a question for you, since you seem to like JIT so much.
Its not JIT that I like, its the HotSpot optimiser - it produces optimised code based on what is actually in need of optimising at run-time, rather than what a compiler guesses is in need of optimising at compile time.
Why the hell doesn't Java cache the compiled code between program executions?
Security. Java VMs validate classes and byte codes when they are loaded. Otherwise, someone could write garbage into the code cache, with exciting results.
The latest Java (5.0) does cache some system classes in order to significantly improve startup time.
You don't have to use JIT - if you want binaries compile your classes with GCJ. I haven't tried it, but I hear good things.
Both of them have this hard unyeilding non-OO core that shouldn't be there, and that forces you to waste time (human and programmer) creating overlaid class libraries that hide it...
I agree - I used to love developing in Smalltalk - it was elegant and fun. The problem is that true full OO has unfortunately ever been really that popular, and languages (like Smalltalk) that provide this just don't measure up: years ago, I switched to Java because it was cross-platform at the binary level, free, and fast. No Smalltalk or other true OO language I researched could compete. Java is not perfect, but I believe it succeeded because it was a sufficient compromise to attract even hardened C coders, while providing reasonable OO.
and add additional layers of method calls that can't be optimised away.
I'm not too worried about this: method calls are very lightweight, and I believe that many can be in-lined and optimised away.
Adding more power doesn't help anything when lack of power was not a problem in the first place.
True, and I take your point. I guess what I was trying to say is that Java and scripting are not exclusive options, and that if you need it th e power to combine the two is there.
Running the scripts I require to run through Java adds another step to running them that I do not require.
Its not another step - its simply an alternate step. You use a Java interpeter for the script as against one written in C or C++.
I'm talking about scripting, you know, writing text files with commands in them that you launch using a command interpreter of some kind.
But that is exactly what these Java shells are - simple command interpreters. Nothing more, nothing less.
Its actually more complex to call a script from Java than your poor examples reflect.
The link you gave was an example of using the scripting language embedded, not command line. Using embedded scripts is fiddly in any language. Although, the example you have via the link is certainly not complex:
Object result = new bsh.Interpreter().source("myscript.bsh");
its one method call, giving the script file name.
My point was that you can do this:
java Bsh.jar % x = new MyClass();
then you can call methods on existing java classes using a dynamically typed scripting language.
Since you do not know what I do, you are hardly in a position to judge.
You said, in a public forum, that it was 'complex', and you gave no examples. If you gave examples, people could comment on them and judge them. If you don't give examples, you can only expect people to comment on what you actually say, which was an unqualified statement that running scripts using a Java interpreter is complex.
Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.
I apologise, it was uncessary and rude. But this is Slashdot, and a place for 'robust' debate. However, as I said, I apologise.
why to use something you do not need? if python is enough, why use jython?
Because it gives you more power. With scripting languages on Java you have access to all Java APIs - GUIs, threading, collections, network, multimedia, etc. It also allows you to seamlessly mix-and-match bits of code in different languages: You can call your Java code from the scripting language.
Because it allows for code-reuse. If you already have code written in Python, why bother to re-write it if you have to develop in Java? If you have some neat Java libraries, you can call them up from Python, TCL, BeanShell, Smalltalk, Prolog, Ada, COBOL, Pascal, Forth, Modula, Oberon, or any other of hundreds of languages that run on the JVM.
Re:jsp is a bad idea, but Java is not
on
On PHP and Scaling
·
· Score: 1
No...you are not correct. Your point about JSPs is only this is only true under a model 1 implementation/design.
You are right - I was talking only about model 1. JSPs can be used very effectively in MVC frameworks.
What I was trying to describe was JSP use when Java code is embedded, rather than tag libraries.
If they had a "DB abstraction layer" the thing would've been even slower.
No, as such abstraction layers can cache results, store compiled queries etc.
A few more method calls between your code and the database is going to make no difference whatsoever on modern hardware.
Re:jsp is a bad idea, but Java is not
on
On PHP and Scaling
·
· Score: 2, Informative
The problems with JSP are to do with writing maintainable code, not speed. There is a principle of software development that suggests that it is a bad idea to embed software logic in presentation code, as this does not allow for easy modification. If you support this principle, JSP (and some ways of using PHP) are not a good idea. However, JSP is not slow: the JSP pages are translated into Java Servlet source code and then compiled. This can result is very fast websites.
If Java is comparable to C++ speed, then that C++ code is doing something wrong, or C++ can be a lot slower than I ever imagined.
Whatever. This is statement of opinion, not fact. Write some comparable code, and try it.
"look back at recent Slashdot articles"?
There is a core of anti-Java bias on Slashdot. I assumed that if I pointed back to a Slashdot article that demonstrated Java speed, I might make some progress in countering that bias. However, there are, of course, plenty of independent studies.
I think this is because you are basing your experience on Java GUI apps, which have really let Java down. The way Swing was implemented was a big mistake, but thank goodness that is not used that much these days. Try SWT, and see Java run fast.
but on the server side that overhead is killer.. That is Why Java is so widely used server side. That is why Java is so finely tuned in terms of multithreading and multiprocessing. Server-side developers aren't crazy - they use Java because its a damn good way to implement programs that handle those thousands of threads and requests per second.
Its FAST.
Palm and deleted the VM, because it was slow enough *there* to be annoying.
Most Java VMs on Palm only run as interpreters, not JIT compilers. That's why it is slow, unfortunately.
Linux - There is no single vendor, and the community will not produce a closed JVM.
The JVM is not closed - the source code is available. Just because it doesn't conform to some Linux distributors definition of 'open' does not mean Java is 'closed'.
Its not that the community won't produce a JVM - there are several out there: Kaffe, SableVM. Its just that they aren't compatible with the java test suites.
No, it runs in native 32-bit code instead of being emulated in an optimised JVM that makes it only five or ten times slower than native code.
*sigh* This is nonsense. Its been nonsense for years. For goodness sake, keep up to date. Java is now comparable to C++ speed. Just look back at recent Slashdot articles.
Slashdot Mirror
Managers don't understand the details - they don't bother to learn that 5.0 is really 1.5, and they make decisions based on their high level views.
Its not really 1.5. Its Java 5.0, J2SE 5.0. Its not like 'Java 2, J2SE version 1.2, 1.3, 1.4..'.
Sun has hurt Java's name, and let its developers down, with this absurd naming move, a repeat of the shambolic schizophrenic 1.2/2.0 business years ago.
I don't hear of any mass movement away from Java because of the version number! Its not schizophrenic - its 5.0 throughout.
So now we have Java 2 Version 5????? Employers will want to know why developers haven't done any version 3 and version 4. And it will certainly confuse the crap out of them.
No, its not Java 2 version 5. Its Java 5. The split between the JDK/SDK number and the Java version number is no longer present.
Hopefully they will grow a brain and drop this scheme and just stick to the one version from now on
This is what they have done. Its Java version 5.0, internal version number 5.0.
but Sun needs to pull its head out of its ass before C#, PHP, and Python relegate Java to the scrap heap.
Why should they? Python hasn't relegated Perl or C to the scrap heap, neither has PHP.
These languages are being used for different purposes. For example, at the moment, C# seems mainly used as a Visual Basic replacement for client-side development under windows.
Not even a drop of water has been found there
/ SE MYKEX5WRD_0.html
http://www.esa.int/export/SPECIALS/Mars_Express
"Water at Martian south pole."
And some theories say life started there with autocatalytic enzymes, with cell walls, DNA, and chlorophyll coming later.
Yes, but all that activity requires liquid water. Its not going to happen in pools of ethane or methane - water is pretty amazing chemically.
I'm sure a physicist will be along shortly to say if Titan also receives energy from tidal pumping in its orbit around Saturn - that keeps Io, Europa and Ganymede hot around Jupiter, and Triton hot around Neptune.
Unfortunately not. The situation around Jupiter is unusual in the Solar system. Much of the heating of Io, Europa and other moons comes from their interaction with each other: they are all large bodies locked into resonant orbits. The situation is different at Saturn. Also, Triton certainly isn't hot - the surface temperature is around -230 celcius, with geysers of liquid nitrogen.
There could very well be underwater vents, similar to here,
Its very unlikely. First of all, if there were any such vents they would produce heat which would be visible from infrared measurements of the surface. Secondly, the vents would not be underwater - the only thing liquid on the surface of Titan is probably ethane or methane. Thirdly, where would the heat come from? The Earth is big enough to have tectonic activity. Smaller bodies like Europa and Io are heated by tidal effects from Jupiter, but Titan is probably too far from Saturn for that effect to be significant.
but where Titan is concerned no one seems to think about contamination?
Because the surface temperature on Titan is way below freezing. When the Titan probe cools down after its batteries run out, any Earth life is going to be killed pretty quickly.
I think there are other issues as well - I guess I should read the article in more detail, but I would imagine that a single failure in the PC would bring down a whole 4-user system. Also, there are matters of user and resource management: Its all so much easier and simpler on a single server.
I don't know, but my impression is that there is an aspect of 'look - this is cool' to what they are doing, as against a true saving of cost. But even if this is the case, what they have done IS cool! I would LOVE to have 4 screens on my PC.
Good grief; its more scalable than dedicated X terminals which can only serve ONE display. ONE. (1).
I don't think it is scalable, in terms of price:
Firstly, as I said, the X-terminals need not be dedicated - you can use old, low-spec PCs, that may have some alternate use, as X-terminals. There is good freeware for Windows to do this.
Secondly, look at prices: The cost of a good monitor is around 200 (I'm using UK prices, but it will be proportionally the same). The price of keyboard and mouse is around 20. The price of the specified video cards is, on average, around 80. Total: 300.
If I choose my supplier carefully, I can get a whole desktop system for less than this, especially if I can get a discount for buying bulk.
Its not only more scalable to use X-terminals, its potentially a lot cheaper, which, after all, was the point of the exercise in the first place.
Observations that "this has been done before" are really missing an important point, that it's being done in a new way.
I think there is cynicism about this because it does not appear to be a scalable way of doing things; after all, there are only so many video cards you can plug into a PC, yet with dedicated X terminals, or even low-end PCs running X-servers, you could run a whole classroom off 1 reasonably specified Linux server. Managing that single server is probably going to be a lot simpler. With good broadband connections and ssh you could even let students access this single server from their home PCs, using an open source X-server like X/Cygwin.
Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.
After some thought, I'm rather troubled by this statement. I admit I was a bit rude in my comments, and I am sorry for it, but this is part of the nature of public forums.
What is NOT acceptable is threats, as in your statement, although its hard to see what the possible consequences could be (except for people being rude back to me!).
I've got a question for you, since you seem to like JIT so much.
Its not JIT that I like, its the HotSpot optimiser - it produces optimised code based on what is actually in need of optimising at run-time, rather than what a compiler guesses is in need of optimising at compile time.
Why the hell doesn't Java cache the compiled code between program executions?
Security. Java VMs validate classes and byte codes when they are loaded. Otherwise, someone could write garbage into the code cache, with exciting results.
The latest Java (5.0) does cache some system classes in order to significantly improve startup time.
You don't have to use JIT - if you want binaries compile your classes with GCJ. I haven't tried it, but I hear good things.
Both of them have this hard unyeilding non-OO core that shouldn't be there, and that forces you to waste time (human and programmer) creating overlaid class libraries that hide it...
I agree - I used to love developing in Smalltalk - it was elegant and fun. The problem is that true full OO has unfortunately ever been really that popular, and languages (like Smalltalk) that provide this just don't measure up: years ago, I switched to Java because it was cross-platform at the binary level, free, and fast. No Smalltalk or other true OO language I researched could compete. Java is not perfect, but I believe it succeeded because it was a sufficient compromise to attract even hardened C coders, while providing reasonable OO.
and add additional layers of method calls that can't be optimised away.
I'm not too worried about this: method calls are very lightweight, and I believe that many can be in-lined and optimised away.
Adding more power doesn't help anything when lack of power was not a problem in the first place.
True, and I take your point. I guess what I was trying to say is that Java and scripting are not exclusive options, and that if you need it th e power to combine the two is there.
Running the scripts I require to run through Java adds another step to running them that I do not require.
Its not another step - its simply an alternate step. You use a Java interpeter for the script as against one written in C or C++.
I'm talking about scripting, you know, writing text files with commands in them that you launch using a command interpreter of some kind.
But that is exactly what these Java shells are - simple command interpreters. Nothing more, nothing less.
Its actually more complex to call a script from Java than your poor examples reflect.
The link you gave was an example of using the scripting language embedded, not command line. Using embedded scripts is fiddly in any language.
Although, the example you have via the link is certainly not complex:
Object result = new bsh.Interpreter().source("myscript.bsh");
its one method call, giving the script file name.
My point was that you can do this:
java Bsh.jar
% x = new MyClass();
then you can call methods on existing java classes using a dynamically typed scripting language.
Since you do not know what I do, you are hardly in a position to judge.
You said, in a public forum, that it was 'complex', and you gave no examples. If you gave examples, people could comment on them and judge them. If you don't give examples, you can only expect people to comment on what you actually say, which was an unqualified statement that running scripts using a Java interpreter is complex.
Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.
I apologise, it was uncessary and rude. But this is Slashdot, and a place for 'robust' debate. However, as I said, I apologise.
why to use something you do not need? if python is enough, why use jython?
Because it gives you more power. With scripting languages on Java you have access to all Java APIs - GUIs, threading, collections, network, multimedia, etc. It also allows you to seamlessly mix-and-match bits of code in different languages: You can call your Java code from the scripting language.
Because it allows for code-reuse. If you already have code written in Python, why bother to re-write it if you have to develop in Java? If you have some neat Java libraries, you can call them up from Python, TCL, BeanShell, Smalltalk, Prolog, Ada, COBOL, Pascal, Forth, Modula, Oberon, or any other of hundreds of languages that run on the JVM.
No...you are not correct. Your point about JSPs is only this is only true under a model 1 implementation/design.
You are right - I was talking only about model 1. JSPs can be used very effectively in MVC frameworks.
What I was trying to describe was JSP use when Java code is embedded, rather than tag libraries.
If they had a "DB abstraction layer" the thing would've been even slower.
No, as such abstraction layers can cache results, store compiled queries etc.
A few more method calls between your code and the database is going to make no difference whatsoever on modern hardware.
The problems with JSP are to do with writing maintainable code, not speed. There is a principle of software development that suggests that it is a bad idea to embed software logic in presentation code, as this does not allow for easy modification. If you support this principle, JSP (and some ways of using PHP) are not a good idea. However, JSP is not slow: the JSP pages are translated into Java Servlet source code and then compiled. This can result is very fast websites.
Why? Because the problems I solve with scripts do not require the complexity of running them through Java :)
What complexity?
To run BeanShell:
java Bsh.jar
How is that complex?
To run TCL on Java, you put two files into CLASSPATH, then
java tcl.lang.Shell
Is that complex?
If it is, I think you should be careful about what problems you are trying to solve. Stick to simple ones.
If Java is comparable to C++ speed, then that C++ code is doing something wrong, or C++ can be a lot slower than I ever imagined.
Whatever. This is statement of opinion, not fact.
Write some comparable code, and try it.
"look back at recent Slashdot articles"?
There is a core of anti-Java bias on Slashdot. I assumed that if I pointed back to a Slashdot article that demonstrated Java speed, I might make some progress in countering that bias. However, there are, of course, plenty of independent studies.
but it's not fast, nor efficient, not small.
I think this is because you are basing your experience on Java GUI apps, which have really let Java down. The way Swing was implemented was a big mistake, but thank goodness that is not used that much these days. Try SWT, and see Java run fast.
but on the server side that overhead is killer..
That is Why Java is so widely used server side. That is why Java is so finely tuned in terms of multithreading and multiprocessing. Server-side developers aren't crazy - they use Java because its a damn good way to implement programs that handle those thousands of threads and requests per second.
Its FAST.
Palm and deleted the VM, because it was slow enough *there* to be annoying.
Most Java VMs on Palm only run as interpreters, not JIT compilers. That's why it is slow, unfortunately.
Linux - There is no single vendor, and the community will not produce a closed JVM.
The JVM is not closed - the source code is available. Just because it doesn't conform to some Linux distributors definition of 'open' does not mean Java is 'closed'.
Its not that the community won't produce a JVM - there are several out there: Kaffe, SableVM. Its just that they aren't compatible with the java test suites.
No, it runs in native 32-bit code instead of being emulated in an optimised JVM that makes it only five or ten times slower than native code.
*sigh* This is nonsense. Its been nonsense for years. For goodness sake, keep up to date. Java is now comparable to C++ speed. Just look back at recent Slashdot articles.