This is a refreshing view on changes to Java, because it doesn't
make the
traditional calls for templates, a preprocessor, and operator
overloading.
Most of the article is well considered and logical, and should be
implemented in a move to Java 3.
There are however some issues with which I must disagree:
Under the discussion of primitive types, the author proposes that
the
current wrap-around handing of primitive types is incorrect.
Mathematically, yes - but not in computing terms. While the overhead of promoting all primitive types to objects may be
insignificant, the overhead of checking all arithmetic for overflow
does
have the possibility of causing significant overhead. Not only that, but you will still end up with a RuntimeException,
because
you cannot expect ALL arithmetic to be in a try... catch block. So
all
this becomes is an aid in debugging or forcing a crash (rather than
progress
based on an invalid computation) on a live system. I have to question
whether the performance trade-off is worth it. Overflow errors are a well known problem - well-written software
should not
suffer from them.
Still on the primitive types discussion, I don't believe the
author has
considered the impact of using an arbitrary-size number computing
which does
not require such numbers. The performance overhead is potentially
huge, and
you lose the ability to performance a large number of optimisations
based on
the fact that you are dealing with a quantity of a determistic size (in
memory). There are also threading and synchronisation considerations,
which
I will discuss later.
The byte type is unfortunately defined in Java. It
should be
unsigned, to begin with. It is certainly necessary for many IO
operations,
and data encoding/decoding; moveover it would be preferable if bytes
had the
special property that aritmetic operators converted other types to
bytes
(even if data loss was involved) rather than vice verse. Many Java developers are caught by using code like b =
(byte)i;
rather than b = (byte)(i & 0xff);. It is generally true that
when
dealing with bytes, you want to keep data as bytes until you
explicitly make
it into another type. Finally, byte arithmetic should always overflow, as is expected in
CPUs.
Last note on primitives (and it applies to 4-byte chars as well):
the
assumption we are afforded by Moore's law does NOT apply as the author
suggests. Rather, what was designed to run on a low-end Sun or 486
Intel PC
is now expected to run on a 1Mhz 8-bit CPU with 32Kb memory. While J2ME is not fully Java-compliant (no floating point support, for
example), it still largely conforms to the write-once test-everywhere
rule,
and this is part of Java's attractiveness.
Onto the size of chars. This is a bit of a tough one -- which it
would
be nice to have a 4-byte character, I have dealt with several Java
applications which were very String-intensive. They could gobble up
256Mb
RAM in a matter of seconds. A 4-byte char only worsens this problem.
It is
even doubtful that a char object (as opposed to primative) would help,
given
the overhead that would be associated with the object (at minimum a
type and
representation lenght - you're back at 4 bytes again). More memory is not always a good solution. Java's garbage collection
architecture is very wasteful of memory at the best of times; at the
worst
of times you are using immutable objects like Strings, so you can't
pool or
reuse the objects. As increasingly more applications handle text
because
of our new XML obsession, this situation becomes worse.
Threading next. I have studied Java's threading model in some
detail,
including the issue of non-atomic longs. The problem comes down to
one of
efficiency - again. Java implementations typically do not emulate threads on their most
common
platforms - they make use of the native threading model of the
operating
system. This means that making a 64-bit operation atomic must involve
the
use of a lock; so instead of a 64-bit operation taking up 4 times the
time
of a 32-bit operation, it could take that plus two calls into kernel
space. As mentioned before, the same is true of using arbitrary-size numbers.
Only
a number that the CPU can treat atomically will result in an atomic
operation without additional synchronisation.
With regard to monitors, I fail to see the need for multiple
monitors
per object. Every object is a monitor, and Java syntax provides for
implicit synchronisation on the current object as well as explicit
synchronisation on an arbitrary object. Thus, to have different types of operations (all implemenented in one
object) synchronised on different locks, simply use each in an explicit
synchronisation block and have private or protected lock objects
specifically for that purpose. Decoupling monitors from objects would kill a lot of the ease-of-use
that
makes Java threading such a pleasure by comparison to many other
models.
On the other hand, there are many weaknesses in Java threading. It
lacks a strongly-defined policy for thread scheduling, which can make
the
design of complex multithreaded applications very difficult. Furthermore it ONLY has monitors as locking primitives, which rules
out the
use of overlapping locks, which are one of the few effective
synchronisation
primitives which can overcome weakly-defined scheduling. Java would do well to add an additional synchronisation primitive -
either
mutexes (as error-prone as they are), or interlocked
increment-and-compare
(which can solve a number of synchronisation problems far more
effectively
than mutexes).
Onto the XML question, and getting to my area of pet hate: The XML
Silver Bullet.com. The author's bias towards XML is understandable,
but he
needs to realise, as do the millions of developers who let the
marketting
machine think for them, that XML is a poor implementation of a decent
idea. For a better critique of XML take a look at http://www.eastcoast.co.za/twylite/pml/pml.html"
>my anti-XML page
(incomplete, but the anti-XML rationale is presented). In particular, XML is a very poor choice for the encoding of Java
objects,
because of its lack of terseness, and the relatively slower speed of
parsing
XML - both of which impose significant penalties in a distributed
environment. Some hard facts to back up these claims: in an application I have
worked on,
we experimented with SOAP instead of our original binary protocol. The
result was a 80% decrease in call rate. In a few years, the XML phenomenon will wear off, and world+dog will
wonder
why we are wasting our precious bandwidth on all the overhead.
Already WS
developers are starting to wonder how it will affect their resources,
and we
have proposals for a binary encoded XML for the mobile world. This "simple" specification is too complex and too overkill for most
tasks,
so every "lightweight" XML parser on the market conveniently leaves out
certain parts of the specification - be it DTD, PI, CDATA, whatever.
We
already have XML documents that aren't compatible between two parsers,
the
situation will only worsen. And in the end we will realise that it isn't necessary to make
computer data
human-readable, because really, everything is just a bucket of bytes
and a
rule on how to view it, and XML is a very, very poor rule.
Java is not perfect. It is not a silver bullet, and it is
certainly not
everything to everyone. Instead, it offers an environment that, to a
lot of
people, is a damn sight better than C++ because it avoids the
error-prone
complexities and power of the latter. But you must accepts its
weaknesses
as a trade-off.
I'd rather have a system that the government can abuse than one an arbitrary criminal can abuse. Why? Because the government can abuse anything an arbitrary criminal can, and in most places of the world the word of one cop is NOT the law (cops have to prove that they handled evidence correctly, that there was a witness to all handling of evidence at all times, etc) - i.e. it takes two to tango.
And then again... why not? Do we really want a bunch of illegal immigrants running around... or how to we tell the difference between then and true nationals. Wait... racial profiling?
In South Africa you have an ID booklet (card system will occur sometime in the future... shees) and a passport. Both are optional, although you will always have an ID number, and need an ID book to vote, open bank accounts, etc. (Proving your ID without a birth certificate becomes fun though, by all accounts).
In addition, when you reach 16 your ID book is reissued (your "junior" ID expires when you reach 16), and you are fingerprinted before being issued your new ID. Shock, horror.
Privacy implications? Sure... if you are prepared to brush a place and run a fingerprint match, you can figure out if I was there. But then few people or organisations are likely to go to that trouble unless we're actually talking about a criminal indicent, which is precisely the case in which you want ALL adult fingerprints on file.
Does this mean I support genetic fingerprinting as well? No. A fingerprint in and of itself does not tell you anything significant about a person. A generic fingerprint does - many industries would love to get hold of that sort of information to load your insurance/medical premiums, to name but one possibility.
Every time someone mentions identity numbers, the YRO group gets up and slits their wrists. Why? Like it or not, you are identified every day but several numbers that you don't argue about, and probably have less control over.
Let's start with the basics. Every country needs a central population register. If it doesn't have one, it can't recognise its citizens and afford them their rights; or take action to protect itself against illegal immigrants; or issue you with a passport. At the very least that system has your legal name (at birth) and your date of birth. Without an entry in that system you can't prove your age or citizenship.
Now, as every database expert should know, full name and birth date do not have to be unique within a population. Therefore this "database" will include a unique number for every person. Even if its not given to you or used somewhere, you still have an identity number.
Now let's look at the implications of using that number outside the system. First, you have a card which can be used for identification purposes. This has good and bad points. It can be used to secure your transactions (prevent fraud against you), but also to link you with a transaction (reducing privacy). The better the security system of the card, the more difficult it is to forge, and the better the trade-off.
The ID card also serves to verify age. This is pretty important. How do you *know* she is 16? How does a bank know you are old enough to have a credit card? Many establishments that require age verification use a credit card or driver's license, but just because you are of the legal age to obtain one of these doesn't mean you actually have one. Not to mention that the legal age for driving is different in various parts of the world, and in many places you can get a credit card at any age if your parents sign surety.
What about SSNs? They are commonly used for a variety of identification purposes, but are a very poor choice for this! Knowing an SSN is a direct route to being able to abuse an SSN (in most countries) -- it is a number you NEED to keep private, but the lack of a unified identification system often prevents that from happening.
The lack of an ID card doesn't prevent the linking up of various disparate systems. In fact, most of these systems have poor design from a privacy standpoint, as they never had it in mind. You bank WILL know your SSN, drivers license, name, home address, and preferred make of condoms if it wants to. An ID system does not make this any more or less difficult.
So what's the BAD part about mandatory ID cards? The government and/or industry may enact policies that require positive identification at a time when such identification should not be needed. And that is what privacy legislation is there to ensure does not happen.
I, for one, like the fact that I have an identity card which is REQUIRED (by law) to be produced in any interactions with the government for the purposes obtaining passports, etc, or when opening accounts with a bank. It requires a fair amount of effort to fraudulently open an account in my name or otherwise impersonate me, and electronically secured (i.e. digitally signed) ID cards will make that more difficult in the future.
On the other hand, I don't give my ID number out to people or institutions who don't require it. I am aware of the privacy implications of having that number, even if there is no publically accessible means of misusing it.
The "handing over keys" thing is just FUD from the article poster. There is NO provision in the bill for this, after there was a public outcry about the recommendations of the technical committees (which did the research which led to the bill).
Unfortunately the public outcry was caused by FUD from morons just like this poster. The technical committees recommended that a court could issue a warrant to force any person to disclose their keys or the contents of an encrypted message or transaction (at the discression of the person receiving the warrant).
This would have been the most enlightened stance on the matter in the world, since you (if accused of wrongdoing) could avoid handing over your keys!
At the moment, legal opinion is that in most countries the court could force you to hand over your keys under existing law, if it deemed them important in an investigation, or find you in contempt.
So, thank you FUDding dipshits for fucking up a really good thing, because you couldn't be bothered to READ and UNDERSTAND the ACTUAL BILL, but relied on bullshit that you got from the rumourmill.
I'm not a serious photographer, but the ability to have full control over focus, aperture and exposure is important to me. I have found few digital cameras that will admit to being less intelligent than me in this regard, and none which allow (physical) aperture control.
I have done a fair amount of nature photography, especially birds. For a non-digital camera, aperture and film speed are critical. Optical magnification (as in a 2x or 4x converter, as opposed to a longer lense) is almost out of the question because each filter makes you lose 1 or 2 f-stops, which means a longer exposure and more chance of movement.
I have yet to find a digital camera which can adequately address this problem. They all use magnification filters instead of telephoto lenses so that they stay compact, and most only have digital compensation which they claim is aperture control.
A CCD which fits in place of a normal 35mm film would be a great way to get high quality photographs.
My right is to shoot you. My justification is that you have no social morality. Shit reason, yes. Especially since, as you point out, resorting to force is a march off the moral highground. The the law still violates my right to shoot you.
An example of a nasty problem I can think of with operator overloading is that both dereferencing operators can be overloaded, which adds a huge amount of complexity to the analysis. A->b() may not call method b() of class A!
Some other complexities of C++ include pointers and references; all Java data is passed by value (this is how the spec describes it, but "values" of objects are in fact references), making its behavioural model more simple.
I am also interested in the dependancy tree that will be built; while I am envisaging its use in a specific context here, it is a generally very useful structure to have, and you can derive a huge amount of information from it.
On large projects it means maybe I can't audit all of my code until you audit some of yours, which can be a big deal.
Yes, this is a hurdle that I saw. I think it can be avoided if you have a strongly modular system: audit each module independantly, making (and documenting) assumptions that calls to other modules are considered audited. Then the system as a whole can be considered audited when all modules have been audited.
I think this would require some use of graph theory to prove, and may be a good exercise before I make any further assumptions about the workability of this idea;)
It is so much harder to figure out what function is being called when you just see t->foo()!
Tell me about it;) I spent a couple of months working on a reverse engineering system. Fortunately we weren't targetting C++ (at the time) - it was a prospect I was not looking forward to.
But I still believe that if you take a module and can make that statement "assuming all the functions (list) which exist in other modules and are called from this one can be considered audited, this module can be audited", then you can audit virtual/polymorphic methods by auditing every such method in every class in that module.
I'm quite sure that only the parsing of the Java is easier then C++, not the actual analysis. Er, except maybe for templates. Drat.
An operator overloading, I'm inclined to think;)
Sometimes. Other times the many-heads produce a really complex set of goals, and the project flounders. A single head could produce a realistically small set of goal, write some code to half do the job, and then kick it on out where 50,000 people go "that's stupid, I could do better", and 3 people submit patches to make stuff better.
There's always someone who has to take the overkill scenario;) How about "a small positive number of heads (with attached bodies and in a state which would be considered "alive" by medical standards as applied to mammals of the genus homo sapiens sapiens) greater than one is in most if not all scenarios involving analysis and/or design a more effecient corpus for problem-solving that a single equivalent head"...?
Okay, this is to all those self righteous arrogant sons of karma whores who mod downs posts because they make any sort of positive reference to the Evil Empire (for all values of Evil Empire).
The post to which I replied attempts to defend CVS almost exclusively from a social viewpoint (uptake and support), while ignoring the technical shortcomings in the product. This is exactly the argument that the Open Source movement as a whole makes against Microsoft, a point which I illustrated through parody.
The argument that something is good or good enough simply because of widespread acceptance doesn't hold water. At best, CVS can be said to have been the best system available at the time. That in no way makes it a superior solution to full-blown configuration management systems.
So next time, think before you press your Troll hot-key, because just maybe the author isn't some 2 bit skript kiddie try to elicit a response from your sorry little back-room unix wannabe guru who has never worked on a Microsoft system but will claim it is shit anyway mind.
Sorry for the confusion, but I wasn't meaning that the SCM imposed a requirement for auditing - that would of course be optional. Rather, a file cannot be marked as audited until all of its contents have been audited ("a file requires all contents to be audited").
I don't believe having blocks which can be marked unauditable is a good idea. Rather, the auditor can make a best effort to check the code, and mark it as audited with a comment that the code is unsuitable to the standard audit procedures (whatever they are). The auditing system treats all code as opaque anyway -- a change means the audit is invalidated.
Java can let you load a class by name and call it. The name can be dynamically constructed. So any function that does this is unauitable.
While this presents a tough problem for auditing, use of this feature generally only applied to plug-ins (Tomcat is a counter-example). Such a method can be considered audited if it takes the necessary precautions (as can be taken) to prevent abuse, and obeys the contract of the plug-in. That way, if you are dealing with an audited plug-in, the system as a whole can be considered audited.
In both languages any virtual (or non final) member function might be a call to a never seen before class (if, for example you are a libarary).
Yes, this does make the logic behind dependancy analysis very difficult. My feeling was that, in a given system (which is assumed to be complete) a method cannot be considered audited until all descendants which override it are audited. This would also imply that a class cannot be considered audited until a number of members from sub- and super-classes have been audited. A nasty business!
I don't think C++ is any harder to analyse in this way, both are quite difficult, and full of big nasty traps. C++ is quite a bit harder to parse though
Certainly there are issues (otherwise I would have written it this weekend;) ), but (certainly for Java) I don't think any of them are insurmountable. Your comments and observations show that it would be valuable to gather a team to approach a problem like this; many heads are better than one (usually).
Thanks, this is very interesting! I have a page where I've been messing around with some thoughts about XML and how it should have been - minXML gives me some more material to think about.
Personally I prefer having the structure represented by tags, and data only in attributes. It makes it a little easier to represent certain categories of information (IMHO).
There is a natural extension to this which is just begging to happen: dependancy analysis and locking and/or approval mechanisms on a sub-file basis.
Essentially, if the SCM can parse the language, it can figure out what its looking at (classes, members, functions, etc), and what other parts of the entire source code use what its looking at.
Combined with an approval mechanism, the potential for code auditing is staggering: audit a function and mark it as such. No function can be considered audited if it calls a function which is not audited. If a function which was audited is updated, all functions which call it (in the new project revision) are no longer considered audited.
Functions and function documentation are audited as a unit. The should be obvious, because the idea of invalidating the stamp of approval on functions which call altered code is based on the idea that pre/post conditions may not have been properly disclosed or checked.
A class cannot be considered audited until all members are audited, and a file requires all contents to be audited.
Implementing a system like this for a languge like Java would not be tremendously difficult; but C++ (especially) is a very complex language to parse and analyse in this manner.
I would not hesitate to say that it has it's share of difficulties, but there is no way anything is going to replace it anytime soon. There are many meta-features of Windows that make it unable to be replaced:
1. Massive Acceptance: Windows is everywhere. 50 million people use it every day. Another few million elsewhere. It is the common thread that pulls us apart (kinda like the government!)
2. Massive, Massive Application support: This is my favorite. You can use it about a hundred different ways. Not 1 gui, but 500000!. It doesn't have command line apps, like great!. Show me another OS that has integration with the windows explorer like it has. You Can't. (Don't even try that god-awful WINE's integration:yuk!)
3. SimplicityIt's REALLY simple to use. It's not that complicated. If Windows throws you for a loop, maybe anything involving computers really isn't where you should be working. The incompetence among users is what makes all software look bad.
4. Protocols: You can run Windows with SSH, RSH, SMB, File Access, and more... It fits into every environment. It works across any damn network. It can jump tall buildings in a single bound!
Really, until someone makes something that trounces Windows in all those areas, AND provides features that "I can't live without" Windows will Rule.
This is NOT a troll. 100,000 lemmings CAN be wrong.
If my company spends $120,000 and I still have to spend two weeks thoroughly reading a document to comprehend it, then I shit all over the upper echelons. At that price I expect information, not data.
While I accept your point, I must counter that the Bindings and Profiles document runs over 50 pages (excluding title, ToC, references), and is almost purely technical. The Protocols and Schemes document is a further 20; and that's not the end of the technical specs.
Printed, the SOAP specification is a little under 20 pages, and XML a little under 50; both are laid out in a similar manner to these documents, and include examples, reference tables, etc. And XML can hardly be considered a simple specification (MS XML and Xerces are still trying to get fully compliant, many years on).
BEEP is a ridiculous waste of time which equates to XML-encoded-TCP over TCP/IP. The many unsubtle problems that causes should be obvious; if they aren't, here are some:
Multiple channels to a single endpoint: typically not useful without routing; few protocols require multiple data bands, and those that do usually require QOS in at least one band, in which case you want separate TCP/IP connections where QOS will (hopefully) be supported by routers between you and the server.
XML protocol headers: Adds a massive amount of bandwidth and processing overhead, which achieve little if any benefit over a binary encoding. Contrary to popular bullshit, XML is not human readable (as if computers care about that), is not fast/efficient and is not programmatically simple to decode (2 grammars, 2 character encodings, 5 syntactically different data classes, and 2 orthogonal data models all in once specification with more BNF rules than C++!). The XML spec. states explicitly "Terseness is of minimal importance..." - certainly NOT what you want to use as header data on packets in a communication channel.
Security: BEEP proides just another mechanism for hiding attacks, and requires a new application level firewall which must feature a full XML parser (in order to monitor and firewall individual channels within the protocol). Not only that... you think that Unicode attacks are bad? With several years of development behind them, MS XML parser and Xerces STILL aren't fully XML 1.0 compilant -- how many security compromises do you think may be present with all the encodings XML supports, and how many will be present in the hundreds of less mature products?
You point out that SGML is a bad thing for encoding "at that level", but in the same breath say that XML is a good thing. Since XML is SGML-compatible, and largely employs the same syntax (but doesn't allow SGML short-cuts like leaving out closing tags), I fail to follow your argument.
And in your musings about the IETF, has it ever struck you that maybe the IETF also think that adding an incomprehensibly slow transport layer on top of an existing and widely supported transport layer is a shit idea? BEEP is NOT an application level protocol, even if it wants to claim to be one.
I think you missed my point entirely. In many rural communities, especially in Africa (the situation in India, specifically, is different), people don't have access to education because of the distances involved in getting to facilities.
Studies have shown that computers CAN, if used correctly, address this problem, and be a substitute, not simply a tool, for traditional basic education. This is because a computer CAN be used to teach literacy, basic mathematics, etc, and most importantly CAN be located nearer to the target audience than traditional resources (such as teachers).
Books are useless without literacy. Even for the literate, educational books are of questionable value without a suitable guide. This is a basic flaw in using a non-interactive medium for education. Only once you have learned to educate yourself (which is supposed to be the basic skill you learn at a University) can you be reasonably expected to learn from books. (This isn't to say that people don't, but rather that not all people do).
Regarding medical knowledge, I was referring to expert systems, not to medical texts. In a community where there is no doctor, an maybe only a nurse several kilometers away, an expert system can be a valuable aid.
Finally, having been taught by several crap teachers, I'll take a filmstrip any day. Educational broadcasts in developing nations are proving to have more success than formal education, because they reach a wider audience, and are presented in a clear and understandable fashion... completely unlike a lesson from a crap teacher.
Computers are, surprisingly, less necessary in an environment where there is a higher literacy rate. Computers, unlike books or pencil and paper, can teach literacy. This is probably the most critical application in underdeveloped countries.
As for the problems it will solve: #1. Communication. This is far less obvious that it may seem, but many poor people spend an enormous amount of their annual income on communication, primarily to stay in contact with loved ones who have moved to cities (in search of an income / better living). It is painfully obvious that e-mail is orders of magnitude cheaper than long-distance phone calls; something that many "operators" take their cut for along the line (most often an enterprising shop owner pays ridiculous bribes to get a telephone installed, and then passes that cost along to the consumers...).
Access to knowledge bases is also important. Medical knowledge is often sorely lacking in rural areas. For literate adults, a source of educational information is also important.
Technology can be used to improve quality of life, not just as a passtime for the rich.
You're absolutely right: $200 is far too expensive. But...
A pencil and paper only assist if you are either literate, or able to receive instruction. Computers, on the other hand, can teach literacy. This has huge potential: (in Africa) many people can't take the time to attend literacy classes (which may involve walking 15km or more). There are also a lack of resources to sustain ongoing training.
Between a computer and cleaner water, sure, go for the cleaner water. But first consider some things: (1) in many places the water is sufficiently clean or at least not a health risk to the population (whereas it may be a risk to a Western visitor who is not accustomed to the local bacteria); (2) without education, most people don't know enough about the importance of clean water and basic sanitation, which in itself is the greatest threat to natural supplies of clean water.
Reminds me of the big chemical companies promoting pesticides in the third world thus putting entire populations and countries into debt. Supplying cheap(ish) computers is subtly different from supplying engineered toxins which solve your problem for a year or two but poison the environment so that only related products from the same supplier will allow food to grow.
If you're hungry and in a country where many people are dying of preventable illnesses, education is the greatest key to upliftment.
Most children have to forgo the opportunity of education in order to survive, because they are needed at home to contribute. This means that they don't have the time to walk 15km to and from school every day, as many children in Africa do.
A broader base of accessible computers is a means to improve this situation. It will allow literacy improvement at home for many children and adults. It will also bring knowledge on how to avoid preventable diseases, primarily through basic nutrition and sanitation.
These are areas of adult education that have been notoriously difficult to target because of a lack of resources, and the target audience being illiterate and not having the time to devote to learning.
An interactive medium like a computer does not require literacy, and can be used to teach literacy. It can also (through expert systems) substitute for a doctor or paramedic when experts are not on hand (say, 100km away on a dirt road).
The digital divide is not about people who don't have (quake|word processing|e-mail) versus those who do, it is about the failure to use modern (digital) technologies to address issues in underdeveloped countries.
Maslow's Hierarchy is a model, and as with most models it is not entirely accurate, nor is it intended to function without context. 'Surfing the net' may not feature, but security needs and social needs -- both of which are enabled through education -- are directly above physical/biological needs.
Slashdot Mirror
This is a refreshing view on changes to Java, because it doesn't make the traditional calls for templates, a preprocessor, and operator overloading. Most of the article is well considered and logical, and should be implemented in a move to Java 3.
There are however some issues with which I must disagree:
While the overhead of promoting all primitive types to objects may be insignificant, the overhead of checking all arithmetic for overflow does have the possibility of causing significant overhead.
Not only that, but you will still end up with a RuntimeException, because you cannot expect ALL arithmetic to be in a try
Overflow errors are a well known problem - well-written software should not suffer from them.
Many Java developers are caught by using code like b = (byte)i; rather than b = (byte)(i & 0xff);. It is generally true that when dealing with bytes, you want to keep data as bytes until you explicitly make it into another type.
Finally, byte arithmetic should always overflow, as is expected in CPUs.
While J2ME is not fully Java-compliant (no floating point support, for example), it still largely conforms to the write-once test-everywhere rule, and this is part of Java's attractiveness.
More memory is not always a good solution. Java's garbage collection architecture is very wasteful of memory at the best of times; at the worst of times you are using immutable objects like Strings, so you can't pool or reuse the objects. As increasingly more applications handle text because of our new XML obsession, this situation becomes worse.
Java implementations typically do not emulate threads on their most common platforms - they make use of the native threading model of the operating system. This means that making a 64-bit operation atomic must involve the use of a lock; so instead of a 64-bit operation taking up 4 times the time of a 32-bit operation, it could take that plus two calls into kernel space.
As mentioned before, the same is true of using arbitrary-size numbers. Only a number that the CPU can treat atomically will result in an atomic operation without additional synchronisation.
Thus, to have different types of operations (all implemenented in one object) synchronised on different locks, simply use each in an explicit synchronisation block and have private or protected lock objects specifically for that purpose.
Decoupling monitors from objects would kill a lot of the ease-of-use that makes Java threading such a pleasure by comparison to many other models.
Furthermore it ONLY has monitors as locking primitives, which rules out the use of overlapping locks, which are one of the few effective synchronisation primitives which can overcome weakly-defined scheduling.
Java would do well to add an additional synchronisation primitive - either mutexes (as error-prone as they are), or interlocked increment-and-compare (which can solve a number of synchronisation problems far more effectively than mutexes).
For a better critique of XML take a look at http://www.eastcoast.co.za/twylite/pml/pml.html" >my anti-XML page (incomplete, but the anti-XML rationale is presented).
In particular, XML is a very poor choice for the encoding of Java objects, because of its lack of terseness, and the relatively slower speed of parsing XML - both of which impose significant penalties in a distributed environment.
Some hard facts to back up these claims: in an application I have worked on, we experimented with SOAP instead of our original binary protocol. The result was a 80% decrease in call rate.
In a few years, the XML phenomenon will wear off, and world+dog will wonder why we are wasting our precious bandwidth on all the overhead. Already WS developers are starting to wonder how it will affect their resources, and we have proposals for a binary encoded XML for the mobile world.
This "simple" specification is too complex and too overkill for most tasks, so every "lightweight" XML parser on the market conveniently leaves out certain parts of the specification - be it DTD, PI, CDATA, whatever. We already have XML documents that aren't compatible between two parsers, the situation will only worsen.
And in the end we will realise that it isn't necessary to make computer data human-readable, because really, everything is just a bucket of bytes and a rule on how to view it, and XML is a very, very poor rule.
Java is not perfect. It is not a silver bullet, and it is certainly not everything to everyone. Instead, it offers an environment that, to a lot of people, is a damn sight better than C++ because it avoids the error-prone complexities and power of the latter. But you must accepts its weaknesses as a trade-off.
I'd rather have a system that the government can abuse than one an arbitrary criminal can abuse. Why? Because the government can abuse anything an arbitrary criminal can, and in most places of the world the word of one cop is NOT the law (cops have to prove that they handled evidence correctly, that there was a witness to all handling of evidence at all times, etc) - i.e. it takes two to tango.
And then again ... why not? Do we really want a bunch of illegal immigrants running around ... or how to we tell the difference between then and true nationals. Wait ... racial profiling?
In South Africa you have an ID booklet (card system will occur sometime in the future ... shees) and a passport. Both are optional, although you will always have an ID number, and need an ID book to vote, open bank accounts, etc. (Proving your ID without a birth certificate becomes fun though, by all accounts).
In addition, when you reach 16 your ID book is reissued (your "junior" ID expires when you reach 16), and you are fingerprinted before being issued your new ID. Shock, horror.
Privacy implications? Sure ... if you are prepared to brush a place and run a fingerprint match, you can figure out if I was there. But then few people or organisations are likely to go to that trouble unless we're actually talking about a criminal indicent, which is precisely the case in which you want ALL adult fingerprints on file.
Does this mean I support genetic fingerprinting as well? No. A fingerprint in and of itself does not tell you anything significant about a person. A generic fingerprint does - many industries would love to get hold of that sort of information to load your insurance/medical premiums, to name but one possibility.
Every time someone mentions identity numbers, the YRO group gets up and slits their wrists. Why? Like it or not, you are identified every day but several numbers that you don't argue about, and probably have less control over.
Let's start with the basics. Every country needs a central population register. If it doesn't have one, it can't recognise its citizens and afford them their rights; or take action to protect itself against illegal immigrants; or issue you with a passport. At the very least that system has your legal name (at birth) and your date of birth. Without an entry in that system you can't prove your age or citizenship.
Now, as every database expert should know, full name and birth date do not have to be unique within a population. Therefore this "database" will include a unique number for every person. Even if its not given to you or used somewhere, you still have an identity number.
Now let's look at the implications of using that number outside the system. First, you have a card which can be used for identification purposes. This has good and bad points. It can be used to secure your transactions (prevent fraud against you), but also to link you with a transaction (reducing privacy). The better the security system of the card, the more difficult it is to forge, and the better the trade-off.
The ID card also serves to verify age. This is pretty important. How do you *know* she is 16? How does a bank know you are old enough to have a credit card? Many establishments that require age verification use a credit card or driver's license, but just because you are of the legal age to obtain one of these doesn't mean you actually have one. Not to mention that the legal age for driving is different in various parts of the world, and in many places you can get a credit card at any age if your parents sign surety.
What about SSNs? They are commonly used for a variety of identification purposes, but are a very poor choice for this! Knowing an SSN is a direct route to being able to abuse an SSN (in most countries) -- it is a number you NEED to keep private, but the lack of a unified identification system often prevents that from happening.
The lack of an ID card doesn't prevent the linking up of various disparate systems. In fact, most of these systems have poor design from a privacy standpoint, as they never had it in mind. You bank WILL know your SSN, drivers license, name, home address, and preferred make of condoms if it wants to. An ID system does not make this any more or less difficult.
So what's the BAD part about mandatory ID cards? The government and/or industry may enact policies that require positive identification at a time when such identification should not be needed. And that is what privacy legislation is there to ensure does not happen.
I, for one, like the fact that I have an identity card which is REQUIRED (by law) to be produced in any interactions with the government for the purposes obtaining passports, etc, or when opening accounts with a bank. It requires a fair amount of effort to fraudulently open an account in my name or otherwise impersonate me, and electronically secured (i.e. digitally signed) ID cards will make that more difficult in the future.
On the other hand, I don't give my ID number out to people or institutions who don't require it. I am aware of the privacy implications of having that number, even if there is no publically accessible means of misusing it.
The "handing over keys" thing is just FUD from the article poster. There is NO provision in the bill for this, after there was a public outcry about the recommendations of the technical committees (which did the research which led to the bill).
Unfortunately the public outcry was caused by FUD from morons just like this poster. The technical committees recommended that a court could issue a warrant to force any person to disclose their keys or the contents of an encrypted message or transaction (at the discression of the person receiving the warrant).
This would have been the most enlightened stance on the matter in the world, since you (if accused of wrongdoing) could avoid handing over your keys!
At the moment, legal opinion is that in most countries the court could force you to hand over your keys under existing law, if it deemed them important in an investigation, or find you in contempt.
So, thank you FUDding dipshits for fucking up a really good thing, because you couldn't be bothered to READ and UNDERSTAND the ACTUAL BILL, but relied on bullshit that you got from the rumourmill.
I'm not a serious photographer, but the ability to have full control over focus, aperture and exposure is important to me. I have found few digital cameras that will admit to being less intelligent than me in this regard, and none which allow (physical) aperture control.
I have done a fair amount of nature photography, especially birds. For a non-digital camera, aperture and film speed are critical. Optical magnification (as in a 2x or 4x converter, as opposed to a longer lense) is almost out of the question because each filter makes you lose 1 or 2 f-stops, which means a longer exposure and more chance of movement.
I have yet to find a digital camera which can adequately address this problem. They all use magnification filters instead of telephoto lenses so that they stay compact, and most only have digital compensation which they claim is aperture control.
A CCD which fits in place of a normal 35mm film would be a great way to get high quality photographs.
My right is to shoot you. My justification is that you have no social morality. Shit reason, yes. Especially since, as you point out, resorting to force is a march off the moral highground. The the law still violates my right to shoot you.
And finally, US law violates my right to shoot you for having no social morality.
An example of a nasty problem I can think of with operator overloading is that both dereferencing operators can be overloaded, which adds a huge amount of complexity to the analysis. A->b() may not call method b() of class A!
Some other complexities of C++ include pointers and references; all Java data is passed by value (this is how the spec describes it, but "values" of objects are in fact references), making its behavioural model more simple.
I am also interested in the dependancy tree that will be built; while I am envisaging its use in a specific context here, it is a generally very useful structure to have, and you can derive a huge amount of information from it.
Yes, this is a hurdle that I saw. I think it can be avoided if you have a strongly modular system: audit each module independantly, making (and documenting) assumptions that calls to other modules are considered audited. Then the system as a whole can be considered audited when all modules have been audited.
I think this would require some use of graph theory to prove, and may be a good exercise before I make any further assumptions about the workability of this idea ;)
Tell me about it ;) I spent a couple of months working on a reverse engineering system. Fortunately we weren't targetting C++ (at the time) - it was a prospect I was not looking forward to.
But I still believe that if you take a module and can make that statement "assuming all the functions (list) which exist in other modules and are called from this one can be considered audited, this module can be audited", then you can audit virtual/polymorphic methods by auditing every such method in every class in that module.
An operator overloading, I'm inclined to think ;)
There's always someone who has to take the overkill scenario ;) How about "a small positive number of heads (with attached bodies and in a state which would be considered "alive" by medical standards as applied to mammals of the genus homo sapiens sapiens) greater than one is in most if not all scenarios involving analysis and/or design a more effecient corpus for problem-solving that a single equivalent head" ...?
Okay, this is to all those self righteous arrogant sons of karma whores who mod downs posts because they make any sort of positive reference to the Evil Empire (for all values of Evil Empire).
The post to which I replied attempts to defend CVS almost exclusively from a social viewpoint (uptake and support), while ignoring the technical shortcomings in the product. This is exactly the argument that the Open Source movement as a whole makes against Microsoft, a point which I illustrated through parody.
The argument that something is good or good enough simply because of widespread acceptance doesn't hold water. At best, CVS can be said to have been the best system available at the time. That in no way makes it a superior solution to full-blown configuration management systems.
So next time, think before you press your Troll hot-key, because just maybe the author isn't some 2 bit skript kiddie try to elicit a response from your sorry little back-room unix wannabe guru who has never worked on a Microsoft system but will claim it is shit anyway mind.
Sorry for the confusion, but I wasn't meaning that the SCM imposed a requirement for auditing - that would of course be optional. Rather, a file cannot be marked as audited until all of its contents have been audited ("a file requires all contents to be audited").
I don't believe having blocks which can be marked unauditable is a good idea. Rather, the auditor can make a best effort to check the code, and mark it as audited with a comment that the code is unsuitable to the standard audit procedures (whatever they are). The auditing system treats all code as opaque anyway -- a change means the audit is invalidated.
While this presents a tough problem for auditing, use of this feature generally only applied to plug-ins (Tomcat is a counter-example). Such a method can be considered audited if it takes the necessary precautions (as can be taken) to prevent abuse, and obeys the contract of the plug-in. That way, if you are dealing with an audited plug-in, the system as a whole can be considered audited.
Yes, this does make the logic behind dependancy analysis very difficult. My feeling was that, in a given system (which is assumed to be complete) a method cannot be considered audited until all descendants which override it are audited. This would also imply that a class cannot be considered audited until a number of members from sub- and super-classes have been audited. A nasty business!
Certainly there are issues (otherwise I would have written it this weekend ;) ), but (certainly for Java) I don't think any of them are insurmountable. Your comments and observations show that it would be valuable to gather a team to approach a problem like this; many heads are better than one (usually).
Thanks, this is very interesting! I have a page where I've been messing around with some thoughts about XML and how it should have been - minXML gives me some more material to think about.
Personally I prefer having the structure represented by tags, and data only in attributes. It makes it a little easier to represent certain categories of information (IMHO).
There is a natural extension to this which is just begging to happen: dependancy analysis and locking and/or approval mechanisms on a sub-file basis.
Essentially, if the SCM can parse the language, it can figure out what its looking at (classes, members, functions, etc), and what other parts of the entire source code use what its looking at.
Combined with an approval mechanism, the potential for code auditing is staggering: audit a function and mark it as such. No function can be considered audited if it calls a function which is not audited. If a function which was audited is updated, all functions which call it (in the new project revision) are no longer considered audited.
Functions and function documentation are audited as a unit. The should be obvious, because the idea of invalidating the stamp of approval on functions which call altered code is based on the idea that pre/post conditions may not have been properly disclosed or checked.
A class cannot be considered audited until all members are audited, and a file requires all contents to be audited.
Implementing a system like this for a languge like Java would not be tremendously difficult; but C++ (especially) is a very complex language to parse and analyse in this manner.
Look, Windows is king.
Yes, King.
I would not hesitate to say that it has it's share of difficulties, but there is no way anything is going to replace it anytime soon. There are many meta-features of Windows that make it unable to be replaced:
1. Massive Acceptance: Windows is everywhere. 50 million people use it every day. Another few million elsewhere. It is the common thread that pulls us apart (kinda like the government!)
2. Massive, Massive Application support: This is my favorite. You can use it about a hundred different ways. Not 1 gui, but 500000!. It doesn't have command line apps, like great!. Show me another OS that has integration with the windows explorer like it has. You Can't. (Don't even try that god-awful WINE's integration:yuk!)
3. SimplicityIt's REALLY simple to use. It's not that complicated. If Windows throws you for a loop, maybe anything involving computers really isn't where you should be working. The incompetence among users is what makes all software look bad.
4. Protocols: You can run Windows with SSH, RSH, SMB, File Access, and more... It fits into every environment. It works across any damn network. It can jump tall buildings in a single bound!
Really, until someone makes something that trounces Windows in all those areas, AND provides features that "I can't live without" Windows will Rule.
This is NOT a troll. 100,000 lemmings CAN be wrong.
If my company spends $120,000 and I still have to spend two weeks thoroughly reading a document to comprehend it, then I shit all over the upper echelons. At that price I expect information, not data.
While I accept your point, I must counter that the Bindings and Profiles document runs over 50 pages (excluding title, ToC, references), and is almost purely technical. The Protocols and Schemes document is a further 20; and that's not the end of the technical specs.
Printed, the SOAP specification is a little under 20 pages, and XML a little under 50; both are laid out in a similar manner to these documents, and include examples, reference tables, etc. And XML can hardly be considered a simple specification (MS XML and Xerces are still trying to get fully compliant, many years on).
Drive the market for massively high bandwidth, Gigabit switches, Pentium 4s and horribly expensive application level firewalls...?
Nothing which requires 1.8Mb of compressed PDFs to describe can fall into the category "simple".
I'm sorry, but I can't buy much of this at all.
BEEP is a ridiculous waste of time which equates to XML-encoded-TCP over TCP/IP. The many unsubtle problems that causes should be obvious; if they aren't, here are some:
You point out that SGML is a bad thing for encoding "at that level", but in the same breath say that XML is a good thing. Since XML is SGML-compatible, and largely employs the same syntax (but doesn't allow SGML short-cuts like leaving out closing tags), I fail to follow your argument.
And in your musings about the IETF, has it ever struck you that maybe the IETF also think that adding an incomprehensibly slow transport layer on top of an existing and widely supported transport layer is a shit idea? BEEP is NOT an application level protocol, even if it wants to claim to be one.
I think you missed my point entirely. In many rural communities, especially in Africa (the situation in India, specifically, is different), people don't have access to education because of the distances involved in getting to facilities.
Studies have shown that computers CAN, if used correctly, address this problem, and be a substitute, not simply a tool, for traditional basic education. This is because a computer CAN be used to teach literacy, basic mathematics, etc, and most importantly CAN be located nearer to the target audience than traditional resources (such as teachers).
Books are useless without literacy. Even for the literate, educational books are of questionable value without a suitable guide. This is a basic flaw in using a non-interactive medium for education. Only once you have learned to educate yourself (which is supposed to be the basic skill you learn at a University) can you be reasonably expected to learn from books. (This isn't to say that people don't, but rather that not all people do).
Regarding medical knowledge, I was referring to expert systems, not to medical texts. In a community where there is no doctor, an maybe only a nurse several kilometers away, an expert system can be a valuable aid.
Finally, having been taught by several crap teachers, I'll take a filmstrip any day. Educational broadcasts in developing nations are proving to have more success than formal education, because they reach a wider audience, and are presented in a clear and understandable fashion ... completely unlike a lesson from a crap teacher.
According to Google, 33000 lemmings^Wpeople think you're wrong. So does the Oxford English Dictionary.
You're American right ...?
Computers are, surprisingly, less necessary in an environment where there is a higher literacy rate. Computers, unlike books or pencil and paper, can teach literacy. This is probably the most critical application in underdeveloped countries.
As for the problems it will solve: #1. Communication. This is far less obvious that it may seem, but many poor people spend an enormous amount of their annual income on communication, primarily to stay in contact with loved ones who have moved to cities (in search of an income / better living). It is painfully obvious that e-mail is orders of magnitude cheaper than long-distance phone calls; something that many "operators" take their cut for along the line (most often an enterprising shop owner pays ridiculous bribes to get a telephone installed, and then passes that cost along to the consumers ...).
Access to knowledge bases is also important. Medical knowledge is often sorely lacking in rural areas. For literate adults, a source of educational information is also important.
Technology can be used to improve quality of life, not just as a passtime for the rich.
You're absolutely right: $200 is far too expensive. But...
A pencil and paper only assist if you are either literate, or able to receive instruction. Computers, on the other hand, can teach literacy. This has huge potential: (in Africa) many people can't take the time to attend literacy classes (which may involve walking 15km or more). There are also a lack of resources to sustain ongoing training.
Between a computer and cleaner water, sure, go for the cleaner water. But first consider some things: (1) in many places the water is sufficiently clean or at least not a health risk to the population (whereas it may be a risk to a Western visitor who is not accustomed to the local bacteria); (2) without education, most people don't know enough about the importance of clean water and basic sanitation, which in itself is the greatest threat to natural supplies of clean water.
Reminds me of the big chemical companies promoting pesticides in the third world thus putting entire populations and countries into debt. Supplying cheap(ish) computers is subtly different from supplying engineered toxins which solve your problem for a year or two but poison the environment so that only related products from the same supplier will allow food to grow.
If you're hungry and in a country where many people are dying of preventable illnesses, education is the greatest key to upliftment.
Most children have to forgo the opportunity of education in order to survive, because they are needed at home to contribute. This means that they don't have the time to walk 15km to and from school every day, as many children in Africa do.
A broader base of accessible computers is a means to improve this situation. It will allow literacy improvement at home for many children and adults. It will also bring knowledge on how to avoid preventable diseases, primarily through basic nutrition and sanitation.
These are areas of adult education that have been notoriously difficult to target because of a lack of resources, and the target audience being illiterate and not having the time to devote to learning.
An interactive medium like a computer does not require literacy, and can be used to teach literacy. It can also (through expert systems) substitute for a doctor or paramedic when experts are not on hand (say, 100km away on a dirt road).
The digital divide is not about people who don't have (quake|word processing|e-mail) versus those who do, it is about the failure to use modern (digital) technologies to address issues in underdeveloped countries.
Maslow's Hierarchy is a model, and as with most models it is not entirely accurate, nor is it intended to function without context. 'Surfing the net' may not feature, but security needs and social needs -- both of which are enabled through education -- are directly above physical/biological needs.