Java vs C++ speed (IO & Sorting)

[James Kanze]

[...]

You make a lot of assertions without explanation. How is
threading being part of language means the language is
suffering because of it?

Because it limits what you get. I thought I even gave an
example: an application which uses rwlock to manage shared
memory.

 

[pelio]

James Kanze dixit:

Two big issues: the fact that you cannot easily implement
programming by contract in interfaces, and the fact that you
cannot easily separate the class definition from the definition
of the member functions.

For the first, you can use abstract classes instead of
interfaces, but the actual virtual functions still have to be
protected (private is better), and you loose the possibility of
multiple inheritance.

Yes I miss multiple inheritance in Java. Too complicated to implement
and to explain.

For the second, you can use interfaces to work around the
problem more or less well, and the C++ solution is also far from
ideal. (Much better are Ada or Modula-3.) But it's still more
awkward in Java than in C++.

In C++ you usually provide a header file to client of your classes. In
Java this is different. You provide jar files and use import and
javadoc. So this is not a problem that there is no header file (actually
in C++, unless you care to do not so, you usually put private members in
header file which I don't find very clean; the same in ADA as far as I
remember)

The fact that you must dynamically link every class is also an
endless source of problems. In C++, of course, when you want
to be sure that the program works on site, you static link
almost everything---so that the version of the library used at
the deployment site cannot possibly be different from the one
you tested with. In Java, we even had a special name for this:
CLASSPATH hell.

If you want to not have problem with libraries you provide your version.
CLASSPATH allows you do that. This is not much different that static
linked C++ libraries. For dynamic C++ libraries, well same problem as
"dynamic" jar files.

There are also a lot of little things which get on ones nerves:
the fact that a constructor of a base class can call a function
in a derived class before the derived class' constructor has
even started, for example, has caused me grief in the past, and
the fact that there's absolutely no way to crash the program
when you know it's failed can be pretty frustrating as well (and
also means that you cannot use the language in critical
systems).

Perhaps I am too tired but can you give an example on how it can fail ?

 

[stan]

Or you can stop ruining the thread by continuously whining like a
10-year old.

One of us is certainly acting like a child. That determination is not up
to you though, it is up to other observers.

You don't bother me... keep on whining (even though the thread is
right no topic).

Can you even spell "charter"? You have no idea what is on topic here, as
you haven't even tried to find out. Finding out what a charter is and
what it does is left as a homework for the reader.

No it isn't. Whining about a topic in an unmoderated USENET newsgroup
is something that a newbie with thin skin does. If you knew anything
about USENET, you would know you (or anyone else) have no control on
what is posted here. Only a fool will waste time by whining about a
thread instead of ignoring it.

The fact that you think correcting people who are off topic is a newbie
behavior clearly indicates how long you've been around. I was reading
usenet on ARPANET. I don't believe I can control anyones behavior, that
is a belief held by the young, immature, and inexperienced. The fact
that I'm not all powerful doesn't mean that I must quietly suffer
unacceptable behavior. Rudeness deserves to be pointed out. It may not
help you, but may help others who are as inexperienced as you to become
aware of usenet behavior. Maybe it's time to mention the emily postnews
document for the benefit of people who wish to be good citizens. I'm
guessing that in your case it will be about like throwing marshmellows at a
turtle.

As for you idea that there is absolutely no control over usenet you're
not totally correct. There have been isp's that terminated accounts of
people who persistantly refuse to behave. Those cases have been
relatively rare, but they do exist. Nearly every isp has an abuse email
address. It's actually not hard at all to forward bad behavior to an
isp.

I find it sad that you consider it a "waste of time" to point out bad
behavior. There are people who are incapable of learning and I guess by
some stretch of the definition some would consider anyone attempting to
teach such an unfortunate person as a "fool". Again I find it sad that
you consider yourself as incapable of learning, but as I noted above
this is a public place and others may benifit and some of them are
teachable. I guess you'll have to revise you're name calling to "mostly
a fool".

 

[Arved Sandstrom]

I suspect that the performance improvements are due more to improvements
in the
virtual machine and not so much in language improvements. Think of it
this way.
Wouldn't you expect your C++ code to run faster on a real machine that is
several
years newer than another? The JVM with JDK1.6 is much improved over older
ones.

Someone who cares could probably test this using the 'old' class files
with both the
old and new JVMs.

