I was under the impression that we were discussing jbuilder here. As far as I know a native compiler is provided with that product but I'm not sure. Anyway there are plenty of native compilers. I used to run the symantec compiler when I was programming for jdk1.1. It was much faster and usually compiled my stuff in a second or so. The standard JDK from sun comes with a java implementation of the compiler (I wish they shipped jikes or something else instead). The speed loss it suffers is mainly due to the constant overhead of starting the VM.
You need two things to run a java IDE: - a pentium II 300MHZ 128+ MB or better - a fast jdk (IBM, suns jdk 1.3 beta, inprise?)
I've installed jdk 1.3 beta a few days ago on my NT PC (PII 350 mhz, 192 MB) and the result is very satisfying. The first thing I loaded was the swingset demo application. This is a good test since it contains a sample of all the swing components and forces the jdk to load just about all the classes in the swing package.
In short it was substantially faster. It loaded very fast and once loaded there was no lag when you clicked on a GUI element, unlike all the previous versions of the JDK. It loaded in about 9 seconds on my PC and responded as fast as a native app after that.
Next on my list was forte (used to be netbeans), this is a IDE comparable to what borland released today. It ran fast. It used to be a bit too slow with previous JDKs but all the lag seems to have disappeared. Switching between different workspaces is as fast as you could want it to be.
Next was togetherJ, a UML 1.3 compliant modeling tool. Very nice app and once again performance problems have mostly disappeared.
Then finally a swing application I wrote myself, again major speedup, faster loading time and very decent response.
Seems like the java is slow argument has become obsolete. Now you only can claim it is memory intensive, but hey what's the price of a 128 MB upgrade?
Needless to say that I'm not going back to 1.2.2. I managed to download jbuilder but have been unable to obtain a key so its just sitting there. I also tried to run it with jdk1.3 beta but jbuilder didn't like that. Apparently there are some hardcoded dependencies on borlands version of the JDK, so I don't think they can claim it is 100% java.
If they don't fix that, I'll probably won't use it because being able to use the latest jdk is a must for me.
In short, I can recommend the jdk 1.3 even though it is still beta. I have not encountered any crashes or anomalies and it sure is much faster than 1.2.2.
Do you do this on purpose or are you just a stupid fool. Obviously half a year wasn't enough for you to learn some very basic information about a simple language like Java. Lets go by your points one by one 1 every reference to an object is a pointer. The difference here is that everything is treated as a pointer. 2 #include is a preprocessor directive, java has no preprocessor. This means that you can't extend the language in unsafe (not compiler checked) ways and you don't have the chance to obfuscate your code. 3. You can use a simpler object that wraps around an array of Chars if you need to. The String provides flexibility but obviously you like reinventing the wheel so that is wasted on you. 4. Nope, ints, chars, booleans and floats are not objects. There exist object wrappers for them should you need them (just to prevent idiots like you from writing them yourself).
Of course you got your final statements wrong as well, the compiler is a native program. An IDE is not a compiler. The pretty widgets you click in VB are not part of the compiler.
Try www.disney.com for a change it might suit your abilities better than slashdot.
Indeed, standardization only slows things down. Java is evolving rapidly, any standard would be obsolete before it has gone through the acceptation procedure. I.e. a standard has little other than marketing value.
If you look at standardization of Java, there's three things that can be standardized: - the language - the bytecode - the API
Standardizing the language at this point would not be a good thing since interesting language extensions are being developed at the moment (classes with parameters). As long as the extended languages are backwards compatible that's ok with me.
Standardizing the bytecode would probably be not very harmful but I don't see any immediate advantages either. The bytecode and the VM have been pretty well described already and anybody can make a cleanroom implementation of it. As far as I know the specs have been very stable. It should be possible to compile old jdk 1.02 programs with the latest JDK and run the resulting bytecode on an old java VM (provided the new API doesn't clash with the old one).
Standardizing the API is rediculous. The java API is a moving target, functionality is being added continuously and the existing API is also perfected from time to time. Fixing the API is not a good thing since I want new functionality and I want those errors fixed in the existing API. In any case a standard API would be lagging behind the current version of the API making it pretty much useless.
Indeed another witch hunt. It seems the blackdown people got what they wanted in the first place: a port of the SUN JDK to linux. It would be a nice gesture of SUN if they gave the blackdown people some credit though. But on the other hand this is only a beta release and SUN is probably not giving much attention on packaging, documentation and such right now.
I can imagine that for the average user the fact that some blackdown code is hidden in the product is not particularly relevant information so that might have been a reason for SUN not to provide this information. Probably blackdown is not the only contributing party to the product. I imagine they got some help from companies like IBM and inprise as well and they are not mentioned either.
In a way the blackdown project must have been a bit of a failure in the eyes of SUN, I mean they put out their stuff to have it ported and in the end they had to jump in to get things to work.
BTW. Has anybody actually tried the new JDK? How does it compare to the blackdown release? Is the performance any good or do we have to wait for a decent JIT to be released?
I don't give a flying fuck about the filesystem when I'm an end user. Unix people often fail to see the big picture when it comes to end users, probably because this type of user never gets near their OS.
When I was a CS student I had the pleasure of working with several UNIX flavors. I also installed linux on my PC when this still was a non trivial act. At the university I worked we had those nice little networked workstations which commonly shared one computer (3 terminals, one computer, HP UX machines, Indys and later also Sparcs). They were slow. Not just a little bit but really slow. Even when we got newer hardware it still was slow. Probably those things are really nice if you can use them stand alone but networking to terminals clearly was a bad idea performance wise.
X windows is only nice if you have monolithical applications (i.e. apps you can't break up). If its monolithical that means it is probably too big to run on a small computer. If it's not, you can separate the GUI from the rest of the application. Well designed applications don't need to waste bandwidth on transmitting mouse clicks.
Now opengl over X sounds like a really bad idea. Even a modest 3d environment can contain hundreds of megabytes in textures and polygons. I have a hard time believing that you can squeeze that down a network in real time. If on the other hand you have it locally, why the heck would you want your software to run remotely? Any performance gains would be canceled by the network overhead.
An idea would be to bootstrap vmware or freemware ontop of an exokernel (I just read the HURD story). The idea of an exokernel is to put very little functionality in it and focus on multiplexing the hardware (so that it can be used by multiple applications). Using such a setup would make it possible to host multiple normal operating systems without having to use a limiting host OS.
I really like this idea of being able to run multiple operating systems at the same time since there is no one size fits all OS. Different applications come with different requirements. The ability to serve web pages is something entirely different than the ability to handle large files.
I agree. Right now each OS provide is solving the same boring problems: getting 3d to work, getting driver support for exotic hardware, making a filesystem, etc.
Having a generic OS core that is free and allows other OS to coexist would mean a great deal for smaller operating systems like BeOS. They wouldn't have to worry so much about hardware support, they wouldn't have to worry so much about coexistence with other operating system and could focus on getting things to work with the virtual hardware instead.
What I'm curious at is whether a multimedia beast like BeOS can be run efficiently virtually or that it would have to live with the limitations of the host OS (filesystem size, etc.).
X windows is a solution to a non existent problem. It is too abstract for efficient hardware communication. This abstraction is justified by being able to remotely run an application which is something useful for some people but shouldn't get in the way of people who don't use that feature (far more people).
Today there are other ways to run an application remotely (HTML, java) which in the long term will make X windows obsolete for that purpose. The ability to remotely do 3d stuff doesn't impress me at all. It smells like bad software architecture to me. I'd be surprised if it works well over slow connections (like most 2d applications).
As far as I know XFree 4.0 contains optimizations and ways to get around X directly to the hardware. Probably it is very efficient (I trust those people know what they are doing) so that is a good thing.
The fact remains that it is an obsolete piece of technology patched to fullfill modern requirements rather than an efficient, well designed piece of software. But who cares, as long as it works it's ok with me. XFree 4.0 solves a long list of longstanding problems (at least it claims it will) so that's really nice. Replacing it never was an option so keep up the good work. I hope it will solve the performance problems, make it easier to write drivers and will support 3d better, make configuration less painfull and so on.
There is a difference between mozilla and communicator. Mozilla is currently alpha (at least that's being discussed at mozillazine). It will likely hit beta some time after that (late januari?). After mozilla goes final, netscape will add its stuff and start testing it which will take another few months. I don't expect a communicator 5 release before spring 2000 and that is assuming that there will be no more major setbacks.
Mozilla is a fine project from a software engineering perspective, I'm really excited about its probabilities but from a management perspective its a classical example of how not to manage a poject. It is taking up lots of resources (netscape engineers) and it is suffering from excessive feature creap which has caused the deadlines to shift enourmously (like half a year).
I think the people at netscape will have a really hard time convincing the rest of the world to run communicator 5. From an engineering perspective it certainly is an interesting product but engineers are only a minority of the target audience.
If mozilla is going to survive it will be on its technical merits. The mozilla project is promising a lot and judging from the nightly builds, it is delivering on those promises.
If on the other hand it will fail it will be because it came to late and missed its window of opportunity, which in my opinion will be nearly closed by spring 2000. Microsoft has been in the luxurious position that it had a great GUI for their browser for nearly two years. All this time they have been able to focus on producing a better rendering engine. I have a hard time believing that they won't release a better one before communicator ships. And they just got a few extra months to perfect their stuff.
you should see a doctor to get treatment for your paranoia.
"I remove all cookies during boot up each time and I NEVER KEEP sensitive personal info on my PC."
If I were you I would unplug the computer, lock the door and be afraid for the rest of my life. Not taking part in society is excellent defense against Big Brother. But seriously, what's the big deal with cookies? Only the site that created them can access them and they might as well store it serverside if there really is something worth storing. Cookies are mostly for your convenience so with deleting them you only give yourself extra trouble.
Moving privacy sensitive data to a central place gives you more privacy because you know who leaked information when something goes wrong. In my view your privacy sensitive data should be legally protected (i.e. you can sue when somebody illegally accessess it).
"Because some of us prefer that BIG BROTHER does not know everything we do and when and at what time...."
I suppose you're not that paranoid that you don't store your money in a bank. I.e. anytime you make a payment with your creditcard (online/offline) that information is registered anyway.
"Any other behavior is just proof of evolution in action...the stupid shall be fleeced:)"
*sarcasm* Ok we an über mensch posting here.*/sarcasm* Just because you learned to operate a computer doesn't make you any smarter. In fact the smart let geeks like you do the monotonous work of operating a computer since they have better things to do.
I agree with this. The whole problem is that each web app deals with security on its own way. Many sites require a person to identify himself. This is commonly solved with a username/password combination. What would be nice is if there were a third party that would do user identification. Rather than providing each site with all your details you could authorize (through a certificate) a company to verify with that third party that you are you. This would also be a way to limit the amount of information you show to that company. The third party could of course maintain a database of user data but you could agree (with a contract if necessary) to restrict access to that database.
This would solve the privacy issue and it would allow sites to verify that you are who you say you are.
What we need for this is standards. We have standards to verify that a piece of software is from a certain company, why don't we have a standard to establish the identity of someone.
Scientology practices extortion and other bad things. The german government is very right in staying clear of anything this organization is involved with.
Actually I think the idea of MS teaming up with a scientology owned company is pretty ironic. Believe me MS' fud practices are amateurism compared to what scientology is capable of.
Some might claim that prohibiting an organization like scientology goes against free speech but does free speech include extortion practices?
I did what I described. I don't care what the survey says since the program screamed on my PC.
PalmOS already has a java VM. It works very well without being dependent on propietary Palm libraries.
The future by the way is not a Palm with 8 MB. There's a thing called progress. More likely a Palm with 128 MB and a 200MHZ+ processor is the nearby future.
I have no idea but I know the people at Symbian use rigorous coding standards for their stuff. Check out their coding regulations at their site (www.symbian.com).
The interesting thing is that with all the limitations they impose, the code mimics things that were designed into the Java language. It shows that in order to write reliable C++ code you have to be very disciplined.
Java programs generally are smaller than their C/C++ code versions. I did all three languages and I can say with a straight face that most things are much shorter in Java than they are in C.
The reason for this is that you can eliminate redundancy in your code by using OO, you don't have to do memory management and you have a great API with all sorts of default functionality. You won't cath me implementing a linked list in Java.
"Please explain to me (with a straight face) why interger and Integer exist simultaneously."
Oh that's easy. Performance versus flexibility. If you want performance in an application, you don't want to use objects to model basic types like integers. If you want flexibility, you want to model basic types as objects so that you can put them in for instance a Collection Object.
Also the Integer, Boolean, etc classes contain nice static methods for conversion to and from string etc.
From a pure OO perspective the presence of basic types is wrong but then a pure OO program would probably be to slow when handling large amounts of objects so you need them to avoid creating an object for each integer in your program.
Download JDK 1.3 Beta (performs much better than 1.2)
Download TogetherJ, a full featured UML 1.3 modeling tool written in Java.
Run TogetherJ using jdk1.3 and enjoy. Its not that much slower than its main competitor (Rational Rose) and the system requirements are not different either. Featurewise TogetherJ also does nicely. I particularly like the way diagrams are synchronized with Java code.
TogetherJ synchronizes its UML 1.3 compliant diagrams with the java code that you type/generate (depending on whether you edit a diagram or the code). Very Cool! Apparently there also is a C++ version. I thought it would be worthwile to mention it in this context. It is of course a Java program so you want a decent VM running on dito hardware (jdk 1.3 beta is very satisfying for this purpose).
Thank god you didn't learn programming in the time that Cobol was the main language because you'd be stuck with that instead.
"Would I want to write a driver in Java?"
You wouldn't. Drivers are hardware specific. What you do in Java is abstract from hardware. So what you'd do instead is use/create an API that does that for you (java3d for instance) and write a driver in C that mediates between the API and the hardware.
Its all about using the right tool for the right job.
"I would be reluctant to write OS level code (e.g., drivers) in an OO language"
If you do it well like the people that created BeOS for instance the result is very satisfying.
If you don't understand that windows 3.1 and mac os doesn't support non preemptive multitasking you run into trouble when you port a multithreaded app to that platform. If you don't know about green threads light weight processes when working on Solaris, you might run into problems.
Java made multi threaded programming a lot easier but it is still possible to shoot yourself in the foot. If you do don't blame Java but grab a book and learn how to do it properly (and comfort yourself that you wouldn't have pulled it of in another language either).
"I don't have to understand the context switching issues of various CPU's, because the OS takes care of that for me."
Yes you do, you have to understand that context swithching is an expensive operation on most platforms and that you should design your program in such a way that it limits the nr of context swithces.
Not understanding what you are doing is never a good idea. Java hides the complexity of programming parallel programs but does not protect you from writing inefficient software.
In the research group where I work a guy evaluated a few large C++ server applications for multiprocessing systems and he found that with some of those systems the performance decreased when you added more processors. The key to solving this problem was understanding context switches (which he did rather nicely).
One is the API that has indeed evolved greatly (and that's definately a good thing). Most programs can be ported to later generation JDK with little effort.
Two is the language (the language hardly changed) and is backwards compatible.
Three is the bytecode (you can compile jdk 1.0.2 programs with the latest VM and provided it doesn't clash with the API it will work on any good jdk 1.0.2 VM)
Slashdot Mirror
I was under the impression that we were discussing jbuilder here. As far as I know a native compiler is provided with that product but I'm not sure. Anyway there are plenty of native compilers. I used to run the symantec compiler when I was programming for jdk1.1. It was much faster and usually compiled my stuff in a second or so.
The standard JDK from sun comes with a java implementation of the compiler (I wish they shipped jikes or something else instead). The speed loss it suffers is mainly due to the constant overhead of starting the VM.
You need two things to run a java IDE:
- a pentium II 300MHZ 128+ MB or better
- a fast jdk (IBM, suns jdk 1.3 beta, inprise?)
I've installed jdk 1.3 beta a few days ago on my NT PC (PII 350 mhz, 192 MB) and the result is very satisfying. The first thing I loaded was the swingset demo application. This is a good test since it contains a sample of all the swing components and forces the jdk to load just about all the classes in the swing package.
In short it was substantially faster. It loaded very fast and once loaded there was no lag when you clicked on a GUI element, unlike all the previous versions of the JDK. It loaded in about 9 seconds on my PC and responded as fast as a native app after that.
Next on my list was forte (used to be netbeans), this is a IDE comparable to what borland released today. It ran fast. It used to be a bit too slow with previous JDKs but all the lag seems to have disappeared. Switching between different workspaces is as fast as you could want it to be.
Next was togetherJ, a UML 1.3 compliant modeling tool. Very nice app and once again performance problems have mostly disappeared.
Then finally a swing application I wrote myself, again major speedup, faster loading time and very decent response.
Seems like the java is slow argument has become obsolete. Now you only can claim it is memory intensive, but hey what's the price of a 128 MB upgrade?
Needless to say that I'm not going back to 1.2.2. I managed to download jbuilder but have been unable to obtain a key so its just sitting there. I also tried to run it with jdk1.3 beta but jbuilder didn't like that. Apparently there are some hardcoded dependencies on borlands version of the JDK, so I don't think they can claim it is 100% java.
If they don't fix that, I'll probably won't use it because being able to use the latest jdk is a must for me.
In short, I can recommend the jdk 1.3 even though it is still beta. I have not encountered any crashes or anomalies and it sure is much faster than 1.2.2.
This type of PCs has been available for at least two years. You can expect a good developer to be willing to invest in good tools.
Most commercial IDEs, java and non java have a memory requirement of 64 MB but in practice you need 128 MB to run them comfortably.
So no big deal, pretty modest system requirements. A two year old PC with plenty of memory (dirt cheap at the moment) is all you need.
"I'll stick with my text editor and command line - works equally well from my old 486 to my PIII."
That's your choice but an editor is not the same thing as an IDE.
Do you do this on purpose or are you just a stupid fool. Obviously half a year wasn't enough for you to learn some very basic information about a simple language like Java. Lets go by your points one by one
1 every reference to an object is a pointer. The difference here is that everything is treated as a pointer.
2 #include is a preprocessor directive, java has no preprocessor. This means that you can't extend the language in unsafe (not compiler checked) ways and you don't have the chance to obfuscate your code.
3. You can use a simpler object that wraps around an array of Chars if you need to. The String provides flexibility but obviously you like reinventing the wheel so that is wasted on you.
4. Nope, ints, chars, booleans and floats are not objects. There exist object wrappers for them should you need them (just to prevent idiots like you from writing them yourself).
Of course you got your final statements wrong as well, the compiler is a native program. An IDE is not a compiler. The pretty widgets you click in VB are not part of the compiler.
Try www.disney.com for a change it might suit your abilities better than slashdot.
Indeed, standardization only slows things down. Java is evolving rapidly, any standard would be obsolete before it has gone through the acceptation procedure. I.e. a standard has little other than marketing value.
If you look at standardization of Java, there's three things that can be standardized:
- the language
- the bytecode
- the API
Standardizing the language at this point would not be a good thing since interesting language extensions are being developed at the moment (classes with parameters). As long as the extended languages are backwards compatible that's ok with me.
Standardizing the bytecode would probably be not very harmful but I don't see any immediate advantages either. The bytecode and the VM have been pretty well described already and anybody can make a cleanroom implementation of it. As far as I know the specs have been very stable. It should be possible to compile old jdk 1.02 programs with the latest JDK and run the resulting bytecode on an old java VM (provided the new API doesn't clash with the old one).
Standardizing the API is rediculous. The java API is a moving target, functionality is being added continuously and the existing API is also perfected from time to time. Fixing the API is not a good thing since I want new functionality and I want those errors fixed in the existing API. In any case a standard API would be lagging behind the current version of the API making it pretty much useless.
Indeed another witch hunt. It seems the blackdown people got what they wanted in the first place: a port of the SUN JDK to linux. It would be a nice gesture of SUN if they gave the blackdown people some credit though. But on the other hand this is only a beta release and SUN is probably not giving much attention on packaging, documentation and such right now.
I can imagine that for the average user the fact that some blackdown code is hidden in the product is not particularly relevant information so that might have been a reason for SUN not to provide this information. Probably blackdown is not the only contributing party to the product. I imagine they got some help from companies like IBM and inprise as well and they are not mentioned either.
In a way the blackdown project must have been a bit of a failure in the eyes of SUN, I mean they put out their stuff to have it ported and in the end they had to jump in to get things to work.
BTW. Has anybody actually tried the new JDK? How does it compare to the blackdown release? Is the performance any good or do we have to wait for a decent JIT to be released?
I don't give a flying fuck about the filesystem when I'm an end user. Unix people often fail to see the big picture when it comes to end users, probably because this type of user never gets near their OS.
When I was a CS student I had the pleasure of working with several UNIX flavors. I also installed linux on my PC when this still was a non trivial act. At the university I worked we had those nice little networked workstations which commonly shared one computer (3 terminals, one computer, HP UX machines, Indys and later also Sparcs). They were slow. Not just a little bit but really slow. Even when we got newer hardware it still was slow. Probably those things are really nice if you can use them stand alone but networking to terminals clearly was a bad idea performance wise.
X windows is only nice if you have monolithical applications (i.e. apps you can't break up). If its monolithical that means it is probably too big to run on a small computer. If it's not, you can separate the GUI from the rest of the application. Well designed applications don't need to waste bandwidth on transmitting mouse clicks.
Now opengl over X sounds like a really bad idea. Even a modest 3d environment can contain hundreds of megabytes in textures and polygons. I have a hard time believing that you can squeeze that down a network in real time. If on the other hand you have it locally, why the heck would you want your software to run remotely? Any performance gains would be canceled by the network overhead.
An idea would be to bootstrap vmware or freemware ontop of an exokernel (I just read the HURD story). The idea of an exokernel is to put very little functionality in it and focus on multiplexing the hardware (so that it can be used by multiple applications). Using such a setup would make it possible to host multiple normal operating systems without having to use a limiting host OS.
I really like this idea of being able to run multiple operating systems at the same time since there is no one size fits all OS. Different applications come with different requirements. The ability to serve web pages is something entirely different than the ability to handle large files.
Yup, it couldn't handle the stampede of slashdotters (sorry couldn't resist)
I agree. Right now each OS provide is solving the same boring problems: getting 3d to work, getting driver support for exotic hardware, making a filesystem, etc.
Having a generic OS core that is free and allows other OS to coexist would mean a great deal for smaller operating systems like BeOS. They wouldn't have to worry so much about hardware support, they wouldn't have to worry so much about coexistence with other operating system and could focus on getting things to work with the virtual hardware instead.
What I'm curious at is whether a multimedia beast like BeOS can be run efficiently virtually or that it would have to live with the limitations of the host OS (filesystem size, etc.).
X windows is a solution to a non existent problem. It is too abstract for efficient hardware communication. This abstraction is justified by being able to remotely run an application which is something useful for some people but shouldn't get in the way of people who don't use that feature (far more people).
Today there are other ways to run an application remotely (HTML, java) which in the long term will make X windows obsolete for that purpose. The ability to remotely do 3d stuff doesn't impress me at all. It smells like bad software architecture to me. I'd be surprised if it works well over slow connections (like most 2d applications).
As far as I know XFree 4.0 contains optimizations and ways to get around X directly to the hardware. Probably it is very efficient (I trust those people know what they are doing) so that is a good thing.
The fact remains that it is an obsolete piece of technology patched to fullfill modern requirements rather than an efficient, well designed piece of software. But who cares, as long as it works it's ok with me. XFree 4.0 solves a long list of longstanding problems (at least it claims it will) so that's really nice. Replacing it never was an option so keep up the good work. I hope it will solve the performance problems, make it easier to write drivers and will support 3d better, make configuration less painfull and so on.
There is a difference between mozilla and communicator. Mozilla is currently alpha (at least that's being discussed at mozillazine). It will likely hit beta some time after that (late januari?). After mozilla goes final, netscape will add its stuff and start testing it which will take another few months. I don't expect a communicator 5 release before spring 2000 and that is assuming that there will be no more major setbacks.
Mozilla is a fine project from a software engineering perspective, I'm really excited about its probabilities but from a management perspective its a classical example of how not to manage a poject. It is taking up lots of resources (netscape engineers) and it is suffering from excessive feature creap which has caused the deadlines to shift enourmously (like half a year).
I think the people at netscape will have a really hard time convincing the rest of the world to run communicator 5. From an engineering perspective it certainly is an interesting product but engineers are only a minority of the target audience.
If mozilla is going to survive it will be on its technical merits. The mozilla project is promising a lot and judging from the nightly builds, it is delivering on those promises.
If on the other hand it will fail it will be because it came to late and missed its window of opportunity, which in my opinion will be nearly closed by spring 2000. Microsoft has been in the luxurious position that it had a great GUI for their browser for nearly two years. All this time they have been able to focus on producing a better rendering engine. I have a hard time believing that they won't release a better one before communicator ships. And they just got a few extra months to perfect their stuff.
you should see a doctor to get treatment for your paranoia.
:)"
"I remove all cookies during boot up each time and I NEVER KEEP sensitive personal info on my PC."
If I were you I would unplug the computer, lock the door and be afraid for the rest of my life. Not taking part in society is excellent defense against Big Brother. But seriously, what's the big deal with cookies? Only the site that created them can access them and they might as well store it serverside if there really is something worth storing. Cookies are mostly for your convenience so with deleting them you only give yourself extra trouble.
Moving privacy sensitive data to a central place gives you more privacy because you know who leaked information when something goes wrong. In my view your privacy sensitive data should be legally protected (i.e. you can sue when somebody illegally accessess it).
"Because some of us prefer that BIG BROTHER does not know everything we do and when and at what time...."
I suppose you're not that paranoid that you don't store your money in a bank. I.e. anytime you make a payment with your creditcard (online/offline) that information is registered anyway.
"Any other behavior is just proof of evolution in action...the stupid shall be fleeced
*sarcasm* Ok we an über mensch posting here.*/sarcasm* Just because you learned to operate a computer doesn't make you any smarter. In fact the smart let geeks like you do the monotonous work of operating a computer since they have better things to do.
I agree with this. The whole problem is that each web app deals with security on its own way. Many sites require a person to identify himself. This is commonly solved with a username/password combination. What would be nice is if there were a third party that would do user identification. Rather than providing each site with all your details you could authorize (through a certificate) a company to verify with that third party that you are you. This would also be a way to limit the amount of information you show to that company. The third party could of course maintain a database of user data but you could agree (with a contract if necessary) to restrict access to that database.
This would solve the privacy issue and it would allow sites to verify that you are who you say you are.
What we need for this is standards. We have standards to verify that a piece of software is from a certain company, why don't we have a standard to establish the identity of someone.
Scientology practices extortion and other bad things. The german government is very right in staying clear of anything this organization is involved with.
Actually I think the idea of MS teaming up with a scientology owned company is pretty ironic. Believe me MS' fud practices are amateurism compared to what scientology is capable of.
Some might claim that prohibiting an organization like scientology goes against free speech but does free speech include extortion practices?
I did what I described. I don't care what the survey says since the program screamed on my PC.
PalmOS already has a java VM. It works very well without being dependent on propietary Palm libraries.
The future by the way is not a Palm with 8 MB. There's a thing called progress. More likely a Palm with 128 MB and a 200MHZ+ processor is the nearby future.
I have no idea but I know the people at Symbian use rigorous coding standards for their stuff. Check out their coding regulations at their site (www.symbian.com).
The interesting thing is that with all the limitations they impose, the code mimics things that were designed into the Java language. It shows that in order to write reliable C++ code you have to be very disciplined.
Java programs generally are smaller than their C/C++ code versions. I did all three languages and I can say with a straight face that most things are much shorter in Java than they are in C.
The reason for this is that you can eliminate redundancy in your code by using OO, you don't have to do memory management and you have a great API with all sorts of default functionality. You won't cath me implementing a linked list in Java.
Ok I'm really scared now: MFC the next generation. I guess they'll never get it there.
"Please explain to me (with a straight face) why interger and Integer exist simultaneously."
Oh that's easy. Performance versus flexibility. If you want performance in an application, you don't want to use objects to model basic types like integers. If you want flexibility, you want to model basic types as objects so that you can put them in for instance a Collection Object.
Also the Integer, Boolean, etc classes contain nice static methods for conversion to and from string etc.
From a pure OO perspective the presence of basic types is wrong but then a pure OO program would probably be to slow when handling large amounts of objects so you need them to avoid creating an object for each integer in your program.
HOWTO show it to you. Hmm.
Take a modern PC >300 mhz and 128+ MB memory.
Install solaris or windows (whatever you prefer)
Download JDK 1.3 Beta (performs much better than 1.2)
Download TogetherJ, a full featured UML 1.3 modeling tool written in Java.
Run TogetherJ using jdk1.3 and enjoy. Its not that much slower than its main competitor (Rational Rose) and the system requirements are not different either. Featurewise TogetherJ also does nicely. I particularly like the way diagrams are synchronized with Java code.
TogetherJ synchronizes its UML 1.3 compliant diagrams with the java code that you type/generate (depending on whether you edit a diagram or the code). Very Cool! Apparently there also is a C++ version.
I thought it would be worthwile to mention it in this context. It is of course a Java program so you want a decent VM running on dito hardware (jdk 1.3 beta is very satisfying for this purpose).
Thank god you didn't learn programming in the time that Cobol was the main language because you'd be stuck with that instead.
"Would I want to write a driver in Java?"
You wouldn't. Drivers are hardware specific. What you do in Java is abstract from hardware. So what you'd do instead is use/create an API that does that for you (java3d for instance) and write a driver in C that mediates between the API and the hardware.
Its all about using the right tool for the right job.
"I would be reluctant to write OS level code (e.g., drivers) in an OO language"
If you do it well like the people that created BeOS for instance the result is very satisfying.
If you don't understand that windows 3.1 and mac os doesn't support non preemptive multitasking you run into trouble when you port a multithreaded app to that platform. If you don't know about green threads light weight processes when working on Solaris, you might run into problems.
Java made multi threaded programming a lot easier but it is still possible to shoot yourself in the foot. If you do don't blame Java but grab a book and learn how to do it properly (and comfort yourself that you wouldn't have pulled it of in another language either).
"I don't have to understand the context switching issues of various CPU's, because the OS takes care of that for me."
Yes you do, you have to understand that context swithching is an expensive operation on most platforms and that you should design your program in such a way that it limits the nr of context swithces.
Not understanding what you are doing is never a good idea. Java hides the complexity of programming parallel programs but does not protect you from writing inefficient software.
In the research group where I work a guy evaluated a few large C++ server applications for multiprocessing systems and he found that with some of those systems the performance decreased when you added more processors. The key to solving this problem was understanding context switches (which he did rather nicely).
Actually there's three sides to compatibility.
One is the API that has indeed evolved greatly (and that's definately a good thing). Most programs can be ported to later generation JDK with little effort.
Two is the language (the language hardly changed) and is backwards compatible.
Three is the bytecode (you can compile jdk 1.0.2 programs with the latest VM and provided it doesn't clash with the API it will work on any good jdk 1.0.2 VM)
So quit whining.