Slashdot Mirror
Inside Java 2 Platform Security, Architecture, API Design and Implementation
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.
Can anyone answer this question: Before Java 2, signed applets got the same privilegies as any applicatotion. So if you wanted your applet to do something "difficult", you just had to sign it. Easy for the user. But now with Java 2, the user does also have to place .java.policy (I think it was called that) file in his home directory to allow a non trivial applet to do thing out of its sandbox. To me it seems this ruins the whole concept! If the user has to install a file he can as well install a program? Am I right???
Heheh I liked this one.
Moderate it up a bit.
This is very funny! Thanks for the laugh.
Carol Lay's latest cartoon strip (on Salon) has another reference: Nancy: Oh Nick, you're such a tool!
In the first year of Java's release, we saw it used for stock tickers, buttons, and animation. Five years later, it's still the same damn thing.
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.
Call me back when they figure out something for Java that's actually cool.
"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." You make a valid point. Object orientation is not needed to write a "hello, world" program that runs form the console. However, if that is the limit of your ambition, you should be able to satisfy it in an afternoon and move onto something else besides programming. Perhaps something that you have an aptitude for. sr
There is already a Python that compiles to Java bytecodes. However, bytecode is not an optimal universal object format, because compilation to bytecode discards information (the syntax tree) which is difficult or impossible to reconstruct at runtime. This prevents some kinds of optimization. A format like Oberon's "Slim Binaries", which preserves the entire parse tree in compressed form, does not preclude these optimizations, and can be loaded off disk and compiled to native object code faster than the equivalent object code (because it is much larger and disks are slow) could itself be loaded off disk. sr
This one did make me smile.
Bob Clip - friend of A Nony Mouse.
Hmm, you mean speed matters in a program? Does Microsoft know about this yet?
Those damn Latinians ARE pigs...
I have this book and I have found it to be very useful. Its even better than the OReilley books! Also, some of the comments posted here about Java are pretty funny. Thanks!
Look at the size of that title!
Is there any way that I can filter out all Score:2 posts that haven't been moderated? The amount of crap that gets self-bumped is rediculous. People, like "slashdot-terminal" (to pick on someone from this article), bump absolutely everything they post, even when it in no way derserves a 2. I'm starting to enjoy reading the -1 posts more and more. Certainly more interesting than Score:"me too" posts.
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?
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
"There is no culture in computer science, only cults." - M. Felleisen
IMHO JAVA is rather a poor language, with many niggling and unnecessarily clumsy constructs. It is too similar to C/C++.
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
"There is no culture in computer science, only cults." - M. Felleisen
LOL.
That can be said to be true about Java. You can also state that Java moves a lot of the time and computing cycles used to make a program run efficently to the end of a project.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
With the stinking license, non-standard. It's
:|
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
--exa--
Just Java 2 by Peter van der Linden, Sun Microsystems Press is a great book. I learned java with it.
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.
It does have the disadvantage of not having the Swing/AWT in as compare to the first two editions.
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....
:-)
The only Good System is a Sound System
I was very happy recently to pick up a copy of java 2 performance and idiom guide by Craig Larman and Rhett Guthrie (fatbrain) . 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.
The only Good System is a Sound System
If you ask me, I would say "DON'T BOTHER!" Why buy a book when there is a nice set of tutorials ont the Sun website to get you started? If you need reference, learn to read the API documentation. If you really stuck, the forum on the site is a good place to get friendly advices. 2c
Java as it's currently implemented sucks, for reasons in its runtime philosophy. The net effect of Java's cross-platform bytecode is nothing more than a shift from spending time and computing cycles on the developer side to spending them on the user side. The only way JIT compilers will ever get close to the efficiency of precompiled C or C++ binaries is by spending more and more computing resources on the compiler, and less resources actually running the program. Developers get paid to develop software, why force the user to do the work for them all in the name of "elegance" or "abstraction". If developers want their software to run on multiple platforms, they should take the time and effort to compile for those platforms.
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.
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
JOVE
threadeds blog
Yes, it works, yes it is fast, yes, you can download an evaluation copy.
threadeds blog
There is at least one java compiler than can give Fortran levels of performance.
threadeds blog
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.
Around our company we usually recommend the two-book series Horstmannn and Cornell's Core Java. It's best if you know a language like C or C++ before reading this. These books are very well-written and they don't skimp on the hard stuff. One may wish to consider glossing over the increasingly deprecated AWT material in favor of some other book on JFC and Swing, when the time comes to learn GUI stuff.
So basicly, you want java as some kind of c++ superset? That seems to be what Sun thinks too, and also what is ruining the language. Things like garbage 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.
This is really the beginning of something. Geeks have always despised Java because of speed difficulties, but its starting to actually go somewhere. It more of a "true" OO language than C++ (more like Smalltalk) and once we see some breakthroughs with runtime compilers for it speed will be a nonissue.
Surprised no one seems to have mentioned it yet...
Jikes from IBM is a darned fast one. It also has more meaningful error messages than the javac program.
Further to Fingal's post: you can get the book in electronic form for free from Bruce's website. Although you may wan't to buy it as it's rather large and well worth the money.
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!
Amazing magic tricks
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?
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'
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
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
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 (for ADA), IBM's NetRexx, and a version of Python.
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 .....
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 has it for
$26.95
unhealable deep cut discounts!
Have you actually used this puppy, or do you
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.
http://rareformnewmedia.com/
I agree that too many people post a lot of stuff at a score of 2 that really shouldn't be - I think it would help if the default were to post at a score of 1, with the option to uncheck a box to post with a score of 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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The book is not only available in printed form, but Bruce Eckel has a web site on the book and related subjects, including the full text in both html (downloadable zip or browsable) and indexed pdf format. However, it's not small and I would recommend going for the paper version if you like it.
The only Good System is a Sound System
The Third Edition of Java in a Nutshell is quite a good beginners book. But dont try the 1st or 2nd editions, they require you to know a bit of C or imperative programming. The Third Edition is much nicer for newbies.
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?