Inside Java 2 Platform Security, Architecture, API Design and Implementation 61
| Inside Java 2 Platform Security, Architecture, API Design and I | |
| author | Li Gong |
| pages | 262 |
| publisher | Addison-Wesley, 06/1999 |
| rating | 9/10 |
| reviewer | Jayakrishnan |
| ISBN | 0201310007 |
| summary | A very useful book for anyone who wants to get an in-depth knowledge of Java 2 security architecture. |
The book begins with an introduction to computer and network security fundamentals. The different types of attacks, available defense mechanisms, current security models, cryptography, authentication, etc., are introduced. Chapter 2 brings you up to date with what has been happening 'til JDK 1.1 The different components of the Java security architecture such as the byte code verifier, security manager, the restrictive sandbox, signed applets, and the strong typing, etc. are briefly described.
Chapter Three, 73 pages long, explains the inner details of JDK 1.2 security architecture that provides for flexible, extensible and fine-grained access control. The important classes and their relationships are explained. Of these classes the key methods are explored in detail.
Chapter 4 and 5 talk about deployment and customization of the security architecture. Deployment involves creating policy files and using tools like keytool, policytool, jarsigner and customization involves creating new permission types and configuring the security policy. Also here you learn about how to migrate from the JDK 1.1 based security managers to JDK 1.2 based. Certain good coding practices for writing secure Java objects form the topic of Chapter 6- --Object Security. JDK 1.2 also introduces some new classes for the same SignedObject, SealedObject and GuardedObject
The generic crypto APIs of JDK along with the Java Cryptography Extension (JCE) form the Java Cryptographic Architecture which provides platform independent cryptography APIs. Chapter 7, Programming cryptography introduces the classes of the JCE. The final chapter looks into the future. Security features that are being investigated for the future releases are discussed and since the author is also the chief Java security architect, this section resembles a trailer of what is coming.
This book is for developers who are very much interested in the inner details of the JDK 1.2 architecture and system administrators who have to configure the system security policy.
Developers will in particular enjoy the discussions where the author explains the rationale behind the design of key classes and algorithms of significant methods. We get to know what were the alternatives present, from where the ideas came, and why this particular one was chosen. For example, you need only private keys to create signatures and public keys to verify them, but then why does CodeSource deal with only certificates and not public keys?
This book is not just theory; it is also rich with examples. You will learn how to create a new Permission type, use the classes of the cryptographic package or use the tools that comes with JDK, just to name a few.
Sys Admins will benefit a lot from Chapter 4, which teaches how to configure and deploy policy files. The technical depth is one of the strong points of this book but it can be overwhelming to people who would just like to get an update on what all is new. But then you can skip the sections that get into the details and benefit a lot from the breadth of knowledge that is covered. There is also an excellent bibliography.
JDK 1.2 is feature rich. The author has done a commendable job in making all of this easy to comprehend by giving a number of real-world code examples. This book is definitely not for the newbie, but for someone who knows the language and the environment, so the book could have done without the section on how to install JDK or it would have been more appropriate in the appendix. I would recommend reading the Java Security trail (http://java.sun.com/docs/books/tutorial/security1.2/index.html) of the Java Tutorial before reading this book.
On the negative side, there are syntax errors in some of the Java code given. The keyword "class" is omitted in the definition of a class. Considering the fact that this book comes "from the source", this is a serious error.
The security model that came with the original version of Java was the very restrictive sandbox model. JDK 1.1 gave us the feature of signing applets. JDK 1.2 brings a whole lot of new features and tools which allows flexible and configurable security policies. One of the factors that hinder the adoption of new technology is complexity. Books like these, which clearly explain how to use it, will definitely make the process of using these security features a lot painless.
Finally, the author gives a tip to improve the security features on MS-Windows--- restrict all applications to be 100% Java code. Till we reach that golden era, I will stick with Robert T. Morris' three golden rules to ensure computer security: do not own a computer, do not power it on, and do not use it :)
Pick this book up at ThinkGeek.
Agreed. This Karma system is driving me insane. (Score:1)
Re:runtime compilers (Score:1)
The problem is that Java compilers actually create an interpreted bytecode format that is (allegedly) cross-platform compatible. For the most part it is, GUIs notwithstanding. Java also does garbage collection (copy collection, I believe), which would have to be compiled into the final executable. The other alternative would be conservative collection, since copy collection and the ideas of stack and heap cause issues (is it a pointer? or a value? It's all fscking bits!)
But the main problem is cross-platform compatibility. Class files can be copied from, say, a Sparc station to an Intel box and reused. However, if we had true compilers for Java, we'd have to recompile the source for each platform, or have 10 million different class files, one for each architecture.
So how you want to deal with it depends on what features of Java are most important to you.
- Y
Clumsiness of JAVA (Score:1)
Syntactically you may have a point, however, semantically, Java and C++ radically differ in certain key areas.
For starters, Java is built object-oriented from the ground up. C++ is a set of object-oriented principles grafted onto C. This causes problems with granting improper access to object innards via C low-level function calls onto C++ objects.
Secondly, Java classes can extend superclasses and implement interfaces. Java can implement many interfaces, but can only extend one superclass. In C++, multiple inheritance is allowed. Let's say you have a C++ class M which inherits methods from both superclasses K and L, and both K and L have a method f. Which f does M implement? Java avoids this problem by only allowing class M to inherit the methods of its superclass L. If M implements interfaces J and K, M has to provide the implementation of any method f that might occur in both J and K.
Thirdly, Java doesn't have pointers. Pointers are evil. The fact that you can do arithmetic with them leads to inconsistent programming and innumerable ugly hacks. If you are designing a program that requires OOP to maintain consistency and modularity, having a low-level feature like pointers around doesn't help you ensure that your objects are fully protected. Instead, Java passes references to objects between methods, which allows the programmer to modify object contents, but not the reference itself.
Just my 2 cents (adjust for inflation).
- Y
Brilliant - moderate this up (Score:1)
Re:On Bytecode and Binaries (Score:1)
In other words, I would argue that because it's so much easier to write decoupled systems in Java it's really easy to produce a program quickly that starts out fairly sound but slow - then you can take the time to heaviliy optimize the architechture for the few parts of the system that really need it. That could even include writing some customized JNI native code to do something with some custom hardware (JNI is nicely portable to make even that relativley easy to transport across systems)
The problem you may have seen is that a lot of people do not take the final optimization step as seriously as they should, since traditionally it had to be done throughout the developemnt cycle to be of any use.
Bashing sun's bastardized Java. (Score:1)
the leading figure in the hall of shame of programming languages. I personally think C++ will eventually triumph over Java, or yet another victorious language will emerge.
Anyway, that's what I hope. About Java's "cool" features? Can you spell "rip-off"? Repeat after me: "Sluggish". Very good, now try this: "Special Purpose". Oh, you think it's a general purpose programming language. Well, I suggest you look no further than C for that.
Pragmatics. Use. Remember? How many programs in your system are pure C code? Well, how many java? See? How many elisp? And Java's security model. God, I think I should stop and applaud crying. This Java is almost an OS, but a bit *slow* though... Boring
Re:Not for newbies; what is? (slightly OT) (Score:1)
Re:Not for newbies; what is? (slightly OT) (Score:1)
You might also invest in a reference like O'Reilly's Java in a Nutshell; if you're comfortable reading on the computer, there's a CD version that includes the contents of several other Java books.
Also be sure to look over the downloadable references provided by Sun.
Re:Not for newbies; what is? (Score:1)
You might like to get Java Foundation Classes and Java Examples in a nutshell.
Mind you I am a nutshell fan with 7 different titles on my desk....
Re:Not for newbies; what is? (slightly OT) (Score:1)
:-)
Other speed concerns/solutions. (Score:1)
I was very happy recently to pick up a copy of java 2 performance and idiom guide by Craig Larman and Rhett Guthrie (fatbrain [fatbrain.com]) . The book is aimed at:
Note the word design. If you want your application to work fast in a particular language then you have to design your structure in a way that optimises the strengths of the language. Java has garbage collection which is great and makes your life easier but if you create loads of objects, your program will run like a pig. Yes java has (virtually) invisible network communications over RMI but be aware of the overload of serialising all your objects, and the creation of a new thread for handling each function call and therefore use large-grained remote communication. And so on and so on. If you start your code design with the target language in mind, then unless you are doing either very low level or very computationally intensive operations then java gives fine performance (and yes I know that swing is a bit of a problem...)As such I would highly recommend this book to anyone who is interested in writing large, stable and fast applications while being aware of the design choices that they are making.
Re:Not for newbies; what is? (slightly OT) (Score:1)
On Bytecode and Binaries (Score:1)
Java by itself is a cool language, with lots of nifty features like auto garbage collection that I really love. Unfortunately though, until the folks at Sun realize that they should sell Java as a cool language, and not by preaching about changing "computing as we know it", will Java be adopted wholesale commercially.
Don't look if you don't want to know. (Score:1)
Yes. (Score:1)
Re:Don't look if you don't want to know. (Score:1)
An exercise for the reader ... (Score:1)
Re:runtime compilers (Score:1)
Because Java was intended to be 100% object-oriented, with full encapsulation and data hiding.
Remember, right tool for the right job. You may be able to create any program with a few simple structures and nothing else, but I warrant the guy who comes after you will find it nigh impossible to maintain it. Good object-oriented design can enhance productivity.
Java, unlike C++, only has one paradigm- object-oriented. It forces you to follow certain rules which serve greater ends.
-cwk.
Re:Not for newbies; what is? (slightly OT) (Score:1)
Re:runtime compilers (Score:1)
runtime compilers (Score:1)
Fast java compiler (Score:1)
Jikes [ibm.com] from IBM [ibm.com] is a darned fast one. It also has more meaningful error messages than the javac program.
Re:runtime compilers (Score:1)
NT runs like a sleepy one-legged hog, but the latest java vm's run rather well. Apart from gc which occasionally stops everything it almost rivals native code if you throw enought (256) ram at it.
Re:Not for newbies; what is? (slightly OT) (Score:1)
Re:Not for newbies; what is? (Score:1)
Oreilly also publishes a book of examples designed to go along with Java in a Nutshell, as well as two other companion books, The Java Foundation Classes in a Nutshell (which covers awt/swing, etc.) and Java Enterprise in a Nutshell (which covers servlets, and well, the title is self-explanitory).
I had to put in a plug, they're great books!
Re:Not for newbies; what is? (Score:1)
I second that. Java in a Nutshell is not only the best book on Java that I've seen, but one of the best programming references I've seen.
But Java in a Nutshell is a reference. So if you're new to OOP, I wouldn't start with that. Maybe Core Java, by Horstmann and Cornell?
Re:runtime compilers (Score:1)
Interesting that the entire universe is Win or Linux. Java is in serious use on enterprise class servers as of today. When all the major database vendors bend over themselves to include support for a technology in their platform, it's a little more important than animation.
Re:Really ??? (Score:1)
I've said it before and I'll say it again: don't compare Java to C/C++; it's an entirely different language, suited to different purposes, dispite it's similarity to C/C++ in syntax. Every language has it's strengths and weaknesses; a good programmer should know many different languages and pick the tool that is most appropriate for the task at hand.
Let's assume, for sake of argument, that application X runs 5x faster in C++ than it does in Java. (BTW, are these real numbers you are quoting, or just an approximation derived by rectal extraction?) Run time is not the only issue in software development, and even then it is not always significant -- would a user notice the difference between a program that runs in 10 ms and one that runs in 2 ms? If you are doing a database query, for example, the performance bottleneck is not the code running on the client machine, but the datbase server and/or network bandwidth. CPU-intensive applications are only a small subset of all programming tasks, and are pretty much the only class of programs where Java's performance hit is really noticable.
While programs written in C/C++ (or assembly or Fortan, for that matter) have arguably better run-time performance than the same program written in Java, there are other factors to consider. Java code is far easier to write and maintain than other languages. While Java's garbage collection facilities impose a run-time penalty, they save the programmer a huge amount of time chasing down memory leaks. Java lets you spend more time concentrating on program logic, rather than fighting with language-imposed wierdness, which is often far more important than a few millisecond's improvement in run time speed. It's often far more desireable to deliver a program having a 5 second response time in 1 day than it is to deliver a program in 5 days that has a 1 second response time.
Also, keep in mind that C/C++ code is automatically faster/better than Java. Would you really argue that an ActiveX component written in C++ is superior to an equivalent JavaBean component? Bad C/C++ code can be as slow or slower than Java code; and it's far easier to write bad C code than it is to write bad Java code. And when you compare Java to 4GL's like VB and PowerBuilder (a much more appropriate comparison than C/C++) the performance argument goes right out the window.
Java gives up some of the power and flexability of C/C++ in favor of ease of programability and maintenance. This is a very favorable trade-off for a great many types of applications.
"The axiom 'An honest man has nothing to fear from the police'
Re:runtime compilers (Score:1)
Actually, high-level language constucts like for..next, do..while, and if..then..else are all abstractions of GOTO. At the machine language level, you don't have these constructs; you only have a set of conditional jump operators like "Jump if Not Equal" or "Jump if greater than". Structured procedural 3GL's like C, Fortan, etc were created because it's hard to write good, maintainable programs in an unstructured language like Assembly. OOP languages like Java add a further layer of abstraction, allowing the programmer to spend more time concentrating on the problem instead of the language. Yes, I know C++ is Object-Oriented; however, most real-world C++ programs use a mish-mosh of procedural and OO code, making them a nightmare to debug and maintain. A "Pure" OOP language like Java forces you to do everything using objects, which makes it much easier to design, write, and maintain.
"The axiom 'An honest man has nothing to fear from the police'
Not for newbies; what is? (slightly OT) (Score:1)
This book was specifically mentioned not to be for newbies. When I go to the bookstore, there is an entire rack of java beginner's guides, and it makes my eyes cross. Is there any one book for java newbies that someone would care to recommend?
the inquisitor
JAVA's real future may be as universal bytecode (Score:1)
Speed and cross-platform compatibility are necessarily opposed.
IMHO JAVA is rather a poor language, with many niggling and unnecessarily clumsy constructs. It is too similar to C/C++.
However, I think the universal bytecode it supplies may be its real future. There are a number of compilers which take source code in other OO languages and generate JAVA bytecode: for example, AppletMagic [inmet.com] (for ADA), IBM's NetRexx [multitask.com.au], and a version of Python [jpython.org].
I've used NetRexx, though I've no expertise in the others. I found it far easier to write simple stuff, and no harder to write complex stuff, in NetRexx.
I agree that "run everywhere" has failed. But "one universal bytecode" may be the language's future. Five years from now we may see JAVA largely a server-side language. Classes in JAVA bytecode will be created using compilers that take JAVA, ADA, PYTHON, RUBY, LISP . . . you name it. If these classes are applets, they will be served out to browsers in JAVA bytecode form. The majority of these classes, however, will run as servlets or JSP's. They will be recompiled to the server's native code (the native code compiler takes the JAVA bytecode as input) and will run at high speed.
Qualifier: I have on;lytheoretical knowledge of PYTHON or LISP - it may be that the internal logic of these languages forbids or handicaps translation to JAVA in the ways I have sketched out.... Enlighten me .....
A long time ago.... (Score:2)
Ben: "I was once a troll the same as your brother."
Luke: "My brother didn't troll. He was a Linux zealot."
Ben: "That's what Signal 11 told you. He didn't hold with your brother's ideals. He thought he should post pro-Linux FUD. Not gotten involved."
Luke: "I wish I had known him."
Ben: "He was a cunning troller, and the best flamebaiter on the Internet. I understand you've become quite a troll yourself. And he was a good friend. For over 3 years the trolls made Slashdot worth reading. Before the dark times. Before the moderation"
Luke: "How did my brother die?"
Ben: "A young troller named CmdrTaco, who turned to evil, helped Rob Malda moderate Slashdot. He permanently banned your father's IP Address. Taco was seduced by the Dark Side of the Karma."
Luke: "The Karma?"
Ben: "Yes, the Karma is what gives a Karma-Whore his power. It's an energy field created by repeating pro-Linux FUD. It surrounds us. Penetrates us. Binds Slashdot together. Which reminds me. Your brother wanted you to have this when you were old enough, but Signal 11 wouldn't allow it. He thought you'd follow Anonymous Coward on a FIRST POST."
Luke: "What is it?"
Ben: "It a bowl of hot grits. The weapon of a troll. Not as random or clumsy as a petrified Natalie Portman or a Scooby Doo. An elegant topic for a more trollish First Post."
bookpool.com (Score:2)
$26.95
unhealable deep cut discounts!
Really ??? (Score:2)
just believe the marketing gunk ?
Its hard to believe this - there are a *lot* of reasons why java is much slower than C/C++ let alone fortran - I've been using java off and on for 5 years. The fastest I've seen is jit for ibm jdk1.1.8 on NT which is about 5x slower than C++ equivalent.
Re:Really ??? (Score:2)
The performance numbers came from my own testing, but a similar conclusion is available online:
http://sprout.stanford.edu/uli/java_cpp.html
Why on earth do you think Java is closer to VB than C++ ? That's hardly a complement, and not really fair on Java. You can compile Java as C++ after minor mechanical translations (although you can't link it or run it that easily, since recreating JRE would take some work...). If you mean for RAD capabilities, it's the tool that matters - the language is not really the issue.
As for development time, it depends what you're doing . Some tasks can be done faster in Java, some faster in perl, some faster in C++. If you really want to get me ranting about Java, email me.
Re:Not for newbies; what is? (slightly OT) (Score:2)
K-rich posters should have default at 1, pick 2 (Score:2)
That way, the poster would have to think a little if his/her post deserves a score of two. As it is, it's all too easy to just post and forget to check the box to stop it posting at a higher score...
I'll leave this post at a score of two assuming that it's a good enough idea that it deserves it. I often have posted at a score of 1 though, I try and make sure I have something really interesting to say before I mark it as 2 to start with.
P.S. - sorry for vilating the Strunk and White rules of "one" vs. "1" but it really seemed to look better in this case.
Re:Not for newbies; what is? (slightly OT) (Score:2)
I learned Java with the JDK 1.1, and found two books pretty helpful. I already had been programming in other languages including C/C++ for a while, and these books helped to learn the language. Neither would be a good choice if you also needed to learn how to program at the same time.
The certification guide has an updated version for 1.2 that I haven't read. I was also warned by people who had taken the exam that the book by Boone, "Java 1.1 Certification Exam Guide for Programmers and Developers" is one to stay away from. Apparently it is just filled with errors. (There may be an updated version that is better, but I have no intentions of buying it, so I don't know.)
I know what you mean by being overwhelmed when you go to the bookstore. There are a lot of Java books available, and most are pure garbage. For the more specific Java topics the ORA [ora.com] books are pretty good, but I think that the Addison Wesley [awl.com] books are just a bit better.
Re:runtime compilers (Score:2)
Um, no. It's being used by Fortune 500 companies for serious business applications.
on-line versions (Score:2)
The book is not only available in printed form, but Bruce Eckel has a web site [eckelobjects.com] on the book and related subjects, including the full text in both html (downloadable zip [codeguru.com] or browsable [developer.com]) and indexed pdf [codecuts.com] format. However, it's not small and I would recommend going for the paper version if you like it.
Re:Not for newbies; what is? (slightly OT) (Score:2)
Re:runtime compilers (Score:2)
The official site is the Java section of sourceware [cygnus.com], and there is a recent news update. It compiles source or class files to native code, and the CNI interface is basically C++ calling; so it's set up to be fast, and in fact has been fast, on the software I've managed to get running there.
Briefly, it's bleeding edge; one looks forward to the next GCC release. I don't know how the very latest snapshots go, but it's been ages since I've gotten one that even compiles smoothly (on Redhat 6.0, very standard).
Significant missing features include the ability to parse JDK 1.1 "inner classes" from Java source. It's coming, but not there yet, and the workaround is just to use a JDK compiler and compile from classfiles.
And as for applying this particular signed code architecture (the one in the book, remember what the alleged topic of this thread is? :-) ... it's a ways off, I'd say. Clearly there'll be some good potential for open source hacking there, both to get the crypto parts going (let's really bang on that new BigInteger code!) and to make sure all the other parts of the runtime interact appropriately. Hard work.
Re:Don't look if you don't want to know. (Score:2)
Doh! Ouch! Well the roughly $1,000 liscencing fees were the first thing that threw me. Second ther dosn't appear to be a linux version. Does it work under WINE?
Re:runtime compilers (Score:2)
collection are the strength of languages like java. If you're serious about implementing an object oriented structure, then you really need a language with
these things. Java is more like what the next generation languages will be, allowing you to talk more about meta-objects and sealing off the lower levels of
code. However, what is needed for this is a quality compiler that optomizes your code. Lets try to make java more like perl or python, eliminating the large
amounts of time spent on memory management.
What I really want is having the ability to just take say a program that displays "hello, world" and displays it to the screen to be easily run on the console command line of a linux machine. I can do that with c++.
What I really would like to know is why all the objectness?
I have done some studying and in general any program can be created from:
for
do/while
while
if
Take the use of functions and you have a superb method of creating programs. Also add recursion and you have very nice programs. It seems like all the "object oriented" nature of languages appears to be of little practal use. Except to save perhaps a couple of minutes.
Re:runtime compilers (Score:2)
The obvious things yes I would have to agree with that. Look at all the major linux applications out there little is being done in java regardless of how "good" it is. C/C++ are the languages of choice along with perl/python. I don't think there are any major programs that are written in java ther most average people use everyday (staple apps) that are actually java based on linux distributions. For that matter most of the things I use on windows platforms are not java based either.
Except on Windows NT, Java is slow. It's not open source, either. Interpreted languages that ARE open source generally kick it in the butt performance-wise, are easier to code, and are 100% portable.
I can't see NT as being fast at anything unless it's fast to anger the user.
Call me back when they figure out something for Java that's actually cool.
Dr. Dobbs has a number of what many would consider "cool" things with java. I have seen several games for java but nothing that has hit mainstream. Generally this is due to a lack of speed and bloat to the code. That may change however when we are all running processors 10x faster than now we might get 4% speed increase.
Re:runtime compilers (Score:2)
some breakthroughs with runtime compilers for it speed will be a nonissue.
Isn't there a simple way to just run java executables? I shure would like to actually be able to learn and use java without needing to get some fancy smansy memory intensive, disk space clogging mess. What about the gnu java compiler: gcj? Can I just run output from said java app with say standard libc stuff?
I think more likely is that computers will just end up speeding up to cover up inefficient implimentations of the language and perhaps poor programming. Hey look what fast computers did for windows.
Re:An exercise for the reader ... (Score:2)
And that is?
Re:Not for newbies; what is? (Score:2)
MODERATE THIS TROLL DOWN (Score:2)
No, five years later, it's the the most popular server-side development language for the web (counting new systems).
Except on Windows NT, Java is slow. ... Interpreted languages that ARE open source generally kick it in the butt performance-wise, are easier to code, and are 100% portable.
Java is faster on several other platforms, notably OS/2 and now Linux as well. Java with a JIT compiler compares favorably in speed to Perl and Python. What other language is 100% portable? Not Perl. Gimme a break.
Call me back when they figure out something for Java that's actually cool.
How will you hear the phone if your head is wedged so deeply in your ass?