"Krakatoa--East of Java"
An excellent Rant in which our Titular Leader, Tim May, sings the praises of Java and denounces an evil sect of Crypto Separatists, the self-described "Coderpunks."
Well, I was not invited to join the elite and secret coderpunks list, but I still have some thoughts on coding and, especially, on the opportunities offered by Java. Sorry if this interferes with discussions of Rabbi Heir and Morris Dees.
Given the various parameters which determine the life and death of mailing lists, I fully expect Coderpunks to become moribund within six months, and its members to reunify with this list. Very few of these "I'm going to start my own list with less noise" adventures ever make it long term, absent the personalities and critical mass of interesting information which drove the list they spun off from.
1. Java is of course not a perfect language, nor even the best for specific applications. Other languages will continue to thrive. Critics of the language and related items (applet model, JDK, JITs, etc.) may point to various problems (e.g. security).
2. However, the "big picture" is compelling. Java arrives at a time when a Babel of languages and platforms threatens interoperability. C++ is despised by many (though, to be fair, liked by many, too), and developers are adopting Visual Basic (and the vbx widgets, etc.), PowerBuilder, Delphi, flavors of Smalltalk (no pun intended), and scripting languages (Perl, TCL, Python, etc.).
I completely agree with this. Java incorporates the type of automatic corruption-proof memory management found in languages like APL, the basic notions of object oriented programming, fast dynamic linking, and a C-like program structure. This is powerful combination of features and gives Java the potential to do all the platform-independent things that were advertised for C before the rude reality of thousand line makefiles reared its ugly head. . The complete specification of the Java Virtual Machine means that the behavior of Java programs is perfectly well-defined, and one does not have to tweek anything which is processor or operating system dependent. In the future, I expect Java bytecode to become a significant channel for the distribution of popular applications, with compilation to fast native code on numerous platforms. Java is clean, and its concepts are easily understandable even by persons whose eyes glaze over after the first 30 pages of the C++ manual.
4. What is so compelling, to me, is that Java programs have an excellent chance of running on various flavors of Unix, on Windows-95 and NT systems, on Macs, and on other systems without changes, and without any special compilers bought by the users! (Netscape browsers, and even Microsoft browsers, are able to view applets, or soon will be. And cheap or free applet viewers are available.)
Expect NT to be a Unix-killer in the future. It can be ported to any machine, and its microkernel client-server design with pluggable third-party APIs permits it to manifest simultaneously the personalities of numerous different operating systems. Contrast this with the many different binary incompatible Unix flavors and its marketing advantage becomes clear. NT sales just broke one billion per year and are climbing steadily. NT and Java will be the big players in the future. If Netscape becomes its own OS, requiring no Microsoft software, it will probably capture the low-end "Web TV" market.
6. One can imagine several applets of interest to Cypherpunks. The ability to fairly transparently run them on multiple platforms, effectively bypassing the platform dependencies, is very important. Check out Hal Finney's site for some "crytographic primitive" applets he's written.
Indeed. One can imagine a nice set of Java classes and methods which interoperates with PGP, and has none of the fixed buffer allocation, limits, and awkward memory management present in PGP. Java tends to do the kinds of things PGP does very cleanly, and implementors can worry about the algorithms without being distracted by housekeeping. Any code produced can instantly be used by others in their applications. This is a powerful paradigm, encourages others to expand on existing work, and renders kludges like "PGPTools" unnecessary.
10. "Mindshare" is the real story. Java arrives at the right time. Cypherpunks needs--those needs that go beyond just the "sealed envelopes and signatures" level which PGP provides so well--are likely to fit in with this Net-centric communications model. (I'm already thinking in terms of Java applets for building blocks for Cypherpunk sorts of things.)
Java Applets, mobile crypto agents, and the new Web-centric view of cyberspace will go a long way towards encouraging the planet-wide use of strong crypto, as well as effectively swatting annoying mosquitos like ITAR. Indeed, with Java, I can put up a Web page which teaches someone about a cryptographic algorithm, allows him to try it out and run sample data through it, and provides him with a platform-independent implementation of it to use as he wishes. All in one fell swoop. That's a pretty powerful concept. Java has come at the right time, and it will produce chaotic change in the existing order. Should be interesting. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd@netcom.com $ via Finger. $
On Thu, 25 Apr 1996, Mike Duvos wrote:
Given the various parameters which determine the life and death of mailing lists, I fully expect Coderpunks to become moribund within six months, and its members to reunify with this list.
Very few of these "I'm going to start my own list with less noise" adventures ever make it long term, absent the personalities and critical mass of interesting information which drove the list they spun off from.
In this case, I hope not. There are people (not myself) who only want the coding-related material arriving in their mailboxes. Coderpunks serves that need. I think that particular list is more of a filter than a separate list. If you look at the archives (if they come back up) you'll see a few crypto bigwigs on coderpunks that haven't seen fit to post to cypherpunks in a very long time, if ever. It'd be nice to keep receiving their input without forcing them into tedious killfiling measures. Conversely, I don't see why the activists should have to deal with code. The main list, imho, has mostly become something of a watering hole for the primary crypto user community. Something quite different from the usenet crypto groups. And since the list is very active regardless of signal, it will still be a place to send out some signal on those occasions where the important thngs occur. They don't (and can't) every day. And usenet just doesn't perform this function properly. I really do think having archives alongside a cypherpunks archive is crucial for the survival of an offshoot list. Institutional memory is very useful, especially for time-insensitive things like technical discussions. If hks decides not to bring back the archives, I hope they tell us promptly and temporarily put the whole thing up for ftp so someone else can provide this valuable service. (Kudos to hks and Todd for having given to us up till now.) It's safe for you to unsubscribe now, Perry.
Mike Duvos writes:
1. Java is of course not a perfect language, nor even the best for specific applications. Other languages will continue to thrive. Critics of the language and related items (applet model, JDK, JITs, etc.) may point to various problems (e.g. security).
2. However, the "big picture" is compelling. Java arrives at a time when a Babel of languages and platforms threatens interoperability. C++ is despised by many (though, to be fair, liked by many, too), and developers are adopting Visual Basic (and the vbx widgets, etc.), PowerBuilder, Delphi, flavors of Smalltalk (no pun intended), and scripting languages (Perl, TCL, Python, etc.).
I completely agree with this. Java incorporates the type of automatic corruption-proof memory management found in languages like APL, the basic notions of object oriented programming, fast dynamic linking, and a C-like program structure.
This is powerful combination of features and gives Java the potential to do all the platform-independent things that were advertised for C before the rude reality of thousand line makefiles reared its ugly head. . The complete specification of the Java Virtual Machine means that the behavior of Java programs is perfectly well-defined, and one does not have to tweek anything which is processor or operating system dependent.
Unfortunately, this last statement isn't really true. To quote from the "Java Security" paper from some Princeton researchers: The Java language has neighter a formal semantics nor a formal description of its type system. We do not know what a Java program means, in any formal sense, so we cannot reason formally about Java and the security properties of the Java libraries written in Java. Java lacks a formal description of its type system, yet the security of Java relies on the soundness of its type system. And later: The Java bytecode is where the security properties must ultimately be verified . . . . Unfortunately, it is rather difficult to verify the bytecode. . . . The present type verifier cannot be proven correct, because there is not a formal description of the type system. Object-oriented type systems are a current research topic; it seems unwise for the system's security to rely on such a mechanism without a strong theoretical foundation. It is not certain that an informally specified system as large and complicated as Java bytecode is consistent. And in the conclusions: We conclude that the Java system in its current form cannot easily be made secure. Significant redesign of the language, the bytecode format, and the runtime system appear to be necessary steps toward building a higher-assurance system. . . . Execution of remotely- loaded code is a relatively new phenomenon, and more work is required to make it safe. I do think that the ideas embodied in Java are very important, and will significantly shape the future of computing, but Java itself may be just a stepping stone on the way.
Scott Brickner writes:
Unfortunately, this last statement isn't really true. To quote from the "Java Security" paper from some Princeton researchers:
The Java language has neighter a formal semantics nor a formal description of its type system. We do not know what a Java program means, in any formal sense, so we cannot reason formally about Java and the security properties of the Java libraries written in Java. Java lacks a formal description of its type system, yet the security of Java relies on the soundness of its type system.
I will point out that complete formal semantics exist for other, perfectly practical to use languages, like Scheme.
We conclude that the Java system in its current form cannot easily be made secure. Significant redesign of the language, the bytecode format, and the runtime system appear to be necessary steps toward building a higher-assurance system. . . . Execution of remotely- loaded code is a relatively new phenomenon, and more work is required to make it safe.
I do think that the ideas embodied in Java are very important, and will significantly shape the future of computing, but Java itself may be just a stepping stone on the way.
I go further. Java, as envisioned, cannot be made secure. It is too powerful a language. Furthermore, it is unnecessary for the tasks that it is used for, which are basically adding fancy wacky graphics and simple applications and such to web pages. Perry
I go further. Java, as envisioned, cannot be made secure. It is too powerful a language. Furthermore, it is unnecessary for the tasks that it is used for, which are basically adding fancy wacky graphics and simple applications and such to web pages.
Even though that is all it is used for now, I think it was *intended* to be used for more. -- Sameer Parekh Voice: 510-601-9777x3 Community ConneXion, Inc. FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.net/ (or login as "guest") sameer@c2.net
On Fri, 26 Apr 1996 sameer@c2.org wrote:
I go further. Java, as envisioned, cannot be made secure. It is too powerful a language. Furthermore, it is unnecessary for the tasks that
Even though that is all it is used for now, I think it was *intended* to be used for more.
At Usenix 96 in San Diego it was pointed out that applets are an abberation. This is a complete language designed to displace C++, Visual Basic and other OO languages. Thinking of Java as simpy a Web enhancement tool is short sighted. Personally it is more attractive than C++ for product development and we are trying to get it on FreeBSD, SCO UnixWare and SCO OSR5. Using Java for applets _only_ is like fucking your mother... Most of us are not into it. Dan -- Dan Busarow DPC Systems Dana Point, California
"Dan" == Dan Busarow <dan@dpcsys.com> writes:
Dan> At Usenix 96 in San Diego it was pointed out that applets are Dan> an abberation. This is a complete language designed to Dan> displace C++, Visual Basic and other OO languages. Thinking Dan> of Java as simpy a Web enhancement tool is short sighted. Dan> Personally it is more attractive than C++ for product Dan> development and we are trying to get it on FreeBSD, SCO Dan> UnixWare and SCO OSR5. Using Java for applets _only_ is like Dan> @#$% your mother... Most of us are not into it. I have been doing work in Java for the past half a year or so (most recent project: implementing SSL 3.0). I can't say I don't like it at all, but I like C++ much more. Here are my thoughts about the issue. Since there is a subjective component to choosing a programming language, flamewars are very likely to erupt when you say "Language A is much better than Language B", but it may still be interesting to read others' opinions. As I see it, Java as a language is basically (C++) + (garbage collection) - (templates) - (operator overloading) - (multiple inheritance) - ... Garbage collection is a very useful thing in many cases (though in some it may be a great slowdown), but there is no real reason not to incorporate GC into a C++ implementation, or at least give the user an option of doing it. On the other hand, templates are an extremely useful feature, since they allow huge amounts of code reuse (Wei Dai's crypto++ library is a great example of the use of templates). They also enable a C++ programmer to do such things as run-time array boundary checking (refuting one of the traditional arguments about the dangers of C++), or a type which is a subrange of another. Java programs can have some template-like functionality through the use of the Object class, but that is very limited. For instance, compare the following hypothetical Java code List l; l.append(new Integer(1)); l.append(new Integer(2)); int x = ((Integer)(l.head())).intValue(); with this C++ List<int> l; l.append(1); l.append(2); int x = l.head(); The second version is clearly more readable. It would also be more efficient since no run-time conversions would be done. There are also situations in which templates would work, but Objects would not. For instance, it is very easy in C++ to make a template class Range<type, min, max> that would be a subrange [min, max] of type, and would do run-time checks for any assignments. There is no way you can do this in Java. Java also lacks operator overloading. 'V = M*W + A' (where V, W, and A are vectors, and M is a matrix) is much easier to read than 'V = Vector.add(Matrix.multiply(M, W), A)'. The same would apply to a big integer class. The lack of multiple inheritance is somewhat alleviated with the use of interfaces, but there are cases where this is not enough. The crypto++ library uses a lot of nontrivial multiple inheritance. Another strange deficiency of Java is that there is only one way to pass parameters. All class parameters are passed by reference, while all primitive-type parameters are passed by value. What if you need to pass an integer by reference? Also, when you pass a class parameter, the method can modify it arbitrarily, since Java does not allow constant variables. As for the usual complaint "C++ has pointers which are unsafe!!!", the following can be said. First, Java has pointers too: all class objects are actually pointers to data, so, for instance, "A = B" in Java would mean "Make A a pointer to the same location as B", not the traditional meaning "Make A a copy of B". Second, when it is said that C++ pointers are unsafe, usually two things are meant: C++ allows you to cast a pointer of one type to a pointer of another type, and C++ allows for pointer arithmetic. Both of these features are not needed in virtually all programs (they were probably retained only for C compatibility), except those that interface with the low-level system calls. Also, both of them can only be invoked explicitly. Thus, the programmer which uses them has only himself to blame if anything goes wrong. In summary, I don't see Java as the new great language that is going to replace C++ in the standalone application arena, even if Java ran as fast as C++. It is true that Java has a nice standard library (including threads), but there is no reason whatsoever why a library with a very similar interface could not be written in C++. On the other hand, considering Java as a language specifically for applets is a completely different matter. Here it does not compete with C++. The competitors -- Safe-Perl, Python, and Safe-TCL (and perhaps some Scheme-like languages) -- don't stand a chance without being supported by Netscape. Thus I would say that Java became so popular for the following reasons: - It was developed by Sun. - It was licensed by Netscape. - It is C++ -like. - JDK (and its source) were made freely available. Constructive comments and discussion of this issue would be appreciated, but send the flames to /dev/null. Sincerely, Victor Boyko -- Victor Boyko <vboykod@is-2.nyu.edu> http://galt.cs.nyu.edu/students/vb1890/ To get my PGP key, finger or send e-mail with subject "send pgp key".
On Fri, 3 May 1996, Victor Boyko wrote:
I have been doing work in Java for the past half a year or so (most recent project: implementing SSL 3.0). I can't say I don't like it at all, but I like C++ much more. Here are my thoughts about the issue. Since there is a subjective component to choosing a programming language, flamewars are very likely to erupt when you say "Language A is much better than Language B", but it may still be interesting to read others' opinions.
I agree completely with Victor's analysis. I usually try to avoid me-too posts, but I've been meaning to write an explanation of why I haven't started using Java and am not planning to port my Crypto++ library to Java, so this saves me the effort. Wei Dai
sameer@c2.org writes:
I go further. Java, as envisioned, cannot be made secure. It is too powerful a language. Furthermore, it is unnecessary for the tasks that it is used for, which are basically adding fancy wacky graphics and simple applications and such to web pages.
Even though that is all it is used for now, I think it was *intended* to be used for more.
True. It's still lacking a couple of (non-language) features. The most important (and most cpunks relevant) is a mechanism to pay people to run programs for you. This sort of thing is dangerous without a safe environment. If it was safe to do so, I can see about two hundred PowerPC systems from where I sit that are idle 90% or more. As more users become permanently connected to the net (cable modems and such), there will be *millions* of computers with a little processing power each that are available for distributed tasks. The next generation of "Toy Story" just might be done in near real- time.
Scott Brickner writes:
True. It's still lacking a couple of (non-language) features. The most important (and most cpunks relevant) is a mechanism to pay people to run programs for you. This sort of thing is dangerous without a safe environment.
You can do that safely without making it dangerous for your machine. I know how I would build a restricted execution environment for such markets. However, Java is 1) too slow, since if you are selling rendering cycles or such you don't want to be running an interpreter, 2) insufficently safe, and 3) paradoxically, insufficiently powerful for the sort of code you would want to run in such an environment. Perry
Perry writes: You can do that safely without making it dangerous for your machine. I know how I would build a restricted execution environment for such markets. However, Java is 1) too slow, since if you are selling rendering cycles or such you don't want to be running an interpreter, 2) insufficently safe, and 3) paradoxically, insufficiently powerful for the sort of code you would want to run in such an environment. What solution is fast enough and safe enough and powerful enough? Does such a solution exist? I say, No, it doesn't. So let's quit pretending that the Holy Grail exists, and get back to engineering. But let's not have a food fight. Although entertaining in the short term, food fights are actually deathly boring and incredibly unfruitful in the long term. I'm interested in helping people do interesting things in a reasonably secure way, on the internet, using Java. We're working on a response to the Felten el al. paper, which will be posted to the net shortly. I think some of their points are perfectly valid, some of their points are irrelevant, and a lot of the presentation is melodramatic. Melodrama is good for sound bites, I guess. Marianne working on Java security stuff at Sun
Marianne Mueller writes:
Perry writes:
You can do that safely without making it dangerous for your machine. I know how I would build a restricted execution environment for such markets. However, Java is 1) too slow, since if you are selling rendering cycles or such you don't want to be running an interpreter, 2) insufficently safe, and 3) paradoxically, insufficiently powerful for the sort of code you would want to run in such an environment.
What solution is fast enough and safe enough and powerful enough? Does such a solution exist? I say, No, it doesn't.
I say yes, it does. If what you want to do is run a distributed ray tracer, and sell the cycles for it, you can run an ordinary executable on a machine with an unusual kernel. If, for example, you could completely revoke access to the bulk of system calls and only permit I/O to a small number of inherited file descriptors, you could probably manage to get a reasonable engineering solution in place that would be suitable solely for things like markets in CPU cycles. I could probably design such an execution environment in a few weeks. Such an execution environment radically differs from Java in so far as it has a "what is not expressly permitted is forbidden" strategy all the way down to the kernel interface. It might still be dangerous in the presence of things like kernel bugs that permit you to write arbitrary memory addresses, however. My suspicion is that something thats okay from an engineering standpoint should be possible.
But let's not have a food fight. Although entertaining in the short term, food fights are actually deathly boring and incredibly unfruitful in the long term. I'm interested in helping people do interesting things in a reasonably secure way, on the internet, using Java.
What you are saying, Marianne, is that you work for the Java group at Sun, Java has become very important to Sun's strategy, and that thus Java isn't going to be abandoned regardless of techincal problems.
We're working on a response to the Felten el al. paper, which will be posted to the net shortly. I think some of their points are perfectly valid, some of their points are irrelevant, and a lot of the presentation is melodramatic. Melodrama is good for sound bites, I guess.
Look, not to be insulting, but your job pretty much dictates that you have no choice but to declare their work to be incorrect. I mean, your customers would be very mad for you to say otherwise, and your management would fire you if you didn't say otherwise. This must certainly color your commentary. Understand, I'm not accusing you of being a bad person, but I am noting that you aren't in a position to be objective. Perry
I guess you're opting for food fight? I'll let people who know me judge if they think I'm mouthing party line or what not .. :-) Marianne
Marianne Mueller writes:
I guess you're opting for food fight?
I'll let people who know me judge if they think I'm mouthing party line or what not ..
As I said, I don't think you are a bad person. I merely think that no one could expect the Java security person to say anything other than what you have said. .pm
From the begining of the Java discussion on this list, Perry has been
predicting that a continuous series of security holes would be discovered in Java implementations. So far he's been proven right. I like Java -- I'm not a professional programmer, and Java is a lot easier for me to work with than C++. And I can buy the argument that for many people the benefits of applets will outweigh the security risks. I'm willing to run sendmail, and I'm willing to run Java as well. I'm not working in a finance house, and there's not anything that sensitive on my machine. It also seems likely to me that Java secure mail applets and remailer clients will do a lot of good from a cypherpunk point of view. Java looks like it's going to put easy to use gui crypto tools within reach of everyone with a web browser. So I'd like to see Java catch on, as long as users are allowed to make informed decisions about the risks and the benefits of running applets. But Perry has a track record on this issue (and on many other issues as well). I don't think many people here are going dismiss what he's saying because someone called him a food fighter.
Alex Strasheim <cp@proust.suba.com> writes:
I like Java -- I'm not a professional programmer, and Java is a lot easier for me to work with than C++. And I can buy the argument that for many people the benefits of applets will outweigh the security risks.
I hope everyone here realizes that Java is not just about Applets. Applets are simply one of many abstract classes in Java, suitable for further refinement into things that get plugged into Web pages. Java itself is a full-blown programming language, like C or C++, with command line processing conventions, runtime libraries, and all the other amenities of procedure-oriented programming languages. You can write anything you want in Java, and execute the program at a shell prompt by simply typing its name followed by some arguments. (Perhaps you might have to alias "name" to "java name", but you get the general idea) While the security issues being discussed are indeed important for Applets, where untrusted code from God-knows-where comes into intimate contact with the program visible decor of ones platform, they are less important when Java is used as an ordinary programming language, in order to take advantage of its platform-independence and incorruptable run-time structure. Again, this is not directed at Alex or anyone else specifically, but some of the messages I have read here recently have given the distinct impression that people are thinking of Java as a language solely for writing Applets, as opposed to something more general and a bullet-proof replacement for C++ and C. I think we'll be seeing a lot of things written in Java in the future. A good first start would be a set of Daemons for Unix which run on any platform and are totally immune to the buffer-overrun type holes which permit people to easily break into systems. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd@netcom.com $ via Finger. $
On Sat, 27 Apr 1996, Marianne Mueller wrote:
But let's not have a food fight. Although entertaining in the short term,
I don't owe you anything! I don't owe you anything! Oh, food fight.
reasonably secure way, on the internet, using Java. We're working on a response to the Felten el al. paper, which will be posted to the net shortly. I think some of their points are perfectly valid, some of their points are irrelevant, and a lot of the presentation is melodramatic.
Most of the emphasis in the paper seems to be on the lack of a denotational semantics for java and the java VM, and on the lack of a formally defined set of rules for type inferencing rules. For security purposes, java-the-language is not particularly important; it's the VM code that counts. This is a shame, as it's pretty easy to come up with a reasonably clean denotation for java, wheras the byte code gets pretty messy. It would probably be easier to get a cleaner semantics if you define a set of rules to transform the byte code into an alternate form and then define the denotational semantics for that. The paper mentions that the authors believe the VM to be unsuitable for a denotational semantics, but the issue is not explored to any great depth.
Melodrama is good for sound bites, I guess.
I take it twenty minutes before I go to sleep; seems to work pretty well. --- They say in online country So which side are you on boys There is no middle way Which side are you on You'll either be a Usenet man Which side are you on boys Or a thug for the CDA Which side are you on? National Union of Computer Operatives; Hackers, local 37 APL-CPIO
"Perry E. Metzger" writes:
You can do that safely without making it dangerous for your machine. I know how I would build a restricted execution environment for such markets. However, Java is 1) too slow, since if you are selling rendering cycles or such you don't want to be running an interpreter, 2) insufficently safe, and 3) paradoxically, insufficiently powerful for the sort of code you would want to run in such an environment.
The speed can be significantly addressed by compiling the byte-code to local machine instructions, but given the sheer number of junk cycles that are made available by letting a Java interpreter sell them, it doesn't much matter for some applications. I agree that Java is currently too unsafe. The current Java model may not even be salvageable (that being where I got in on this thread). It's the concept embodied by Java (and it's many conceptual cousins, Scheme, Safe-TCL, E, etc.) that I was talking about. I don't understand what you mean by "insufficiently powerful". It's as expressively powerful as most high-level languages, and computationally Turing equivalent. It's lack of power seems entirely in the performance arena, which may be solved, eventually.
Scott Brickner writes:
I don't understand what you mean by "insufficiently powerful". It's as expressively powerful as most high-level languages, and computationally Turing equivalent. It's lack of power seems entirely in the performance arena, which may be solved, eventually.
Java applications can't save files to disk or use data files on disk. If you were, for instance, buying two CPU weeks of idle time on some machines, you would need stuff like checkpointing or the ability to save intermediate results. Perry
Java applications can't save files to disk or use data files on disk.
Uh, yes they can. It's the applets that can't. -- Sameer Parekh Voice: 510-601-9777x3 Community ConneXion, Inc. FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.net/ (or login as "guest") sameer@c2.net
On Mon, 29 Apr 1996, Perry E. Metzger wrote:
Java applications can't save files to disk or use data files on disk. If you were, for instance, buying two CPU weeks of idle time on some machines, you would need stuff like checkpointing or the ability to save intermediate results.
See the documentation for FileOutputStream; unsigned java applets can't make persistent changes, but signed ones can. Applications can always access the file system Simon --- They say in online country So which side are you on boys There is no middle way Which side are you on You'll either be a Usenet man Which side are you on boys Or a thug for the CDA Which side are you on? National Union of Computer Operatives; Hackers, local 37 APL-CPIO
"Perry E. Metzger" writes:
Scott Brickner writes:
I don't understand what you mean by "insufficiently powerful". It's as expressively powerful as most high-level languages, and computationally Turing equivalent. It's lack of power seems entirely in the performance arena, which may be solved, eventually.
Java applications can't save files to disk or use data files on disk. If you were, for instance, buying two CPU weeks of idle time on some machines, you would need stuff like checkpointing or the ability to save intermediate results.
It is false that Java applications "can't" save files to disk. Java has no I/O facilities, exactly like C and C++ have none. Any I/O capability must be provided in external functions. The applet environment doesn't include file I/O functions, but it can be easily added in a reasonably safe way (filesystem object only allocates a fixed region of real disk space, applets are charged to use it, after the "rent" is gone, the blocks are freed, etc.) Java applications may also send checkpoint data or intermediate results back "home", even in the current environment.
sameer@c2.org writes:
I go further. Java, as envisioned, cannot be made secure. It is too powerful a language. Furthermore, it is unnecessary for the tasks that it is used for, which are basically adding fancy wacky graphics and simple applications and such to web pages.
Even though that is all it is used for now, I think it was *intended* to be used for more.
So much the worse. I don't think its a good idea to download random programs and run them without even realizing it, especially when they run in an execution environment which is not particularly emasculated. I don't think this can be made particularly secure in the general case. It is a bad paradigm. I've said it before, and everything we've seen thus far about Java supports my contention. Perry
participants (11)
-
Alex Strasheim -
Dan Busarow -
mpd＠netcom.com -
mrm＠netcom.com -
Perry E. Metzger -
s1113645＠tesla.cc.uottawa.ca -
sameer＠c2.org -
Scott Brickner -
Simon Spero -
Victor Boyko -
Wei Dai