Java runtime intranet installation? [found it, sort of]

Ed Poore

Never try and find stuff like that, Google is much quicker :doh:

My Blog

Ed Poore

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!

My Blog

Marc Clifton

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

Thyme In The Country
Interacx
My Blog

Ed Poore

Alternative, use Firefox, it doesn't jump the page but stops with some instructions allowing you to click the link.

My Blog

led mike

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.

El Corazon

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)

Shog9 0

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

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

Dan Neely

Most people are probably looking for vbMultiThreadedControl and won't be happy until they can drag/drop it onto their application and be done. :laugh:

-- 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

Phil Martin

I'm totally with you on that one. I encourage just about everyone I meet to use concurrency, and boy do I get some strange looks from the McDonalds staff. They'll thank me one day though :) It is very worth while, and I don't design any system now without a fundamental underpinning of concurrency. And I probably stuff it up more often than not, but hey, it's all good fun. And I never want to discourage people, I just want people to be aware it isn't the easiest thing in the world, and you should respect them threadsies. And you are right, writing most anything in a really robust way automatically makes it hard! I also have italics envy. - Phil

Shog9 0

Phil Martin... wrote:

I also have italics envy.

:laugh:

----

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

Shog9 0

See: BackgroundWorker drag'n'drop tour[^]... :doh:

----

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

Dan Neely

well that's a start, but if you drag a vbMultiThreadedControl onto your existing crufty more or less upgraded to VB6 app it will magically run 4x faster on a quad core with no code changes whatsoever required. Just leave work early, goto the local bar and buy a Bud.

-- 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

NormDroid

dan neely wrote:

Most people are probably looking for vbMultiThreadedControl and won't be happy until they can drag/drop it onto their application and be done.

Yes, the phrase 'most people' because it's fact probably 10% of VB users actually come from a development background (i.estudied at college/uni) that's why VB projects end up being a archetictural disasters.

P Think of the environment; please don't print this message unless you really need to.

stickershock

led mike wrote:

Ah.... you are a true visionary The free lunch is OVER script kiddies days are numbered

Gee, I come to this site to read about java and get some c++ programmer telling everyone the sky is falling. I'll tell you why I like c#, It lets me hire programmers who pump out a lot of code so we can test ideas we have quick and fast without the I AM A COMPUTER GOD mentality of c++ programmers. (only about 25% of the stuff I do is on windows) C# programs tend to be much more reliable and less buggy than stuff written on C++ in a much shorter time. All compiler and runtime yes? Kinda eliminates some of the need for tweaking a piece of soft so it runs on everything, if it compiled, it will be pretty stable and get the job done... As for the link to the end of the world processors wont get any faster, hmmm, do you mean to say that for once, there will be time to catch up with the hardware? Obviously when it becomes a real issue,.. Kinda sounds like keyboard envy to me ;-) ah,, what was that about Java? Ohh, yeah kinds look like a 20+ mb download and a complete reinstall with no net :-( i couldn't find anything that broke up the updates for you to download, product continuity, why give yourself a bad name with manual updates I guess.

MajorTom123

Marc, This is a guess, but it looks like the link for the entire package. I haven't installed this today, but it does look like the link for the entire package to be downloaded then run as an executable. http://java.sun.com/javase/downloads/index.jsp Hope this helps. As for the flamers: You all say "right tool for the right job" but you don't demonstrate that level of knowledge with your posts. Java - Has a GC, however it runs whenever it wants to. Not just when memory is getting full. This can be disastrous when communicating serially with a device. C++ - No GC. This can be hazardous since mistakes do happen and you might run out of memory. Java was supposed to kill C++. C# was to kill Java. I don't see any bodies anywhere. Each of the languages has its warts and short comings. Not sure why they couldn't get OO right by the time C# was implemented, but then again they were not shooting for write once, run anywhere either. You all need to step back and evaluate the landscape. Choose the language that fits the project. Your managers will gasp but that "should" be how it goes. I'm a C programmer btw, but have programmed in all (meaning wrote meaningful programs) except C#. Back to Java: The installation of the JDK (above) allows you to develop. So its not as easy to attain and setup. But the JRE is mostly seamless as a browser plugin, so anyone who writes it off as "too hard to install" must be talking about the JDK not the JRE. I hope this helps you Marc.

led mike

