Java runtime intranet installation? [found it, sort of]
-
Marc Clifton wrote:
I can't figure out how to get there from the home page unless Java is not actually already installed.
It's the first Google search result for "jre download" :rolleyes: I always keep a copy of the offline installer so I don't have to keep re-downloading the damn thing so I wasn't aware there was any other kind.
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^]. Awasu 2.3 [^]: A free RSS/Atom feed reader with support for Code Project. 50% discount on the paid editions for CP members!
Taka Muraoka wrote:
It's the first Google search result for "jre download"
Sigh. I guess I haven't had it hammered into me: the vendor's website is useless, use google to find what you want on the vendor's website.
Taka Muraoka wrote:
I always keep a copy of the offline installer so I don't have to keep re-downloading
That's what I was trying to do too. Marc
-
Rohde wrote:
and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned.
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex. That is probably because I "read about it first, studied it first" before I started writing anything. Someone here on CP once posted a reply to the question "what is the difference between a programmer and a software engineer". He said something like: "At the start of a project the first thing a programmer does is write code. The first thing an engineer does is think."
Rohde wrote:
Many people are really underestimating the difficulties of multi threaded programming
any and all aspects of software development. They are Script Kiddies, also known as VBers.
led mike wrote:
The first thing an engineer does is think
If only we had more of that!! :doh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Rohde wrote:
and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned.
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex. That is probably because I "read about it first, studied it first" before I started writing anything. Someone here on CP once posted a reply to the question "what is the difference between a programmer and a software engineer". He said something like: "At the start of a project the first thing a programmer does is write code. The first thing an engineer does is think."
Rohde wrote:
Many people are really underestimating the difficulties of multi threaded programming
any and all aspects of software development. They are Script Kiddies, also known as VBers.
led mike wrote:
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex.
thinking on this some more, I have a slight problem with this, but only slight, I think it is a matter of semantics and point-of-view. I don't look at threading as complex, though massively parallel can be at times, rather threading requires thought. You can get away with a lot of bad practices in single threads because it only executes one mistake at a time and all you loose is time. But when you parallelize your code, mistakes build upon mistakes. It is still easy to thread, but you can no longer program without thought. However, I still hear demands for compilers to parallelize people's code at GDC, and Intel reminds everyone that OpenMP has been there for nearly a decade now, but there is no magic bullet. You can always mutex() a mistake to lock it out from being executed in parallel and crashing your program, which again shows the differences in programming methodology. If you build it correctly, you minimize mutexes and atomic operations, but that requires thought and planning. Or you just start writing code, ignore thinking, and anywhere your program crashes in a thread you atomic() wrap it via C++0x or mutex() it, or something similar in your platform. Rather than fix it, you simply try to prevent it from crashing, because if it compiles, it is obviously "right" and bug free.... :(( If only we taught thinking to programmers now. :sigh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
led mike wrote:
The free lunch is OVER script kiddies days are numbere
I agree. Multi-threaded development is the next "hurdle" for us, and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned. Many people are really underestimating the difficulties of multi threaded programming - this was also evident in the Java 5 release where the thread model was totally revamped. And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
Java and C# has shown that it is way more complex than first envisioned.
Seconded. Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside. Large applications built on those peoples training is a scary sight to behold!
Rohde wrote:
this was also evident in the Java 5 release where the thread model was totally revamped.
Since moving to .Net in a serious way, probably the biggest thing I miss from Java land is the concurrency library. It was so much easier to think in terms of higher level constructs than to think in terms of semaphores and mutexes. I really miss it! I haven't noticed a few similar structures appearing, but I still have a soft spot in my heart of Java. - Phil
-
So, is this[^] the only way to obtain a Java runtime installation package, that doesn't require Internet connectivity? :sigh: Why, oh why, is this so difficult? [edit] I found this[^] link (as Rohde also pointed out) but I can't figure out how to get there from the home page unless Java is not actually already installed. I'm trying really hard here not to criticize the general "we hate Microsoft" community, but this is so friggin' typical of these sites. [/edit] Marc -- modified at 11:17 Monday 2nd July, 2007
-
led mike wrote:
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex.
thinking on this some more, I have a slight problem with this, but only slight, I think it is a matter of semantics and point-of-view. I don't look at threading as complex, though massively parallel can be at times, rather threading requires thought. You can get away with a lot of bad practices in single threads because it only executes one mistake at a time and all you loose is time. But when you parallelize your code, mistakes build upon mistakes. It is still easy to thread, but you can no longer program without thought. However, I still hear demands for compilers to parallelize people's code at GDC, and Intel reminds everyone that OpenMP has been there for nearly a decade now, but there is no magic bullet. You can always mutex() a mistake to lock it out from being executed in parallel and crashing your program, which again shows the differences in programming methodology. If you build it correctly, you minimize mutexes and atomic operations, but that requires thought and planning. Or you just start writing code, ignore thinking, and anywhere your program crashes in a thread you atomic() wrap it via C++0x or mutex() it, or something similar in your platform. Rather than fix it, you simply try to prevent it from crashing, because if it compiles, it is obviously "right" and bug free.... :(( If only we taught thinking to programmers now. :sigh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I reckon you hit the nail right on the head as to where the real problem is. The requirement to thoroughly think through any problem requiring a multi threaded solution already places it orders of magnitude in difficult above what the 'average' programmer does. I'm not sure however that forcing everyone to think through at that fine grain level is necessarily the right way to go. Ideally, it would be the perfect solution, but more cost effective ways will emerge. Working with higher level constructs instead of the very error prone mutexes and semaphores, wait/notifies , I think will be part of the so called "magic bullet". If we can build our software with pieces that we know agree with concurrency, then we have a far better chance of building it correctly. - Phil
-
I reckon you hit the nail right on the head as to where the real problem is. The requirement to thoroughly think through any problem requiring a multi threaded solution already places it orders of magnitude in difficult above what the 'average' programmer does. I'm not sure however that forcing everyone to think through at that fine grain level is necessarily the right way to go. Ideally, it would be the perfect solution, but more cost effective ways will emerge. Working with higher level constructs instead of the very error prone mutexes and semaphores, wait/notifies , I think will be part of the so called "magic bullet". If we can build our software with pieces that we know agree with concurrency, then we have a far better chance of building it correctly. - Phil
Phil Martin... wrote:
Working with higher level constructs
except that the higher level constructs simply reduce everything to mutexed operations or fully open operations not allowing you the choice. You still end up with lock-stepped threads removing all performance benefit of your threading, except now you have no way to fix it. You can go higher and higher, but the net result is still the same, without thought, you have nothing. You do not have to have a fine grain analysis of mutexes and semaphores, you should know where to use them, and use them only there. You learn, through thought, what needs protection, what does not. Do you need a read-many, write once lock? no problem, use it. Do you really need a mutual exlusion lock, fine, then use it. The problem is not the low level construct, but the fact that programs are written without thought and then massive numbers of mutex and semaphores are added trial and error fashion until the code works. If you want higher-level, use a threaded class with all the controls built in, then reuse it. But you still have the low-grain control if you need it. Thought allows you to know when to use it, when not to.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Phil Martin... wrote:
Working with higher level constructs
except that the higher level constructs simply reduce everything to mutexed operations or fully open operations not allowing you the choice. You still end up with lock-stepped threads removing all performance benefit of your threading, except now you have no way to fix it. You can go higher and higher, but the net result is still the same, without thought, you have nothing. You do not have to have a fine grain analysis of mutexes and semaphores, you should know where to use them, and use them only there. You learn, through thought, what needs protection, what does not. Do you need a read-many, write once lock? no problem, use it. Do you really need a mutual exlusion lock, fine, then use it. The problem is not the low level construct, but the fact that programs are written without thought and then massive numbers of mutex and semaphores are added trial and error fashion until the code works. If you want higher-level, use a threaded class with all the controls built in, then reuse it. But you still have the low-grain control if you need it. Thought allows you to know when to use it, when not to.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I agree with the thought process side of things, but not with the cost effectiveness of those low level tools to every situation. For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect. The problem with using them only where you need to, is that in complex systems it is very hard to judge correctly when you do and do not. And that is what I am getting at - if I can use some tools to that vastly reduce the risk of making mistakes, at the expense of some performance, then I'd be happy with that trade off. I'd much prefer a piece of software that runs at 80% efficiency, rather than one at 100% efficiency but 12 months late! But then again, maybe I just suck at concurrent programming. My ego tells me otherwise, but I just gotta shout that guy down some days :) - Phil
-
I agree with the thought process side of things, but not with the cost effectiveness of those low level tools to every situation. For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect. The problem with using them only where you need to, is that in complex systems it is very hard to judge correctly when you do and do not. And that is what I am getting at - if I can use some tools to that vastly reduce the risk of making mistakes, at the expense of some performance, then I'd be happy with that trade off. I'd much prefer a piece of software that runs at 80% efficiency, rather than one at 100% efficiency but 12 months late! But then again, maybe I just suck at concurrent programming. My ego tells me otherwise, but I just gotta shout that guy down some days :) - Phil
Phil Martin... wrote:
For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect.
My time is better suited elsewhere too, and is done so. I don't spend ages manipulating locks and low level constructs. People make it sound like it is programming assembly, it is not. But it is parallel thought. Everything can happen simultaneously, so thought goes in: Can A occur when B is running? yes. Can B occur while A is running? yes. Will C work with A and B? yes. and so on and so forth. The idea that all operations are asynchronous and anything can happen at any time requires some thought, but we are not talking about writing war&peace, we're not even talking about nobel prize material here. It is simply a change in thought. You do what is necessary to protect what is necessary, no more, no less. No one is asking for 100% efficiency and perfection, no one is asking you to rewrite all your code in assembly. Is it really that hard to think: readlock() code.... unlock() and writelock() code unlock() is that so mindboggling as to defy description and place unparalleled burden on the programmers? You said "thinking" is beyond what most programmers do. That is the most frightening think you have said. The idea that you can program without thought, without analysis, without planning, without a goal, without any form of functional guideline.... just pour out code and hope the compiler is smart/dumb enough to prevent you from making mistakes? It truly is a sad, sad day if that is the demands of programmers to allow themselves to do that.... it is no wonder programmers can't get over the concurrent hurdle, if thought is to prevented, if planning removed.... :((
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Phil Martin... wrote:
For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect.
My time is better suited elsewhere too, and is done so. I don't spend ages manipulating locks and low level constructs. People make it sound like it is programming assembly, it is not. But it is parallel thought. Everything can happen simultaneously, so thought goes in: Can A occur when B is running? yes. Can B occur while A is running? yes. Will C work with A and B? yes. and so on and so forth. The idea that all operations are asynchronous and anything can happen at any time requires some thought, but we are not talking about writing war&peace, we're not even talking about nobel prize material here. It is simply a change in thought. You do what is necessary to protect what is necessary, no more, no less. No one is asking for 100% efficiency and perfection, no one is asking you to rewrite all your code in assembly. Is it really that hard to think: readlock() code.... unlock() and writelock() code unlock() is that so mindboggling as to defy description and place unparalleled burden on the programmers? You said "thinking" is beyond what most programmers do. That is the most frightening think you have said. The idea that you can program without thought, without analysis, without planning, without a goal, without any form of functional guideline.... just pour out code and hope the compiler is smart/dumb enough to prevent you from making mistakes? It truly is a sad, sad day if that is the demands of programmers to allow themselves to do that.... it is no wonder programmers can't get over the concurrent hurdle, if thought is to prevented, if planning removed.... :((
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
Is it really that hard to think: readlock() code.... unlock() and writelock() code unlock() is that so mindboggling as to defy description and place unparalleled burden on the programmers?
Actually, yes, I think that is too hard. Way too hard. I'm sure we can both come up with scenarios where even that trivial scenario will fail in a multi processor environment. In complex systems even seemingly trivial scenarios become too complex to analyze correctly.
El Corazon wrote:
You said "thinking" is beyond what most programmers do. That is the most frightening think you have said. The idea that you can program without thought, without analysis, without planning, without a goal, without any form of functional guideline....
That would indeed be very very bad indeed. But what I actually said was
Phil Martin... wrote:
to thoroughly think through any problem requiring a multi threaded solution already places it orders of magnitude in difficult above what the 'average' programmer does
I am just saying that to corectly solve a multithreaded problem requires many many times more effort than a single threaded one.
El Corazon wrote:
just pour out code and hope the compiler is smart/dumb enough to prevent you from making mistakes?
No way. Wasn't suggeting it and never would. I want as much of my code to be formally correct before it even touches a compiler. Hence my advocacy for better, easier, and less error prone concurrency constructs.
El Corazon wrote:
It is simply a change in thought.
And I am in total agreement - the main ingredient required is a change in thought processes to tackle the future in concurrency. I just happen to think what we should be thinking about is different to what you think we should be thinking about :) - Phil
-
Phil Martin... wrote:
Working with higher level constructs
except that the higher level constructs simply reduce everything to mutexed operations or fully open operations not allowing you the choice. You still end up with lock-stepped threads removing all performance benefit of your threading, except now you have no way to fix it. You can go higher and higher, but the net result is still the same, without thought, you have nothing. You do not have to have a fine grain analysis of mutexes and semaphores, you should know where to use them, and use them only there. You learn, through thought, what needs protection, what does not. Do you need a read-many, write once lock? no problem, use it. Do you really need a mutual exlusion lock, fine, then use it. The problem is not the low level construct, but the fact that programs are written without thought and then massive numbers of mutex and semaphores are added trial and error fashion until the code works. If you want higher-level, use a threaded class with all the controls built in, then reuse it. But you still have the low-grain control if you need it. Thought allows you to know when to use it, when not to.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
How exactly do functional languages get compiled? AIUI the way they're built every operation is fundamentally atomic and independent and that they scale to N processor systems without requiring any code changes.
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
-
Ed.Poore wrote:
Um[^]? Check the first table.
Well, I was trying to find it visiting. www.java.com. I won't even bother with a clickety. Don't waste your time. Marc
-
Ed.Poore wrote:
Um[^]? Check the first table.
Well, I was trying to find it visiting. www.java.com. I won't even bother with a clickety. Don't waste your time. Marc
-
Ed.Poore wrote:
Um[^]? Check the first table.
Well, I was trying to find it visiting. www.java.com. I won't even bother with a clickety. Don't waste your time. Marc
Done it first visit, they must have been listening to you:
- Visit http://www.java.com[^]
- Click "Free Download"
- If pops up asking to install say no
- Under the first picture after "Not the right operating system?" click the "See all Java downloads here"
- Voila!
-
Done it first visit, they must have been listening to you:
- Visit http://www.java.com[^]
- Click "Free Download"
- If pops up asking to install say no
- Under the first picture after "Not the right operating system?" click the "See all Java downloads here"
- Voila!
Ed.Poore wrote:
If pops up asking to install say no
That step only appears if you don't have Java installed. If you do, it goes immediately to a "Verify Java" screen. So, if you don't, and you go ahead and install, thinking you'll get the option to save the installation to disk, you're screwed. :) Marc
-
Ed.Poore wrote:
If pops up asking to install say no
That step only appears if you don't have Java installed. If you do, it goes immediately to a "Verify Java" screen. So, if you don't, and you go ahead and install, thinking you'll get the option to save the installation to disk, you're screwed. :) Marc
-
Rohde wrote:
Java and C# has shown that it is way more complex than first envisioned.
Seconded. Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside. Large applications built on those peoples training is a scary sight to behold!
Rohde wrote:
this was also evident in the Java 5 release where the thread model was totally revamped.
Since moving to .Net in a serious way, probably the biggest thing I miss from Java land is the concurrency library. It was so much easier to think in terms of higher level constructs than to think in terms of semaphores and mutexes. I really miss it! I haven't noticed a few similar structures appearing, but I still have a soft spot in my heart of Java. - Phil
Phil Martin... wrote:
the biggest thing I miss from Java land is the concurrency library. It was so much easier to think in terms of higher level constructs than to think in terms of semaphores and mutexes. I really miss it!
I don't understand that. I did several years of work in Java back in 2000/2001 and I remember multi-threading seemed very similar to working with Win32 synchronization kernel objects of the same time period.
-
How exactly do functional languages get compiled? AIUI the way they're built every operation is fundamentally atomic and independent and that they scale to N processor systems without requiring any code changes.
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
dan neely wrote:
is fundamentally atomic and independent and that they scale to N processor systems without requiring any code changes.
everything is independent, but not atomic. Atomic functionality provides the realism that this code must not be executed on any core/processor/thread other than one and only one at a time. It is the core of any multi-threaded operation. All lower level constructs must be atomic to prevent co-ownership. At the higher level compilers would take
atomic
{
code();
}and at the lower level
lock()
code();
unlock()These are functionally equivalent atomic operations for a given code() call. There is no automatic parallelizing function given that some loops do not scale well, you do not want to parallelize all loops or you get more problems. There is an auto-parallel option on the Intel compilers, however it rarely gains you as much performance as a bit of thought. for instance:
#pragma omp parallel for default(none) \
private(i,j,sum) shared(m,n,a,b,c)
for (i=0; i
looks complicated, but it tells the compiler which is shared variables, which are private, this allows the routine to be parallelized across N cores with minimal code-change, all it requires is a little upfront "though" on what is parallelizable. Auto-parallelize would simply skip the for-loop recognizing that it was beyond scope of the auto-parallelize, where-as:for (i=0; i
would auto-parallelize seeing only one major variable, and mostly constants. But that might not gain you much since that is probably an initialization or clear routine and called infrequently. the routine with the guts above is the one you want to parallelize and it simply needs a bit of "help" to the compiler to do the rest of the work. In the end you know, as the programmer, what is dynamic, and what is constant, what is changing via other threads, what is local, etc. Simply giving that a bit of thought and telling the compiler what to do with it will compile to N processors. But auto-parallelize is rare, and even still rarely as good as a bit of forethought.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) -
Rohde wrote:
Java and C# has shown that it is way more complex than first envisioned.
Seconded. Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside. Large applications built on those peoples training is a scary sight to behold!
Rohde wrote:
this was also evident in the Java 5 release where the thread model was totally revamped.
Since moving to .Net in a serious way, probably the biggest thing I miss from Java land is the concurrency library. It was so much easier to think in terms of higher level constructs than to think in terms of semaphores and mutexes. I really miss it! I haven't noticed a few similar structures appearing, but I still have a soft spot in my heart of Java. - Phil
Phil Martin... wrote:
Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside.
Shucks, y'oughtn'ta cry over exaggeration and braggadocio, 's just the way some people communicate! Sure threads aren't easy, nothing worthwhile in this game is easy... the point is, it is worthwhile. I shudder though, every time i hear someone discouraged from using threads because "they're hard". So what? Usable UIs are hard, reliable command parsers are hard, robust network communication is hard, reliable serialization is hard, programming is hard. But oh, so useful. :)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
-
Phil Martin... wrote:
the biggest thing I miss from Java land is the concurrency library. It was so much easier to think in terms of higher level constructs than to think in terms of semaphores and mutexes. I really miss it!
I don't understand that. I did several years of work in Java back in 2000/2001 and I remember multi-threading seemed very similar to working with Win32 synchronization kernel objects of the same time period.
I am referring to java.util.concurrent There are a number of common threads (ha! I'm so punny!) with java.util.concurrent and some of the .net framework, but I haven't found all the replacements yet. But this is getting dangerously close to non-lounge talk. Naughty us! - Phil