Yes, I'll concede this argument. Apart from the obvious (faster CPUs) I'll
expect improvements in interpretation/compilation with succeeding
generations of VMs/compilers/interpreters etc. I checked out the performance
release notes for the last few major versions of Java, and indeed, there
have been substantial changes.

What I was trying to express, and expressed quite badly, was that I'd still
view a VM/compiler/interpreter somewhat askance if after it's been available
for a decade or more, that it suddenly is substantially improved (all other
things being equal) when used on code that basically has been around for a
long time too.

In any case, I prefer benchmarks that really do highlight the languages, as
tough as it may be to write such benchmarks. The benchmark would have to
include development (design/coding) time, complexity, readability, ease of
maintenance etc. For many programming problems I just don't see a straight
comparison of speed and memory size as being that important. As I and others
posted earlier in the thread it's possible in a number of other languages to
code solutions that are as fast (or faster) than either C++ or Java, for
this problem, have much more compact and maintainable code, are inherently
more bug-free, and are more readable. Compared to these other languages the
C++ solutions and Java solutions are roughly comparable. So why have a
pissing match between those two? IMHO.

AHS

 

[Razii]

The fact that you think correcting people who are off topic is a newbie
behavior clearly indicates how long you've been around. I was reading
usenet on ARPANET.

ARPAnet and Usenet were two different computer networks. Too bad you
have been around for long but didn't learn anything about not feeding
the troll (if I was a troll, which I am not. You are the troll since
you are whining about a thread which is right on topic according to my
interpretation, comparing c++ with other languages).

As for you idea that there is absolutely no control over usenet you're
not totally correct. There have been isp's that terminated accounts of
people who persistantly refuse to behave.

Good luck in trying to get ISPs get people account terminated based on
the fact that they posted something which you interpret as being
off-topic but other reasonable people might not.

 

[clearer]

One more run

Sorry about this -- I just had to see what results my computer would give me.

After having modified the code so that it would compile, I got these results:
Size

-rwxrwxr-x 1 clearer 17060 24 mar 04:06 IOSort
-rw-rw-r-- 1 clearer  1602 24 mar 04:03 IOSort.class
-rw-rw-r-- 1 clearer   653 24 mar 04:08 IOSort.cpp
-rw-rw-r-- 1 clearer   837 24 mar 04:03 IOSort.java

Running time (for A in 1 2 3 4 5 6 7 8 9; do time IOSort; echo echo; done)
This was run prior with no noticeable change in speed.

Time for reading, sorting, writing: 280 ms

real    0m0.785s
user    0m0.258s
sys     0m0.057s


Time for reading, sorting, writing: 290 ms

real    0m1.000s
user    0m0.249s
sys     0m0.075s


Time for reading, sorting, writing: 280 ms

real    0m0.920s
user    0m0.253s
sys     0m0.071s


Time for reading, sorting, writing: 270 ms

real    0m0.721s
user    0m0.243s
sys     0m0.070s


Time for reading, sorting, writing: 300 ms

real    0m0.858s
user    0m0.257s
sys     0m0.076s


Time for reading, sorting, writing: 280 ms

real    0m0.441s
user    0m0.250s
sys     0m0.071s


Time for reading, sorting, writing: 280 ms

real    0m0.496s
user    0m0.248s
sys     0m0.069s


Time for reading, sorting, writing: 290 ms

real    0m0.479s
user    0m0.244s
sys     0m0.091s


Time for reading, sorting, writing: 280 ms

real    0m0.512s
user    0m0.241s
sys     0m0.073s

Running time (for A in 1 2 3 4 5 6 7 8 9; do time java IOSort; echo echo; done)
This has been run before which was considerably slower on the first two runs -- caching is likely to have kicked in.

Time for reading, sorting, writing: 912 ms

real    0m1.403s
user    0m0.928s
sys     0m0.130s


Time for reading, sorting, writing: 979 ms

real    0m1.609s
user    0m0.918s
sys     0m0.119s


Time for reading, sorting, writing: 1030 ms

real    0m1.473s
user    0m0.927s
sys     0m0.128s


Time for reading, sorting, writing: 1066 ms

real    0m1.536s
user    0m0.938s
sys     0m0.124s


Time for reading, sorting, writing: 1164 ms

real    0m1.594s
user    0m0.930s
sys     0m0.137s