Phil Martin... wrote:

I am referring to java.util.concurrent

Ah, I think that was added after my Java stint. When I started there were all sorts of things missing like the sort interface. What is it, like IComparable, ISortable or something? I never understand everyone whining about lack of library encapsulation. When there was no sort interface in Java I just wrote my own. It took very little time and after it was added to the SDK it looked very similar to the one I did so porting was minimal. I think for many novice developers, they started after all these large libraries already existed. They never knew the days when you wrote your own libraries so when a library doesn't have some feature they get stuck, like a pig at an empty trough, they starve because they aren't hunters.

led mike

stickershock wrote:

Obviously when it becomes a real issue,..

Ummm it already is. Apparently you can't read or you don't understand the subject matter of the article. I'm shocked... no really... I am. :zzz:

ensoftrob

The performance issues that most people cite with Java are due to poor understanding of the internal implementations of the data structures they are using. For instance, if you use a LinkedList to store data elements, then traverse the list by retrieving items with List.get(), performance will be on the order of n^2. If, on the other hand, you traverse the list by using an Iterator, and/or you use a different type of data structure (such as an ArrayList), your performance will be linear. In addition, if you use a class that has built-in synchronization support (such as a Vector or Stack), but you do not require synchronization, you are wasting your resources and should instead use a data structure that does not have built-in synchronization support (such as a List, which is easy to use in place of both Vectors and Stacks). The JVM will compile Java bytecode down to native code once a method has been executed many times. Or, if you want your program to run faster from the start, you can launch your JVM with the -server option. A couple of years ago, my company used Java to analyze 16 million+ lines of COBOL source code on parallel machines within just a few hours. Although the CPUs were pegged at 100%, we found that the largest bottleneck was disk I/O, and we compensated for this by pooling objects, compacting our output format, and optimizing the read/write strategies used by our processing routines. The amount of labor required to perform these optimizations was far less than the amount of labor expended on parallel efforts to port parts of the logic to native code, and the Java stuff was easier to debug and maintain. Sure, someone who is married to C could say we aren't as seasoned in C and that we're wimps for not wanting to do our own memory management, and they would be right--at least on the "seasoned" part. ;) But the tradeoff is that we were able to develop the application in less time; and it has been easier to debug and maintain, if only because low-cost Java development tools are easier to use for navigating and refactoring existing code. However, we have both computed and measured the execution time of various computation-intensive tasks that we perform, and the performance is very similar between C and Java implementations. I'm sure the magnitude of the performance discrepancy between Java and native C apps is still somewhat application-dependent, but the truth is that an application won't be slow simply because it's written in Java--and even if that were the case, there are ways o

Phil Martin

Yeah, I started at around the same time. It's been really exciting watching it grow over the years. And whining - yes, I feel the same. HAve you talked to any graduates lately about how they would do text searching? or sorting? or any sort of container? I'm not sure what it is like in the rest of the world, but in this part of australia, it isn't so promising. But then again, it does allow many people to solve many problems without having to learn all the inner workings of the magic libraries. So it isn't all bad. I'm really looking forward to writing some of these structures in C#, it'll be fun! But the concurrent library, I recommend you read over the javadoc, it is really cool stuff. It has a been around for a while now (couple of years at least), but some of the highlights for me are: Executors - basically a bunch of smarter thread pools, all based off the one interface. So if you write your threading calls to all start using an executor interface, you can try out different scheduling strategies with a minimum of fuss. Callable, Future and FutureTask - Similar to async delegates that return values, but a fair bit more verbose :( But very very cool though. It made a very big deal to heaps of the stuff I was working on at the time. The simple feature of having it start some work, and block whe you call get() (if you wanted it to) simplifed things soooo much over wait/notify code. Futures also tied into executors very well, as you could use different mechanisms fo shceduling the Future onto different threads. CyclicBarrier - handy way to have all threads stop at a common road gate. CountDownLatch - my favourite. Easy way for one or more threads to block until some other threads do some work. Sure it's lazy, but soooo much simpler than wait/notify. Exchanger - It allows two threads to block at a point and then swap objects. I didn't use this one much but it would be very handy to have in the work I'm doing in c# now. I just have to come up with a way to do it reliably in c#, and I'll be laughing. CopyOnWrite containers - very handy to have in some situations. And very hard to write correctly yourself.