Slashdot Mirror
Java Application Development on Linux
The authors, Carl Albing and Michael Schwarz, chose to create a book that is a complete guide to writing commercial-quality Java programs. With the burgeoning presence of Linux, they focused on how to use the tools of the Linux platform to assist in the creation and maintenance of Java programs. They have broken the book up into five major parts: Getting Started, Developing Business Logic, Developing Graphical User Interfaces, Developing Web Interfaces, and Developing Enterprise Scale Software. Each chapter is self-contained, and the knowledgeable reader can pick and choose what they would like to read without losing track. Carl and Michael have properly started each chapter with a summary of what you'll learn, and conclude with a What You Still Don't Know section. A Resources section is included to give you more references for further study.
Part 1, Getting Started, provides a 10-chapter overview of Linux, Java, the SDK's (Software Development Kits) from Sun and IBM, version control via CVS, and IDEs. The first two chapters cover enough command-line Linux to manage your files and directories, plus the Vi editor to create and edit your programs. Chapter 3 gives you a summarized but complete overview of the Java language (minus the standard classes), and Chapter 4 covers how the program can deal with the context in which it's running. The next two chapters cover Sun's SDK and (mainly for comparison) IBM's development kit. In some instances, the Java program may be so large and/or so complex that running the byte codes in the Virtual Machine may not be quick enough, so Chapter 7 describes how to use the GNU Compiler for Java (gcj) to create native-code programs.
Larger programs definitely need some form of source control (actually, any project larger than a classroom exercise needs it), so source control using CVS is clearly laid out for you. While other products are available, CVS (Concurrent Versioning System) is widely available, robust, mature, and reliable, so the authors chose to describe its use in detail. For building and deploying the numerous files of a larger project, Ant provides value beyond what the make facility can offer, especially with the RMI (Remote Method Invocation) dependency problems that make can't address. Finally, Integrated Development Environments are covered. While Carl and Michael focus on NetBeans, SunONE Studio Community Edition and Eclipse are also covered.
If the book stopped after Part I, you would still have a valuable addition to your bookshelf. However, it continues with a five-chapter discussion on how to properly develop business logic. One chapter is totally devoted to the business aspects of getting requirements, documentation, and buy-in. The next covers how to use a simple software development methodology to analyze the program and discover the objects to be created. The following chapter goes over a frequently overlooked aspect of programming - automated testing - with JUnit. The last two chapters of Part II cover storing data in databases using Oracle, PostgreSQL, and MySQL, and using the Java Database Connector (JDBC) to access them.
While Linux users (at least the older ones like me) are more used to command lines, most users want some form of a graphical user interface (GUI) to access the program and their data. Chapters 16 and 17 describe how to create a GUI using Swing and the Standard Widget Toolkit (SWT).
By far the most popular way to access programs is via a browser. Java Servlets are (maybe not so) little programs that run on the targeted web server, relieving the user of having to install an application on their local computer. This allows the user to always have access no matter which machine they're on (how many times have you complained that the program you want is on the PC where you're not?), and to always be accessing the latest version of the software (assuming the web administrator keeps it updated on the server). Chapters 18 and 19 cover Servlets and JSP (JavaServer Pages), then Chapter 20 describes Java-based web application servers (JBoss and Geronimo) for serving the servlets.
Finally, Part V covers Enterprise JavaBeans (EJBs) in what the authors describe as an almost criminally brief introduction. While it is definitely an overview, they still cover more than enough about EJBs to get you rolling, and provide many references to where you can fill in the blanks. They wrap up the book with a plea for help. The book is an Open Content book, and therefore they are requesting comments, suggestions, and patch files to help improve the text and examples.
I have to admit that Java Application Development on Linux is an extremely readable, very informative, and deep without being lengthy book. (The only complaint I have is that they tried to cover a little too much in a single book. EJBs, for instance, definitely warranted more coverage than they provided.) Carl and Michael use a very conversational tone, just as though they were sitting with you and giving you their personal attention. I found it enjoyable, interesting, and highly informative.
You can purchase Java Application Development on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Saying that Java is good because it works on all platforms is like saying that anal sex is good because it works on all genders.
I do some of my development in linux, and some on windows. I have found some differences in linux but very few. There is one huge advantage of java, and one huge downfall.
The advantage: Java has abstracted alot.
The downfall: Java has abstracted alot.
For anyone who has done alot of programming in Java, they will understand.
The biggest issue with cross platform development is the "Gotchas". I'd like to see a list of what is actually different between all the OSes. What os specific parameters are there. What classes are unique to Linux devices. Especially with the native IO that 1.4 and later have included.
From skimming through the review, I saw no mention of Eclipse. I wrote a large part of my Masters Thesis in Java on a Linux machine. Sure, Í could use vi, emacs or whatever and a command line compiler, but for me Eclipse is the Java development tool of choice.
BTW. the ret of my project was Java for a HP iPAQ 5555 which, interestinly enough was developed on Windows using IBM websphere device developer, which is based on Eclipse
Freespirit
While Carl and Michael focus on NetBeans, SunONE Studio Community Edition and Eclipse are also covered.
Editing Java in vi is one of the biggest waste of time I can imagine. Eclipse and Intellij are far far more productive environments in ways that are too numerous to describe. I think a Java development on Linux book should really ignore vi and just be an Eclipse centered tour at this point with a little bit of documentation on bash usage , scripting, deployment issues and tuning the environment.
Free But Shackled - The Java Trap
Let's see, they discuss:
* Basic Linux (files, directories, vi)
* Basic Java (two different SDKs)
* Basic software development (requirements gathering, et.al.)
* Basic programming (CVS, build tools)
* Basic Web programming (servlets, presumably JSPs, no Struts/Spring/other frameworks)
* Database programming (Oracle AND PostgreSQL AND MySQL)
* And finally, Enterprise Software in the guise of EJBs (remember: friends don't let friends use Entity Beans!)
Granted it's 600 pages, but I'm wary about how much real detail they can pack into all those topics. I'm guessing this won't be much of a reference book, but rather a large collection of introductions to a variety of Java topics.
Just junk food for thought...
*sigh*
I can't remember the last time I had issues with code because I changed platform, OS, or even JVM version. It's to the point where I don't think about it anymore.
Maybe if you're talking GUI code (desktop/applet), but for web or backend it's just not been an issue for me in some time. I've been developing on Java professionally for nine years now, and have have production systems in place for eight. I remember when you used to need to test every single VM, but by and large that time is done.
For example, I just finished working on a project running on J2EE 1.2 on Websphere 4 (jdk1.3.1) on Windows to running Websphere 5 (jdk1.4.1) on Z-Linux. The *only* thing I had to change was code that was written out of spec (a few JSPs forgot to import java.util.Vector). If the developers of the app hadn't been sloppy, there would have been no code change at all. This is an app that hits databases on Oracle, DB2, Teradata, and LDAP (with updated drivers for all of those, too).
I can think of plenty of counterexamples, but for most server-side business apps it really is write once, run anywhere.
Your binary gets interpreted by the local parser too. It's called a CPU.
./configure, make, and make install? Simple. Not everyone wants to distribute source code. Shocking, I know.
What's wrong with
I know what they mean by that, but really I'd like to have open source quality apps. That's the next level up.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Sure, you have to test on all the platforms that you support. But, what language/runtime requires less x-platform testing than Java? Today, the real issue is testing on each J2EE app server. That's where the real issues are. I haven't seen a pure Java platform issue in years.
Write once, run anywhere becomes closer to the truth if the developer has experience with multiple platforms and knows what he is doing.
Our product that runs on Linux/Solaris/AIX/Win32 also runs wonderfully on OS/390, but this is only AFTER the code base was revisited to respect that fact that a 390 is EBCDIC. For example, ASCII config files that you ship along with your distro to the 390 will be read in the system default encoding if you're using plain Readers. You'd want to use streams with an explicit encoding type. Or, just use XML since the parsers internally understand UTF-8.
So, some may say "debug everywhere" but in some cases this isn't being completely fair, if you're placing the whole blame on the JVM.
(Just as a side note, the weirdest porting problem I had was the result of someone who shall remain nameless assuming that all filesystems are case-sensitive. I unpacked the source tar onto an HFS drive and spent ages trying to work out why some externs were undefined. tree.c was being extracted over TREE.c. There are so many assumptions one can make without checking that they hold for every platform - and even if they do, a future platform may break them if they're not part of a standard to which you're working).
Java-Gnome binds gtk with java. Very nice.
Well, here's another article just beckoning me back to try Java development once more. Here I am, on the rebound again, not knowing any better. Almost forgetting the tough time I had creating GUIs, coming to grips with the AWT then Swing. Going nutty putting multiple classes in a jar file and all that manifest destiny sweet talk that had me at "hello world" but not much further when I ventured out past the simple stuff.
.NET, but too afraid to jump head-on into a relationship with cpp.
Oh yes, it was sooo much better than VB if you can get past the quick way to make graphical interfaces. The multi-threading made creating a multiplatform port-scanning tool so much more pleasurable.
Then there was running the code on multiple platforms. The need to install the JRE, ensure you're pointing to the right CLASSPATH, and all those somewhat cumbersome things.
Yeah, after a while, I forget those experiences. I come crawling back, not wanting to be assimilated in
I'm sure it's going to take time and effort, and I know I need to put more time in our relationship. Right now, though, I'm in the middle of a project with PHP so I'll get back to you when I can. Just remember, Java, that it's not you...it's me.
P.S. -- I think your father's a prick.
> JAVA is a big fat marketing lie.
Which, amazingly enough for a lie, I am now using to rewrite some of our inhouse utilities in preparation from the move from Win2k to Linux servers. There's not too much overhead on CLI Java programs, and I've ported one app so far, rewritten on my Windows box, and it ran without a single hitch on the Linux server it's destined for. No recompiles, no nothing.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Sloppy programming and / or paranoia by the developer.
Anything written for java 2 (1.2 and up) should work fine on the latest 1.4.x, and will probably work fine on 1.5 (I have had some funny issues with 1.5, but they were build time issues)
The only thing I've encountered that actually broke stuff in a version change was the bizarre choice by Sun to not just deprecate reading the OS environment, but to completely disable it by causing it to throw a runtime exception in 1.4 They changed their mind and re-enabled it and un deprecated it for 1.5 though.
Advanced users are users too!
I work for a fairly high profile Internet commerce company that uses WebLogic and pure Java. Our production servers all run Solaris, most of our developers run Windows XP (previously Windows 2000), and I run Linux.
We have hardly ever had any issues with "Write once, run everywhere." It works. Really. Probably writing Swing/GUI apps is different, but on the server side, developing and deploying across different platforms works like a charm. Admittedly the issues you get on development vs. production can be very different, so deploying a production system on multiple operating systems might give you different results. But as far as testing and developing on two platforms, then deploying on a third, we have no complaints.
In a real emergency, we would have all fled in terror, and you would not have been notified.
I congratulate you on providing one of the best examples of trolling I've seen in a while from a non-anonymous post. Let's see if you've covered the basics:
Congratualations... you're a winner!
All sarcasm aside, if you don't like Java and don't develop software in Java, then a book whose title starts out Java Application Development is probably not for you. Moving right along....
I normally don't reply to "Anonymous Cowards" but in this case I will make an exception.
If you are running OSX 10.3 you are running a very new version of the JVM. If you are running OSX 10.2 you are also running a very new version of the JVM. So I guess my question is what OS are you running on it?
Now you mention that you don't "miss" Java. I will argue that you don't care what an application is written in, as long as it looks good, is stable and does what you want. So I challenge you with this. How do you know what the application was written in? You probably don't. If you are a Linux/Macintosh/Windows/Netware/Solaris user and you launch your MP3 player and it works do you really care to see if it was written in C, C++, Java, Cobol?
JAVA runs on all MAJOR platforms.
It doesn't require the user to "compile" any code to run.
It has a rich GUI toolkit built in.
It handles object cleanup well.
It's speed has become excellent at most tasks
It has excellent networking support built in.
It has a giant developer base helping to add funcitonality.
The more I learn about science, the more my faith in God increases.
Actually, this book sounds like a good idea - cover deployment issues like database installation and configuration with Java, tips for deployment, etc.
:-) would make Java a more suitable language for small applications and utilities. This would get around Sun's lame Linux/Java licensing issues also.
I usually do my development on OS X (except for new JDK 5 coding - use my Mac as an X display for a Linux box -- annoying that Apple is slow getting JDK 5 out except for in a $500 developer's preview). Anyway, I do most of my deployment on Linux, and the ease of this depends on which hosting company I am renting a server from. For example, is a usable (i.e., PostgreSQL) database installed, easy to administer, etc. I have not read the reviewed book, but hopefully a lot of practical issues are addressed.
One interesting thing about the Linux platform is that now all new distros have RPMs (or equivalent) for installing runtime and developer support for GNU GCJ.
I find GCJ to be very interesting (a bit of a nuisance to run on OS X) because not only is it a way to run Free Software (GPL) on Linux, but it also makes it possible to take large Java applications like Lucene, compile them natively, and then use the compiled code in Python, C++, Ruby, etc. programs. Very cool, really.
If Linux was my development platform, GCJ would be a much more important tool for me - it would be great if Apple installed GCJ runtime libraries by default (yes, they are large). While Java is not as productive a language for many programming projects as Python, Ruby, etc., Java is a great language and platform for many types of projects; having GCJ runtime installed by default on OS X, Linux, and Windows (well
I'm not a Java zealot by any means, but Java deserves credit for what it does well and one of those things is reducing the importance of platform.
;) -- that runs on XP, Redhat, Mac/OS, Solaris >= 8, HP/UX and AIX 5L.
I've recently worked on a J2EE project with nearly 1 million lines of code -- they're all needed, really
Have there been platform related bugs? Yes.
Are there any open? No.
Are there some lurking? Maybe, but we've tested extensively.
Could any collection of jackasses build this app? No, sorry.
Is Java a magic bullet? No more than any other tool.
I won't argue that Java feels a little bit slower than C++ on a native platform. However, there are a few instances that I can think of where a developer would choose Java over C++:
.NET, you couldn't easily code the interfaces. At least with Java you can guarantee everything will look the same no matter where it runs.
Portability - You can't run C and C++ in a web browser very easily. In an enterprise environment, or even on the internet, you need to be able to distribute your application quickly. No one likes having to download a program from the Internet, especially in the days of spyware and adware. Allowing people to just run your program with code they know won't break their computer is the best way to fly. No to mention, HTML allows you to embed a Java applet much easier than CGI allows you to execute a local program, in my opinion.
User Interface Design - Ever try to write a Windows interface? What about a GTK interface? If you need a program whose main focus is in computation and calculations, not User Interface or data entry, an IDE like NetBeans will help you easily design the interface in an hour or two rather than having to manually code it by hand and constantly test how it looks. Before
Memory Protection - With Java, you have no worries about memory troubles. With C and C++, the developer has to handle his own memory allocation and garbage collection. Java does it automatically. What worries do you have when you dereference a pointer to 6 MB's of memory if Java is going to clean it up for you? There's almost no room for pointer miscalculations and for dealing with ugly Microsoft API's that handle six or seven different arguments, all either reading or writing and all being pointers. Unix API's are simpler but you still run into Segmentation Faults with Linked Lists and other Data Structures.
When you write an application, you want to focus mostly on the purpose of that app, not small CS details such as memory allocation and UI design. Obviously, some projects require this attention but for an enterprise project that isn't going to break into any new territory, eliminating as many problems as possible is the best choice. That's why languages like Perl and Java are great - very little chance to blow things up. I'd agree with someone that Perl might be a better choice in some instances over Java, but saying that C and C++ are better choices because you can compile them natively and run them a few milliseconds faster isn't a good reason for me.
I use Xemacs, JDE, and make on Linux to create commercial products in java/jsp.
At my last job, back on 2002, ant forced me to hate it when:
1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
2. We had this crazy huge build.xml file that was created for our project. It started off life as a rats nest and only got worse from there (OK, probably not ant's fault but it had the same effect on me). On top of it being huge, its in XML which is way hard to read compared to a makefile.
3. I never could figure out how to ask ant to echo the compile line. Make echos it by default and I like it that way.
That was three strikes.
On my current project we are using make but one of them whipper snappers came along and made a build.xml file for the project. Its just one big, ugly, build.xml but it is much faster. The project has 30 or so small, easy to read/understand, makefiles (and I figured out how to make it go much faster on a clean build but its still not as fast as ant).
Sure, make has its quirks (e.g. the tab thing) but I figured all thouse out 15 years ago.
I tried Eclipse last fall after seeing an interesting presentation on it. I tried it for a couple of days but it felt so bloated that I soon abandoned it.
This sig intentionally left blank.
A few (who am I kidding... several) years back, Gartner was promoting a different spin on why IT departements should adopt Java: "Train Once, Write Everywhere". The idea being that with Java, you could have (in theory) the same guys who are writing the GUIs and desktop apps write apps for the server and mobile environments too.
Yes, I know you could argue that "C" fits this bill nicely, too, but the fact is that most corporate IT shops at the time were VB and PowerBuilder clients talking directly to databases. Your average corporate developer would do more harm than good with C, and Java was seen as a simplified C++.
Anyway, I don't know if Gartner ever changed its stance on this, but the reality became quite different with the introduction of J2EE; J2EE required quite a different set of skills compared to good ol' J2SE, and many developers still can't adequately grok distributed server-side development.
Java is just a language, and I firmly believe that more attention needs to be given to the art of programming rather than to any specific language. It seems nobody cares anymore for appropriate use of patterns and careful selection of algorithms. It's all brute force programming. Get it done. Here's your soup - go code.
You can learn all the languages you want -- learn to speak English, Russian, Spanish, French, Hebrew, German and Greek -- but if you don't know how to communicate...
None of the topics mentioned in the review really seem to be Linux specific. Why not just call it "Java Application Development" (period, no "on Linux")?
There are some things that I think would be worth covering though, in a book about Java/Linux. Particularly for someone coming from a development of an app in a Windows Environment to deploying an app in a production Linux environment. Since often they will know all they need about Java. But won't be very familiar with Linux. And may not know the best way to do things in a 'Linux' way.
Some examples...
Init Scripts: Setting up init scripts to stop/start your Java services (e.g. getting tomcat to run on boot up). That differs a lot from how you'd do it with services on Windows.
Permissions I: Often on windows things will be run as root/Administrator. On Linux the better way is to have Java services run as a non-root user. e.g. run Tomcat as tomcat not root. There are some implications to this. e.g. you an unprivileged user cannot listen on addresses with sub-1000 port numbers. The solution is something like iptables or mod_jk2.
Permissions II: Another permissions issue (that I see crop up a lot with people moving from the Windows dev machine to one of our Linux servers for productions) is file permissions. Users being not being able to read/write config/data files that they had been able to see/use well enough on Windows. i.e. a paragraph on the almighty chown -R would be handy.
Command Lines: A page or two on running things from the command line would be a great thing. Often people working on Linux servers are doing so remotely. And won't have a GUI. And often they are only familiar with launching their app from the ide. So knowing about 'java' and 'javac' would be handy. And mention the need for colons between dir names not semi-colons. e.g. java -cp /myclasses:/3rdparty.jar mainclass.
Automating Tasks Users moving from a windows/dev environment to a Linux/production environment would also be well served by a page or two on automation tools. e.g. using ant to automate the process of getting code out of CVS and deploying it. e.g. cron for automating the process of running Java jobs on a regular basis.
--
Java Hosting on Linux, Simple Enough Even For Windows Users
I try and compile your code with GCC and get tons of errors. (I get them all the time with Linux and so do you if you grab lots of source code, perhaps this was the core reason RPM was developed). You and I then spend lots of time working with people to resolve the issues. We generally find out that we don't have a recent library that is needed or we find out that we have too new of a library. We then have a fun option of going to "RPM hell". We start a long process of upgrading stuff in hopes that it will fix our problem.
Some of this is the same in JAVA but with one difference. You don't compile the source code on the machine. You send them a JAR file (zip compression) and in most cases they can just click(or double click) on that file and it runs. Doesn't that sound better? Send a file to a user, have them click on it and it runs? Heck you can even do one better. You can use Java's web start and have them go to a web page, launch the app from the page, it will check to see if you need a JVM installed, if so it will install one (major platforms only), then copy the application down to you and run it. The next time you try and run the app it will check the server automatically for updates and download them if needed. If for some reason the network is not available then it will run the local copy. Some people hate this, but a ton of developers and businesses love it. So now you have two ways of delivering your application. One with Webstart and one with sending a JAR file. No compile needed on either one. All the user needs to do is click on the file and they are off and running.
Lastly, I would also argue that if you have some basic users out there it will be far far easier to get them to load a JVM(with or without using webstart) than it is to get them to load a C compiler. The JVM installer has come a long way on all the major platforms.
Again though I ask you. Do you really care what the code was written in? When you click on your Instant messenger, Email client or CD/DVD burner and it runs, do you care what it was written in? If so then why?
Now I as a developer who wants to write a DVD burner have three options.
I only target Windows because they own 93+% of the desktop market? Most will answer yes to that question and use only Microsoft stuff, and lock the app in to the Win32 API set.
I can develop the application in JAVA and make the installer check to see if the user has a JVM installed. I then can focus my testing on Windows and the product should (without recompile) run on all other platforms.
I could write the software in C or C++ and force the user to have a compiler for their system, (good luck on the various windows versions), then compile the code on that system, create icons for them and they would be off an running.
Out of those options most developers choose options 1 (sucks but it is reality), a few pick option 2 and only open source people pick option 3.
lastly I want to point out that NOTHING is stopping the developers in option 1 or 2 from giving the source code away also. So those brave souls who wanted to compile it could. I can say that I run a quite a few JAVA applications from sourceforge that were written soley on Windows and tested on Windows but because they were written in JAVA I have had GREAT luck in getting them all to work on Linux. Specifically 64bit SuSe. Now getting C source code and compiling it.... Well that is another matter. I still don't have a working copy of Mondo, and can't compile it to save my life.
The more I learn about science, the more my faith in God increases.
Back when I was running JDK 1.4.whatever, there were inconsistencies in operation between Windows and Linux using the NIO (non-blocking I/O) libraries. There are several messages on Sun's message boards relating to this. It seems to have been worked out by now. NIO was kind of squirrely for a few revisions there.
I have coded a wide range of applications, and have used many of the facilities provided by Java. NIO was the only part of the standard library that gave me trouble. However, I have a friend who was using Java3D for a project. His jobsite uses pretty much the gamut of operating systems. He has told me that Java3D is just plain not portable. Code that worked on Windows would not work on Solaris. I have no details on this, but they ended up using something else, according to him.
If your program _only_ relies on gcc it must be a text-based app - X calls don't work on Windows and MFC libs aren't available for Linux.
Java comes with portable GUI libs.
Slashdot's name? When my compiler sees
I agree 100%. I can't stand whiners who claim that Java portability is a myth. The exceptions are trivial and few. It is my opinion that such complainers are either not Java programmers, or whose only interest in Java is finding such examples to trash on it.
The worst thing about Java, supposedly a "write once run anywhere" language, is that you can't run anywhere. You can only run on platforms that Sun has ported a JRE to. This is why projects like Kaffe are so important. With an open-source implementation of the Java specs, you never have to worry about unsupported platforms or Sun yanking the rug out from under you.
Constitutionally Correct
Although you can decompile java byte code with some degree of success, obfuscators exist which can be applied to the byte-code before you distribute it to make decompiling nothing but a waste of time as the code is irrevocably incomprehensible (and some byte-code obfuscators mess things up so bad that the decompiled code won't even compile at all!) Use of such obfuscators is not bad programming practice in the same way that obfuscating source code is because you are still working from clean source. In this sense, java byte-code obfuscators have more in common with the unix utility 'strip', than the conventional notion of an obfuscator. You can set things up in your build.xml or makefile so that the obfuscator can automatically be run on each class file as it's generated, whenever you specify a target intended for distribution.
File under 'M' for 'Manic ranting'
Any program you write completely from scratch with C++ could be compiled for any platform. But if you use a third party API in C++ chances are it is not available to you in source, so you are stuck.
Close, but no cigar. If there are enough binaries for the different platforms, you might not need the code. The bigger problem is that people tend to stack libraries - e.g. on the Windows libraries. That will really get you stuck.
The thing about java is that everyone is forced to distribute "source", or more specifically, bytecode, which amounts to the same thing for cross-system compatibility purposes.
Byte-code is far from source. Though many names (public class names, method & field names) are preserved, none of the code within methods, as well as parameter names will be preserved. Please stick to the Virtual Machine paradigm instead - it pretty much explains itself.
Can you make non-portable "libraries" in Java? Yes.
Well, only if you move outside the Virtual Machine (JNI/exec() calls from the VM), since the default API is available on any supported platform. So that's pretty difficult indeed.
We are probably in the same mind on this issue, but it seems that your explanation is more confusing than it needs to be.
Chapter 1: Confusing the user.
That is the fault of the programmer, not the language.
Chapter 2: Meanlingless error messages
The application programmer decides the error messages. Uncaught exceptions might show to the end user, but if you don't understand these, show me a language with clearer error messages? "ArrayIndexOutOfBoundsException? FileNotFoundException? MidiUnavailableException? What does this mean, I do not understand any of this. Owie my brain hurts...."
Oh, and it is spelled "meaningless". HTH.
Chapter 3: Remaining slow no matter how fast the hardware is.
Chapter 4: Losing data.
And finally:
Chapter 5: How to create the blue screen of death.
Hmm...seems I just responded to a troll.
Being bitter is drinking poison and hoping someone else will die
And for example C++, it should be "write once, port anywhere and then test anywhere"? At least with Java, you can skip one step.
8 of 13 people found this answer helpful. Did you?