Time for reading, sorting, writing: 1664 ms

real    0m2.405s
user    0m0.957s
sys     0m0.143s


Time for reading, sorting, writing: 1711 ms

real    0m2.412s
user    0m0.967s
sys     0m0.114s


Time for reading, sorting, writing: 1616 ms

real    0m2.341s
user    0m0.940s
sys     0m0.138s


Time for reading, sorting, writing: 1650 ms

real    0m2.391s
user    0m0.954s
sys     0m0.121s

cat /proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) 
stepping        : 0
cpu MHz         : 1094.172
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips        : 2189.68
clflush size    : 32

I'm running this with ~500 MiB of free uncached RAM.

I changed the C++ program to the following:

#include <fstream>
#include <iostream>
#include <string>
#include <vector>
#include <algorithm>
#include <ctime>
#include <iterator>

int main()
{
	std::vector<std::string> buf;
	std::string linBuf;

	std::ifstream inFile ("bible.txt");
	clock_t start = clock();

	while (std::getline (inFile, linBuf))
		buf.insert (buf.end(), linBuf);

	std::sort (buf.begin(), buf.end());
	std::ofstream outFile ("output.txt");
	std::copy (buf.begin(), buf.end(), std::ostream_iterator<std::string> (outFile, "\n"));

	clock_t endt = clock();

	std::cout << "Time for reading, sorting, writing: " << ((endt - start) * 1000) / CLOCKS_PER_SEC << " ms\n";

	return 0;
}

It was compiled using g++ -o IOSort IOSort.cpp (i.e. no optimization -- it would likely not get any, anyway) using GCC 4.1.2 20070925 (Red Hat 4.1.2-33) and was then stripped (strip --strip-all IOSort).

The Java program was changed into

import java.io.*;
import java.util.*;

public class IOSort
{
	public static void main (String[] arg) throws Exception
	{
		ArrayList<String> ar = new ArrayList<String> (5000);

		String line = "";

		BufferedReader in = new BufferedReader (new FileReader ("bible.txt"));

		PrintWriter out = new PrintWriter (new BufferedWriter (new FileWriter ("output.txt")));

		long start = System.currentTimeMillis();

		while (true)
		{
			line = in.readLine();

			if (line == null)
				break;

			if (line.length() == 0)
				continue;
			ar.add (line);
		}

		Collections.sort (ar);

		int size = ar.size();

		for (int i = 0; i < size; i++)
			out.println (ar.get (i));

		out.close();

		long end = System.currentTimeMillis();
		System.out.println ("Time for reading, sorting, writing: " + (end - start) + " ms");
	}
}

And was compiled using IcedTea (Java 1.7.0) and run on the IcedTea Virtual Machine. For the uninformed, IcedTea is a Red Hat fork of Sun's OpenJDK, so it shouldn't be any different performance wise (not a whole lot anyway) to the Sun JDK.

This was tested on a Fedora 8 installation (32 bit x86) running Gnome 2.20 (i.e. with X running too) and a few other low intensity apps.

You'll notice that I changed the time calculations as it was bogus (it reported several hundred seconds of processor time).

