|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 35
Messages: 35
Messages: 35
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Weiqi Gao: The Number One Ill of Java
Weiqi Gao has posted "The Number One Ill of Java ..." saying that Java's requirement for the "stupid 'directory structure reflecting the package hierarchy' (mis)feature." No mention of the bloated JRE, or the license issues, or the confusing classloader issues, or ...[The number one ill of java...]
... is its stupid "directory structure reflecting the package hierarchy" (mis)feature.
I was "helping" 20-year programming veterans to "understand" this (mis)feature in 1998. I'm still "helping" people to understand it now.
"I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?"
There is no good answer to this question. Sure, you can get use to it. You can even be proud that you are among the 5% programmers who persevered in understanding it. But it doesn't make it right!
You can label the on switch "off" and the off switch "on". People will get used to it. But that doesn't make it right.
It causes unnecessary problems. And its another barrier to true understanding.
That, and zero-based array indexing, have got to go. What do you think? Any votes for the date-handling? The security manager? Serialization? XML handling?
(Oh yeah - last thought. Anyone reading who's in the 95% who Weiqi says don't understand the package structure in Java?)
|
|
|
Message #237353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Organization is a good thing
I prefer having packages that reflect the directory structure. In my favorite IDE, I can easily view the folders and visualize the project structure. I've also worked in the .NET world where packages (namespaces) do not need to reflect the project structure and, in my opinion, it tends to lead to a bit of disorganized chaos because the directory hierarchy is not enforced.
|
|
|
Message #237356
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Someone hit him with a cluestick
You can even be proud that you are among the 5% programmers who persevered in understanding it.
Yeah, right. That's probably because it's really, really difficult to understand that the source file for foo.bar.Baz is located in the source tree under foo/bar/Baz.java. Great to have a genius like Weiqi Gao around!
That, and zero-based array indexing, have got to go.
Eh? So what's your suggestion? 5-based? 8-based? Seriously, that was the worst article in a very long time.
Hoogla Boogla
PS: I know he probably wants 1-based arrays, no need to point out you've missed something.
|
|
|
Message #237359
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Number One ill?
I can understand the 0 based array index, it's not difficult as you can easily get used to it but is counter intuitive, thats for sure.
But package structure... Number one ill???? come on!! no one who can honestly say they are veterans in programming would take more than five minutes to figure it out.
|
|
|
Message #237361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Bah
One of *the* things I liked about Java is how it forced you to place one class per file and one package per directory. You won't believe the kind of messed up hierarchies C/C++ people come up with! Java forces you to be clean, if you don't like it too bad.
His complaint about zero-based array indexes also makes me laugh. It's subjective, different people prevent different approaches. If you decide to modify zero-based array indexes be sure to modify anything else that is zero-based in the language.
As a sidenote, I believe it was Joshua Bloch that recently said that he regrets that Java did not incorporate unsigned integral types into Java from the onset. One reason being that array indexes are naturally unsigned values and Java is currently running out of index space for arrays (32-bit signed integer is not enough for some applications).
It would be interesting to see how things unfold going forward but I would like to see Sun lean more towards language/code cleanup in the future even if it means breaking backwards compatibility.
|
|
|
Message #237363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Bah
Files and directories aren't actually relevant to programming, they're just what our crummy languages/environments make us deal with.
Most of the time when I'm using IDEA I don't think about files, and hardly ever about directories - I just ask for the source for a certain class and start editing it. That could work the same way even if I could have more than one class per file.
|
|
|
Message #237364
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
How did this narrow minded drivel make it to the TSS homepage?
|
|
|
Message #237366
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
50% Agree
If I understood you correctly; you're complaining about javac needing the top directory of your project source files; that I agree with; SUN needs to fix that.
But the zero array indexing is the norm now in all C like languages; we kinda got use to it; and I don't think changing it now is possible with all the apps out there in Java.
|
|
|
Message #237367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What ever
of all the things to bitch about in Java, the directory structure "shouldn't" be number 1. Try using Visual Studio .NET and the flat structure. Having done that, I find it a nightmare to manage if you have say over 10K files. I suppose those who don't like well structured code prefer to write everything in 1 huge file and grep. by the way, that's a joke. though I have seen bad programmers cram everything into one huge file with 50K lines.
peter
|
|
|
Message #237370
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
So how does one get their random thoughts from the blog posted as a real news article of interest to the community? I'm going to go post on how the number one problem with Java is how they won't let us start variable names with numbers. Seriously, why not? I know you guys are dying to read it!
On a completely unrelated note, the login page has some bad code. Instead of seeing the actual title in between the title tags, people see this:
<title> <c:out value="Enterprise Java Community"/></title>
|
|
|
Message #237372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
The only valid reason I can think of for complaining about the class naming and location requirements of Java is that it causes problems when you need to move or rename things in a lot of source control packages. Of course, lucky people using svn don't have that concern.
|
|
|
Message #237375
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'd vote for Date Handling
The Date/Calendar/milliseconds conversions are a major PITA, fully qualifying for Number One Ill.
Classloader issues are a close Number Two IMHO, i'd love to get a warning when the same class is found multiple times on the classpath...
|
|
|
Message #237377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do you use mod or understand how arrays are implemented?
Java's package structure:
The file per class, and package/file structure is better than hunting for the files that implement a package. If there's anything wrong, it's the fact that the package nesting itself doesn't really mean anything. Packages should represent versioned component boundaries, and you should be able to have multiple versions of a package co-existing peacefully. If you run a strongly connected components algorithm on static references, the correspondence between jar files and strongly connected components should be good enough to automate high level documentation/component refactoring. THAT would be an improvement. But the way that Java does packaging is underdeveloped, but not anywhere near what is worst about Java.
Zero based arrays:
Array indices starting at 1 is a bad choice because it forces you to deal with silly issues that are only the result of not basing on zero. Ex:
- arrays are often implemented with pointer arithmetic as
arrayBase + sizeof(type)*index
so, if you use 1 based arrays, the underlying assembler has to subtract 1 EVERY TIME an array is indexed (with exceptions for indices being reused in various ways).
- a lot of algorithms need to use the mod function. the code is much more straightforward if you dont have to play a lot of games with the index to make it 1 based.
myArray[ i % myArray.length ]
vs
myArray[ ((i-1) % (myArray.length)) + 1 ]
- Like the above example, many algorithms depend on the numerical properties of the index, like using bit shifts in a heapsort for instance. If you have 1 based arrays, then you waste time translating indices. I would say that almost all array based algorithms are simplified by using a zero based index. This seems to be especially true in the cases where most of the work is actually 1..N based, but having extra slots at 0 and N+1 cause corner cases to disappear.
- Most algorithm texts are zero based, so you would have to carefully translate to a 1 based system when you code it.
Counting from zero is not a wierd concept at all. If you are programming computers for a living, then you need to think mathematically anyhow.
|
|
|
Message #237378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Misstated complaint
While the complaint may be manifested about the directory structure of packages, the real issue is ClassLoaders.
Because that's what the directory structure is enforced by.
I can create a file:
package com.serverside.example;
public class Test {
public Test() { }
}
I can put that in any directory I want and compile it, and I'll get a Test.class file with the "com.serverside.example.Test" class in it.
But the default ClassLoader relies on the directory mechanism for arranging the classes, so if that file is not in the right place, the standard Java ClassLoader "can't find it". You can easily create a ClassLoader that relies soley on the filename, for example. Or whatever your want. The JAR ClassLoader for example doesn't rely on directories at all, it relies on the internal structure of the JAR file (which conveniently creates directories when you explode it, but that's coincidence).
Of course, the directory structure is a natural way on modern filesystems to organize hierarchies and namespaces.
But just like "http://example.com/this/that/x.html" has nothing to do with directories (but can conveniently be represented that way on a server), com.serverside.example.Test has nothing to do with directories.
This is a ClassLoader problem, and I'll be upfront to say it's one of the most complex aspects of the Java Runtime.
|
|
|
Message #237379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What??
? It is one of the better features of Java. I worked on very large C++ project (> 1 mil LOC) and good luck finding the class without grep or without a modern C++ IDE which allows you jump to definition.
Also the restriction of one public class/file is a godsend, but result in many files. Hey, there are always trade off but this one I can live it.
|
|
|
Message #237398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not to mention the additional cycles
Don't forget ever array access (unless done with a value resolved at compile time) would result in an additional ALU operation to subtract 1 from the specified index to compute the correct memory address.
|
|
|
Message #237410
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I'd vote for Date Handling
The Date/Calendar/milliseconds conversions are a major PITA, fully qualifying for Number One Ill.
+1. Yep, immutable legal dates (yyyy/mm/dd or whatever). Ones that stay just as the user entered them and don't keep changing as they are persisted, transferred between JVMs, or shown to a user in a different time zone.
1 based array indexes? I remember them. I used to have to deal with them in GWBasic. All that having to add or subtract 1 every time you used a variable as an index.
|
|
|
Message #237412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Blocked classes
The Date/Calendar/milliseconds conversions are a major PITA, fully qualifying for Number One Ill.
Classloader issues are a close Number Two IMHO, i'd love to get a warning when the same class is found multiple times on the classpath...
You could use Classpath Helper to show you this. It shows you blocked classes with the same bytes as well as different bytes. It's available as Eclipse plug-ins. http://classpathhelper.sourceforge.net/
|
|
|
Message #237413
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Hot class re-loading?
I'm surprised nobody bitched about slow re-deployment.
Could be mostly avoided by adding support for real hot reloading of classes (instead of current 'only method bodies are re-loadable').
/Henri Karapuu
|
|
|
Message #237417
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So... .NET got it right then?
I've also worked in the .NET world where packages (namespaces) do not need to reflect the project structure and, in my opinion, it tends to lead to a bit of disorganized chaos because the directory hierarchy is not enforced.
+1
I do Java 99% of the time, and have dabbled in .NET. The first time I realised that com.foo.Bar didn't need to live in the com/foo directory in .NET, I sighed a mighty "WTF....!". I'd still be open to understanding the benefits of being able "package" stuff as .NET allows if anyone can explain it.
I'm guessing the author is a .NET fanboy or has recently had a lobotomy if Java packaging is too hard to understand.
|
|
|
Message #237422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How did this get onto the site?
Lol.
How did this get onto TheServerSide? Are we going to see more Springereque slap-fights over daft things like this?
But seriously, even if this is a serious point for discusion it should never have been allowed to go up without being properly editted or returned to the author for editting.
Onto the actual subject that merits discussion;
I can see the sense in 1-baased arrays for newcomers (oldies get used to it), and perhaps the compiler can take care of the -1 rather than the ALU at runtime; I write myArray[1] but the bytcode says myArray[0] (in bytcode obviously).
That wouldn't take care of the algorithm problems.
|
|
|
Message #237428
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
It's more than 10 years I'm using Java and never heard such a complaint about Java. Around 2001 I joined a Microsft shop to help them migrate from asp based development to jsp/servlet world. One thing I heard almost from all those experienced VB/ASP developers was they love the fact that "directory structure reflecting the package hierarchy" and believe it makes organizing the code easier. By then I had never thought about this aspect of Java!
|
|
|
Message #237433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You sound quite offset ...
.. But! your comments are very reasonable.
The original author's sentiments are actually reasonable as well. However, they are precisely that, sentiment, and do not stand the scrutiny of expert consideration.
Same problems haunt the server side Java (the technology I mean <g>) but regrettably, on the server side, the sentimentalists have had their way ... "really, why do we need all those "stupid" deployment descriptors all over the place? Can't we just put it in the javadocs??" ..
/R
|
|
|
Message #237439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ill? I am not sure who is ill here
Imagine a scenario.
directory com.xxxx.dao.hib.impl contains XYZ.java
and I Can find that out by looking at the code.
But our talented friends says that he wants to by-heart the location.
NOt only that, he wanted to by-heart the locations of remaining 12,000 files in the app too!!
Go ahead, be my guest. yOu can do that even with package names. wHy not by-heart a bat script too, that will change current directory and run the compiles.
BUt give me my option of packages.
|
|
|
Message #237440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
The point about directories having to match file structures being an 'ill' took me by surprise. I think 20-yr programming veterans the author referred to, would have appreciated it right away.
But honestly, classpath issues esp. those in application servers need to be simplified and standardized.
|
|
|
Message #237442
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?
javac -d
If you have been teaching java since -98 and havent figured that out...?
|
|
|
Message #237445
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Organization is a good thing
I just have to agree with the rest here. After 15+ years of c++ programming before starting java coding, i have nothing but good things to say about the directory structure / package structure connection. I wish C++ namespaces forced the same restriction, but there are good reason why (yep, c++ is one weirdo)
|
|
|
Message #237460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ill? I am not sure who is ill here
Imagine a scenario.
directory com.xxxx.dao.hib.impl contains XYZ.java
and I Can find that out by looking at the code.
But our talented friends says that he wants to by-heart the location.
You know I have a friend/working collegue who insists on using UEdit to write java code, or notepad if UEdit isn't available.
So I guess people like him would probably concur on the initial post :o)
a++ Cédric
|
|
|
Message #237461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?
javac -d
If you have been teaching java since -98 and havent figured that out...?
I beleive he was referring to the fact that you can't easily compile, from the command line, all java files in the current directory if there are references to other source files.
For example: com.foo.bingo.Baz refers to com.foo.Toto
javac -c Baz.java will fail because Toto isn't in the CP.
This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.
To which I don't think the -d option will help much, am I wrong?
That being said, it doesn't stop me from sleeping :o)
a++ Cédric
|
|
|
Message #237472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: So... .NET got it right then?
I've also worked in the .NET world where packages (namespaces) do not need to reflect the project structure and, in my opinion, it tends to lead to a bit of disorganized chaos because the directory hierarchy is not enforced.
+1
I do Java 99% of the time, and have dabbled in .NET. The first time I realised that com.foo.Bar didn't need to live in the com/foo directory in .NET, I sighed a mighty "WTF....!". I'd still be open to understanding the benefits of being able "package" stuff as .NET allows if anyone can explain it.
I'm guessing the author is a .NET fanboy or has recently had a lobotomy if Java packaging is too hard to understand.
Guess that is why they choose to call them Namespaces. :)
The good news is that one can match the folder structure to the Namespace. It just doesn't happen by default. :( But the really bad part about .Net Namespaces is that the Namespace is "wild-carded". And that kicks my behind all the time.
|
|
|
Message #237487
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Compile can't deal with the subtraction for you
The problem is that array indexing is usually done through variables, which typically live on the stack. There's really not much room for optimization in terms of subtracting, since the value can't be known until runtime. Only compile time resolvable expressions could be optimized, such as myArray[1].
It's a waste of cycles for something that is not really an issue. Programmers in most languages have been dealing with this for a long time. Even VB gives the programmer the option of using 0 indexing to save the cycles.
|
|
|
Message #237522
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java do not force one package for directory
Java, as a language, do not force any directory structure. It is the compilation
environment that use, by default, some assumption about directory structure to
find classes; but even with javac, you are not really forced to build a directory
structure that map the package structure; for exemple, you can use
the cc style and give a complete and explicit list of Java files to compile as arguments;
in this case, javac don't care where the files are.
I used this technique a couple of times to avoid what i think most of us agree it is
the real pitfall of the package structure: Java packages are namespaces, not modules, and
using namespaces to limit visibility is a way to "emulate" real modules.
This solution work in simple case, but it doesn't when you want to have submodules; you
end up using subdirectories, that by default are nested packages, i.e. just
different namespaces; than you need to make give public visibility to the API
between submodules, that is surely not what you want, and you are finally screwed.
One alternative is to use subdirectories for the submodules, but to not use a different
namespace, using the available javac compiling options; you don't have isolation between
submodules, but you have isolation between the module and the external world.
|
|
|
Message #237574
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?
javac -d
If you have been teaching java since -98 and havent figured that out...?
I beleive he was referring to the fact that you can't easily compile, from the command line, all java files in the current directory if there are references to other source files.
For example: com.foo.bingo.Baz refers to com.foo.Toto
javac -c Baz.java will fail because Toto isn't in the CP.
This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.
To which I don't think the -d option will help much, am I wrong?
That being said, it doesn't stop me from sleeping :o)
a++ Cédric
eh? javac -d <adir> -classpath <adir> ...
Or what?
|
|
|
Message #237584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.
Hum, comparing the C/C++ compilation/linkage process with Java is really straight forward: when javac compiles, it means everything needed was found and the JRE works with same classpath.
When your .c file is compiled, you just have a .o ! You still have to link all your object files against libraries to get an executable... and it is not obvious it runs then.
So Java is better but not perfect: who never gets a NoClassDefFoundError or a LinkageError ?
Yves
|
|
|
Message #237679
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weiqi Gao: The Number One Ill of Java
This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.
Hum, comparing the C/C++ compilation/linkage process with Java is really straight forward: when javac compiles, it means everything needed was found and the JRE works with same classpath.
When your .c file is compiled, you just have a .o ! You still have to link all your object files against libraries to get an executable... and it is not obvious it runs then.
So Java is better but not perfect: who never gets a NoClassDefFoundError or a LinkageError ?
Yves
Not to mention how much smoother dynamic classloading is in Java compared to dlopen/ld/dll hell(s) in C et al.
Of course this also means that it is sometimes over-used....
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