My conclusion is that, even this simple program, the Java program is significantly slower on my machine -- ofcourse, my current processor is also significantly slower than the majority this program has been tested on, however, I do not see any of the performance penalty from IO reported on C++ -- maybe people should consider not using Visual Studio (it appears that people using VS have significant performance penalties on IO -- I wouldn't bet my spleen on it based on this program though).

Doing a bit of number crunching (on programs reported times, not the reported time of "time").

Java
Average: 1310,222...
Median:  1164

C++
Average: 281,111...
Median:  280

               Java     C++
Average ratio: 4,661 to 1
Median ratio:	4,157 to 1

You will also notice that it appears that the granuality of clock on my system appears to be 10 milliseconds, however, since I did several tests a few of them came out as 270 or 290, I don't consider that to be a big problem.

Edit:
uname -a

Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 athlon i386 GNU/Linux

 

[Mark Thornton]

more bug-free, and are more readable. Compared to these other languages the
C++ solutions and Java solutions are roughly comparable. So why have a
pissing match between those two? IMHO.

Once such pissing matches have started it seems impossible to stop them.
The involvement of Microsoft at various points makes a cessation of
hostilities even less likely.

Mark

 

[James Kanze]

James Kanze dixit:

[...]

In C++ you usually provide a header file to client of your
classes. In Java this is different. You provide jar files and
use import and javadoc.

Except that you can't use import and javadoc without the
complete implementation. The "advantage" of the class
definition in the header is that it is just the class
definition; it can be used without any associated function
definitions, and programmers can modify function definitions
without having write access to the header.

There are two widely recognized problem with C++ header files:
the first is that they work by means of textual inclusion, which
can lead to numberous versionning problems (although no solution
is totally immune to versionning problems), and the second is
that you still have to put a lot of implementation information
in the class definition. (There are even widely used patterns
to reduce this, like the compilation firewall idiom.)

Java seemingly got this radically wrong, and I can't really
understand why---the weakness in the C++ model (requiring
implemenationation details in the class definition) was already
recognized by the time Java was being developped---I remember
reading about the compilation firewall idiom (often known back
then as the Cheshire cat idiom---all you see of the
implementation is its smile) long before I'd ever heard of Java,
and it was also common practice then (and now) to forbid
defining any function in the class definition.

As for Javadoc, it puts the cart before the horse. You want to
write the documentation first, then generate the class
definition from it, and not vice versa. (This is more or less
supported by tools like Rose---if you consider the petal file as
the external class definition, then you could argue that Java
and C++ are on an equal footing here. But you can't compile
other sources against a petal file.)

So this is not a problem that there is no header file
(actually in C++, unless you care to do not so, you usually
put private members in header file which I don't find very
clean; the same in ADA as far as I remember)

The presence of private members is definitly a defect. Adding
function definitions just makes it worse.

If you want to not have problem with libraries you provide
your version. CLASSPATH allows you do that.

CLASSPATH is provided by the invoker, not by you. You have very
little control over what he provides.

This is not much different that static linked C++ libraries.
For dynamic C++ libraries, well same problem as "dynamic" jar
files.

More or less. You can still group several classes in a single
dynamic object. But of course, if you're worried about
robustness, you pretty much avoid dynamic linking as much as
possible.

As for jar files, I know that there exist techniques to "seal"
them, which reduces the risk. But dynamic linking remains
dynamic linking.

Perhaps I am too tired but can you give an example on how it
can fail ?

From actual experience, deriving from a class in Swing (I forget
which one). The constructor called one of the virtual
functions, which we'd overridden in the derived class. So we
returned a null pointer, since the constructor of the derived
class hadn't yet been called to set up the pointer.

There are several smaller cases like this, where the Java
solution is more "convenient" and perhaps more intuitive, but
where the C++ solution is more robust. None are really killer
criteria, however (although they do add up, when robustness is
important).

 

[stan]

ARPAnet and Usenet were two different computer networks. Too bad you
have been around for long but didn't learn anything about not feeding
the troll (if I was a troll, which I am not. You are the troll since
you are whining about a thread which is right on topic according to my
interpretation, comparing c++ with other languages).

I realize you're way too young to have any knowledge in this area, but
ARPA no longer exists. ARPA was the network that became the internet as
you know it.

As for you exibiting troll behavior, that's a done deal. You might want
to check the comp.lang.c++ faq for what is says about the "mine is
bigger than yours" troll.

As for your interpretation of topicality, that really isn't relevant.
You failed the homework assignment, sorry. A usenet group charter spells
out what is on topic for a particular newsgroup. Only modest reading
skills are required to se that you are clearly off topic. Advocacy
groups, amoung others, exist for the topic you seem to want to discuss.
The advocacy groups were created long ago to keep noise like this thread
from contaminating topical discussions. Earlier in this thread others
even spelled out alternative groups where this thread would be on topic.

Good luck in trying to get ISPs get people account terminated based on
the fact that they posted something which you interpret as being
off-topic but other reasonable people might not.

As I said, it's not at all common but the number of cases where it has
happened is greater than zero. Just last week I actually played a very
small third party role in two accounts being terminated. What surprised
me was that the accounts were terminated by Google. Traditionally google
has looked the other way and tolerated all sorts of things with little
action. I also personally know about other accounts that were terminated
so I know the number is greater than zero. I have no idea what total
number is, but I suspect it's not a large number.

In a bizzare case, there's actually a current case in New York courts
over usenet posts. It involves chess newsgroups, off topic slanderous
posts, impersonation, and other very strange accusations.

The point I was making was in response to your assertion that there is
no control over unmoderated usenet groups. That assertion is not totally
correct.

As for this thread, as I noted above it is clearly off topic and not an
interpretation issue. I have no idea what your ISP might do if someone
started forwarding your posts to the abuse contact.

 

[Mirek Fidler]

This topic was on these newsgroups 7 years ago

http://groups.google.com/group/comp.lang.c++/msg/695ebf877e25b287

I said then: "How about reading the whole Bible, sorting by lines, and
writing the sorted book to a file?"

Who remember that from 7 years ago, one of the longest thread on this
newsgroup

The text file used for the bible is hereftp://ftp.cs.princeton.edu/pub/cs126/markov/textfiles/bible.txt

Back to see if anything has changed

(downloaded whatever is latest version from sun.java.com)

Time for reading, sorting, writing: 359 ms (Java)
Time for reading, sorting, writing: 375 ms (Java)
Time for reading, sorting, writing: 375 ms (Java)

Visual C++ express and command I used was cl IOSort.cpp /O2

Time for reading, sorting, writing: 375 ms (c++)
Time for reading, sorting, writing: 390 ms (c++)
Time for reading, sorting, writing: 359 ms (c++)

C++ Core language is absolutely fantastic.

What most people do not realize is that the whole picture is
completely spoiled by C++ standard library. Its design and in most
cases implementation simply sucks big time. No wonder C++ gets beaten
by even virtual machines...

C++ standard library was designed around 1990, for hardware available
back then and today, it shows. Also, much more money and talent is
being put into JVM and Java libraries than individual companies can
afford to put into std:: implementation.

Mirek

 

[Mirek Fidler]

I said multiset.

You're requirement was "How about reading the whole Bible, sorting by
lines, and writing the sorted book to a file?"

Reading into a multiset and then writing out meets those requirements.

My guts feeling is that using multiset would be much slower than
sorting a vector.

There was Stepanov/Stroustrup bechmark a couple of years ago comparing
use of various containers/methods at "remove duplicit strings"
problem.

Loading all strings into vector, sorting and using std::unique has won
hands down.

Mirek

 

[Razii]

I realize you're way too young to have any knowledge in this area, but
ARPA no longer exists. ARPA was the network that became the internet as
you know it.

I knew that but you didn't know that ARPAnet and USENET were two
different networks.

As for you exibiting troll behavior, that's a done deal. You might want
to check the comp.lang.c++ faq for what is says about the "mine is
bigger than yours" troll.

There is no such thing in the FAQ. Post proof. And even if there was
such a thing, the FAQ means nothing. The person who wrote the FAQ has
no more ownership to the group than I do.

As for your interpretation of topicality, that really isn't relevant.
You failed the homework assignment, sorry. A usenet group charter spells
out what is on topic for a particular newsgroup.

Post proof or I will say you are lying. I see no such thing in the
original control message (sent in 1991) that created this group.

As I said, it's not at all common but the number of cases where it has
happened is greater than zero. Just last week I actually played a very
small third party role in two accounts being terminated. What surprised
me was that the accounts were terminated by Google.

Google is not an ISP. Google is just one of thousands of USENET
server. The person whose account was terminated by google can post
fine by using another server.

I have no idea what total
number is, but I suspect it's not a large number.

You are wrong. Most ISPs (and USENET server admins) won't care as long
the posts are not spam.

In a bizzare case, there's actually a current case in New York courts
over usenet posts. It involves chess newsgroups, off topic slanderous
posts, impersonation, and other very strange accusations.

Chess newsgroups and NewYork? My wild guess would be some guy called
Sam Sloan was involved.

The point I was making was in response to your assertion that there is
no control over unmoderated usenet groups. That assertion is not totally
correct.

You are wrong. There is no control whatsoever. A USENET admin only
controls his server. If he blocks you from his server, you can use
another server to post. Some server admins don't even recognize
moderated groups because they think it's censorship. Even if I fake
approved header and post it to c++.moderated (without moderator's
approval) these admin won't care and won't cancel the account. I know
from experience. You have a lot of learn.

 

[Razii]

I knew that but you didn't know that ARPAnet and USENET were two
different networks.

Since you seem to be confused here, I will post from USENET FAQ ..

8. Usenet is not the Internet.

The Internet is a wide-ranging network, parts of which are
subsidized by various governments. It carries many kinds of
traffic, of which Usenet is only one. And the Internet is only
one of the various networks carrying Usenet traffic.


9. Usenet is not a UUCP network.

UUCP is a protocol (actually a "protocol suite," but that's a
technical quibble) for sending data over point-to-point
connections, typically using dialup modems. Sites use UUCP to
carry many kinds of traffic, of which Usenet is only one. And
UUCP is only one of the various transports carrying Usenet
traffic.


13. Usenet is not software.

There are dozens of software packages used at various sites to
transport and read Usenet articles. So no one program or package
can be called "the Usenet software."

Software designed to support Usenet traffic can be (and is) used
for other kinds of communication, usually without risk of mixing
the two. Such private communication networks are typically kept
distinct from Usenet by the invention of newsgroup names different
from the universally-recognized ones.

2. Usenet is not a democracy.

Since there is no person or group in charge of Usenet as a whole
-- i.e. there is no Usenet "government" -- it follows that Usenet
cannot be a democracy, autocracy, or any other kind of "-acy."
(But see "The Camel's Nose?" below.)

3. Usenet is not fair.

After all, who shall decide what's fair? For that matter, if
someone is behaving unfairly, who's going to stop him? Neither
you nor I, that's certain.


CONTROL
-------
Every administrator controls his own site. No one has any real
control over any site but his own.

The administrator gets her power from the owner of the system she
administers. As long as her job performance pleases the owner, she
can do whatever she pleases, up to and including cutting off Usenet
entirely. Them's the breaks.

Sites are not entirely without influence on their neighbors, however.
There is a vague notion of "upstream" and "downstream" related to the
direction of high-volume news flow. To the extent that "upstream"
sites decide what traffic they will carry for their "downstream"
neighbors, those "upstream" sites have some influence on their
neighbors' participation in Usenet. But such influence is usually
easy to circumvent; and heavy-handed manipulation typically results in
a backlash of resentment.

PROPAGATION
-----------

In the old days, when UUCP over long-distance dialup lines was the
dominant means of article transmission, a few well-connected sites had
real influence in determining which newsgroups would be carried where.
Those sites called themselves "the backbone."

But things have changed. Nowadays, even the smallest Internet site
has connectivity the likes of which the backbone admin of yesteryear
could only dream. In addition, in the U.S., the advent of cheaper
long-distance calls and high-speed modems has made long-distance
Usenet feeds thinkable for smaller companies.

There is only one pre-eminent site for UUCP transport of Usenet in the
U.S., namely UUNET. But UUNET isn't a player in the propagation wars,
because it never refuses any traffic. UUNET charges by the minute,
after all; and besides, to refuse based on content might jeopardize
its legal status as an enhanced service provider.

All of the above applies to the U.S. In Europe, different cost
structures favored the creation of strictly controlled hierarchical
organizations with central registries. This is all very unlike the
traditional mode of U.S. sites (pick a name, get the software, get a
feed, you're on). Europe's "benign monopolies," long uncontested, now
face competition from looser organizations patterned after the U.S.
model.

THE CAMEL'S NOSE?
-----------------

As was observed above in "What Usenet Is Not," Usenet as a whole is
not a democracy. However, there is exactly one feature of Usenet that
has a form of democracy: newsgroup creation.

A new newsgroup is unlikely to be widely propagated unless its sponsor
follows the newsgroup creation guidelines; and the current guidelines
require a new newsgroup to pass an open vote.

There are those who consider the newsgroup creation process to be a
remarkably powerful form of democracy, since without any coercion, its
decisions are almost always carried out. In their view, the
democratic aspect of newsgroup creation is the precursor to an
organized and democratic Usenet Of The Future.

On the other hand, some consider the democratic aspect of the
newsgroup creation process a sham and a fraud, since there is no power
of enforcement behind its decisions, and since there appears little
likelihood that any such power of enforcement will ever be given it.
For them, the appearance of democracy is only a tool used to keep
proponents of flawed newsgroup proposals from complaining about their
losses.

So, is Usenet on its way to full democracy? Or will property rights
and mistrust of central authority win the day? Beats me.

 

[dave_mikesell]

There is no such thing in the FAQ. Post proof. And even if there was
such a thing, the FAQ means nothing. The person who wrote the FAQ has
no more ownership to the group than I do.

Then there are those things called decency and politeness, concepts
that appear to be lost on many in this generation.

 

[pelio]

Except that you can't use import and javadoc without the
complete implementation. The "advantage" of the class
definition in the header is that it is just the class
definition; it can be used without any associated function
definitions, and programmers can modify function definitions
without having write access to the header.

I am not sure what you say when "without complete implementation". A
java library file (jar file), is sufficient to use it (no need to have
the full source code) The javadoc is usually provided also separately
from the code.

It is sure one can not compile a java program using a library without
the jar file but I don't think this happens often. But in C++ you need
the libraries files - at linking time ok but you need them - so what is
the difference ? (well except if you want to test compilation, you can
do it in java too, just more work making a dummy jar file)

There are two widely recognized problem with C++ header files:
the first is that they work by means of textual inclusion, which
can lead to numberous versionning problems (although no solution
is totally immune to versionning problems), and the second is
that you still have to put a lot of implementation information
in the class definition. (There are even widely used patterns
to reduce this, like the compilation firewall idiom.)

Java seemingly got this radically wrong, and I can't really
understand why---the weakness in the C++ model (requiring
implemenationation details in the class definition) was already
recognized by the time Java was being developped---I remember
reading about the compilation firewall idiom (often known back
then as the Cheshire cat idiom---all you see of the
implementation is its smile) long before I'd ever heard of Java,
and it was also common practice then (and now) to forbid
defining any function in the class definition.

As a user you only need to know the interface and what a class does:
this is described in javadoc. A .java file is the implementation of a
class. If you want the definition (as a user of the class), you use
javadoc (no need for a header file)

As for Javadoc, it puts the cart before the horse. You want to
write the documentation first, then generate the class
definition from it, and not vice versa. (This is more or less
supported by tools like Rose---if you consider the petal file as
the external class definition, then you could argue that Java
and C++ are on an equal footing here. But you can't compile
other sources against a petal file.)

Javadoc is for user of your class. It does not prevent you from making
specification and design documentation before writing your code. And yes
when it comes to detailled design i write javadoc before code in method.

The presence of private members is definitly a defect. Adding
function definitions just makes it worse.



CLASSPATH is provided by the invoker, not by you. You have very
little control over what he provides.

That is wrong. I suppose you are thinking in the CLASSPATH environment
variable which may be set in a user enviroment. When you provide a java
program, you also provide the way to launch it (for exemplio a batch
file) in which you specify the classpath *you* want. Put the classpath
to libraries bundled with your binaries, and you be sure your program
will work.

Classpath had been a problem for a lot of people in the early years of
java because it was new (when you think of it now, it ist obvious)

Static linking is not perfect otherwise there would not have been
dynamic libraries; dynamic libraries is not perfect: often you have to
provide your own copy to be sure to be compatible. This is not a java
problem.

More or less. You can still group several classes in a single
dynamic object. But of course, if you're worried about
robustness, you pretty much avoid dynamic linking as much as
possible.

As for jar files, I know that there exist techniques to "seal"
them, which reduces the risk. But dynamic linking remains
dynamic linking.



From actual experience, deriving from a class in Swing (I forget
which one). The constructor called one of the virtual
functions, which we'd overridden in the derived class. So we
returned a null pointer, since the constructor of the derived
class hadn't yet been called to set up the pointer.

Well i guess the documentation was not accurate enough if it did not
mention that if overrided the method should not return null. Bad use or
design of classes is not a java specific problem.

 

[dave_mikesell]

That is wrong. I suppose you are thinking in the CLASSPATH environment
variable which may be set in a user enviroment. When you provide a java
program, you also provide the way to launch it (for exemplio a batch
file) in which you specify the classpath *you* want. Put the classpath
to libraries bundled with your binaries, and you be sure your program
will work.

How do you control which JRE your user uses? Do you bundle that as
well?

 

[Razii]

Then there are those things called decency and politeness, concepts
that appear to be lost on many in this generation.

Yes, I agree the abusive behavior by some here (of constant whining)
is deplorable.

 

[stan]

I knew that but you didn't know that ARPAnet and USENET were two
different networks.

I've forgotten more about ARPA than you know, I promise. "INTERNET" was
coined to refer to ARPA and BITnets along with a few others which were
smaller after they were fully interconnected over the ip/tcp protocol.
For awhile ARPAnet's backbone WAS the internet. But to be clear I'm not
saying that ARPA is the internet now, but they were not alwys totally seperate
networks.

There is no such thing in the FAQ. Post proof. And even if there was
such a thing, the FAQ means nothing. The person who wrote the FAQ has
no more ownership to the group than I do.

Try looking at 6.3, not that I care about your demands.

Post proof or I will say you are lying. I see no such thing in the
original control message (sent in 1991) that created this group.

Reading an issue? Again, I don't care about your accusations.

Google is not an ISP. Google is just one of thousands of USENET
server. The person whose account was terminated by google can post
fine by using another server.

I'm aware that Google isn't an ISP. I mentioned it because it was
unusual in that Google has historically been inactive and the change was
surprising; to me at least. The other cases I mentioned in passing were
about ISP's.

The general trend, from my admittedly smallish sample seems to be with
people going to the large usenet providers and skipping the smaller isp
variety.

You are wrong. Most ISPs (and USENET server admins) won't care as long
the posts are not spam.

I've never claimed that most or many take a very active part. In fact I
guess the "not a large number" you quoted wasn't a clue. Don't bother to
respond to my earlier query about reading problems; I see.

Chess newsgroups and NewYork? My wild guess would be some guy called
Sam Sloan was involved.

You got it, and as strange as Sam is, the case is about accusations of
someone impersonating him to do strange things. It's almost too much to
believe it's real but the NY Times had a small piece on it so it seems
to have at least some credibility. I don't know that much about the case
but I don't think Sam is the one who brought the case.

You are wrong. There is no control whatsoever. A USENET admin only
controls his server. If he blocks you from his server, you can use
another server to post. Some server admins don't even recognize
moderated groups because they think it's censorship. Even if I fake
approved header and post it to c++.moderated (without moderator's
approval) these admin won't care and won't cancel the account. I know
from experience. You have a lot of learn.

As I said, 'no control' is wrong. I understand that bad behavior and
it's perpetrators can jump around and keep trying. Depends on the
behavior though. Spam (which I admit is different than trolling) is
looked at far differently and there's been a couple of spammers lately
that have been found guilty.

You seem to think in pure black and white; either there is "no control
whatsoever" or there must be some central person who controls every
detail. Here in reality things are full of shades of grey and control is
certainly a range from none to total.

I admit I have a lot to learn about many things. I retired after 32
years of miitary service and went back to college. I'm surrounded by
things I don't know every day. As far as usenet goes, your experience
doesn't seem to have taught you many things. As I've noted elsewhare in
this thread, I don't believe you want to learn or be a good citizen from
your behavior in this thread. Others may learn something and we will all
benefit.

 

[stan]

Since you seem to be confused here, I will post from USENET FAQ ..

I didn't realize the USENET faq was getting that long in the tooth. It
probably should be updated a little. Nothing new in the faq.

One of the biggest changes to come along to usenet was the binary
phenom. That really made a difference in how sites were set up and run.
I believe that's one of the reasons I see more people moving to the
Giganews type thing. Local sites don't want to throw the resources at
long term retention for hugh binary groups and some have restricted the
servers so much sme are opting for the large news specialists. I've seen
both binary and binary seekers switch.

 

[Lew]

James Kanze said:

That is wrong. I suppose you are thinking in the CLASSPATH environment
variable which may be set in a user enviroment. When you provide a
java [sic] program, you also provide the way to launch it (for exemplio a batch
file) in which you specify the classpath *you* want. Put the classpath
to libraries bundled with your binaries, and you be sure your program
will work.

The standard way to package a Java standalone application is in a JAR file, in
which the manifest specifies the classpath in terms of affiliated JARs,
unpacked with the application JAR in the same installation directory or
subdirectories thereof. The invoker's CLASSPATH is explicitly ignored when
the application runs with the "java -jar" option.

The trouble with a "batch file" (i.e., a shell script) is that it defeats the
portability of Java, presumably one of the reasons to use Java in the first
place. The "-jar" option is as portable as Java itself. It obviates the
dependency on the CLASSPATH envar and on the OS shell, and provides an
alternative that can be deployed with the application itself.

How do you control which JRE your user uses? Do you bundle that as well?

No, silly. You inform the user of the minimum system requirements for your
product, just like everyone else does. You don't buy them a computer, either.

Java WebStart makes it convenient to script the requirement, and to give the
user an opportunity to upgrade their Java if need be.