“I ran starry-eyed into the arms of Java 9 years ago. I build enterprise Java applications in my sad day job. I think I can speak with authority to Java’s failings. Both authors of the original documents made claims of ‘solution’. I assert that all software exists for the end-user, and a ‘solution’ that helps the developer, or requires arcane knowledge, solves nothing. Toolkits that allow developers to rapidly create portable code are a necessity to meet business and user needs.” Interesting editorial by C.C. Hovey.
It’s called the GNU Java Compiler – http://gcc.gnu.org/java/
It can compile Java source code to native ELF executables.
And yes anti-open source Java people: this IS an open source implementation of Java! It has existed for years now. Will you say “Oh no, Java will now fork into thousands of incompatible forks and will now die!”? And Sun didn’t even have to open source their own implementation!
So where are the thousands of incompatible forks? Actually, where are the thousands of incompatible forks of Perl and Python? Or GNOME, KDE and OpenOffice?
Today’s lesson: Open source does not guarantee forking. If your project forks then that most likely means there’s a problem with the project’s leadership.
Read the articel! Its not about compiling native executables but about creating native userinterfaces that integrates in your Windows/MacOS/GTK/QT Desktop.
If you’re using a Java app, you don’t need to manually switch to the server VM or tweak heap size parameters; it is the responsibility of the app developer to tune their app. If a developer ships an untuned Java app, that is not Java’s fault or the user’s fault.
As an analogy, C compilers have just as many arcane options as the Java VM, yet that has not prevented C from becoming successful.
It’s called SWT. http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.h…
SWT. That’s all I have to say. Eclipse, Azerus, all these apps have a fast, native interface. I have no trouble using them at all. AND they’re written in Java.
He’s right, Swing sucks.
The SWT toolkit for eclipse is programmed in Java and is fully native with great performance. What more do you need? Need it to look like SWING, sure go ahead and use SwingWT (http://swingwt.sourceforge.net/). Need native compilation, sure go ahead, use gcj on Linux or Excelsior JET (Windows or Linux).
Haven’t used any Java apps, eh? sounds like you haven’t been looking. What about NetBeans? or the recently released Dundjinni? What about scientific programs like Imagene or TFCompanion? or any of the trillions of Java image gallery programs. Ok, sure they are not on Joe average’s desktop, but a lot of that is to do with the quality of the Java coders rather than the language (and there are plenty of crappy C++, VB, and C# projects out there too). Mostly Java suffered because it the GUI was unusably slow until v1.4.2
(and SWING is now OpenGL accelerated in v1.5.0 beta2).
Since I program scientific frame grabbers for a living all the camera and grabber vendors who provide a Java interface (Basler, Epix) do a much better job of getting things to work than their MFC equivalents. I been using C++ for 13 years, Java for 7, and C# for 1 in my day job and I still prefer Java – it is merely a matter of taste (and it is easier to lead a team with Java since even programmers who lack enterprise-level architectural skills can’t do too much bad stuff with it, unlike the C++ pointer-wannabe C#).
Java ain’t perfect, but C# isn’t either, not by a long way. You might try and do a little research before you spout on how good C# is. And at least Sun has granted everyone free use of their patent to do their own Java implementations if they like. You can say thay about C# for either Mono or DotGNU can you. Just wait until Mono starts eating into the Visual Studio.NET space and see the lawsuits come out. Did ya think about that?
No, you are wrong. Plenty of users need apps that work on whatever desktop they are using (the future is becoming more heterogenous not less in the O/S space). And developers are sick and tired of using a new API for each platform (I know I am). In the real, real world most companies don’t want to spend all their money porting apps every three years just cause some vendor has made their O/S backwards-compatible but in a painful way. I mean, .NET 1.0 and .NET 1.1 aren’t fully compatible, but you can still run 8 year old Java 1.0 apps on any later Java Virtual Machine. Avoiding the pitfalls of continuous porting is good business sense for any company.
Sorry, your article is little more than your opinion, which seems rather poorly thought out to me.
Going native actually demolishes the purpose of using Java being the only environment capable of loading, verifying and executing the Java Instruction Set (Byte Codes). Why bother with using the Byte Codes when all they need is a compiler for translating Java syntax to machine language. Want to squeeze more juice out from your slug, compile them to machine code.
Don’t put Azureus as usable java app. While it had a million downloads and it is very popular, when I kill it, I get 200MB of RAM back. I’m using the latest Java VM. BitComet (C++ BitTorrent client) uses 25MB of RAM and 0-8% of my CPU time. Java sucks, and will always suck (both the language and the platform). Do you remeber the Sun memo that was leaked? The java language, and the java platform suck on the desktop. Those that have the money for high end servers and high end workstations can run java. Poor users can’t.
Good article. I love his recognition that the user is king. Java is just one example of something intended to make the lives of developers easier that turns out to be meaningless for users.
So what if developers have an easier way to crank out code no one wants to use? Who cares if developers have it easier if they produce applications no one wants to use? No language is going to give a developer skill, insight and imagination.
Software is a tool. So is a hammer. No one buys a hammer because they like the way the hammer maker works.
To an extent you’re right, and to another more important extent you’re wrong.
Making development more productive means more features and better interfaces for the user. If that’s done at the cost of speed most argue “faster hardware will fix it.” I disagree with wasting clock cycles, but some applications seem to work fine, if done right, in Java/python/perl or any other runtime/VM language.
User’s don’t care what you write it in, they just want it to work. And I think there are numerous examples of Java apps that just work. I’ve heard people complain about Limewires speed, but if asked about Kazaa they’ll admit it works better (probably because it lacks the rediculous interface and over abundance of spyware and ads).
It’s about doing things properly as much as using the quickest code. Sit a rotten program with no concern for speed in front of a c++ compiler and watch him write the slowest code you’ve ever seen. Sit a good programmer in front of Java and watch him develop something quick and useful. The language doesn’t make the program, the programmer does.
And yes, Swing is horrible.
I think Javas biggest trouble from a user standpoint is waiting 5-30 seconds extra for the VM to load.
As long as Microsoft is the arbiter of internet standards, up and coming habituals like SWT will never stand a change in this sweltering marketplace. Somethings never change, and in an environment of lightweight toolkits, dinosours like SWT, AWT, EWT, ETT, and TCK have no change to make their time.
When we will see a truly supported, standard, cross-platform toolkit to replace the aging Win32 API? I, for one, am tired of being locked into this single minded line of thought.
Java ain’t perfect, but C# isn’t either, not by a long way. You might try and do a little research before you spout on how good C# is.
There was no reason to bring C# in to this. But since you did, there are real technical reasons why C# is better than Java. I’m sure it’s been discussed here before: Generics+boxing, concurrency support, CLI (Java has no equivalent), anonymous functions. Perhaps you should take your own advice, do some research.
This doesn’t mean you have to go and use C#, by all means use what you are comfortable with. Java is has a lot of support in industry, and is a fine language.
For cross platform API/GUI toolkits, take a look at QT. QT is the basis of KDE, but it is also used for the user interface, db access, sockets, and threading in large commercial softare products such as Adobe, JDEdwards (not PeopleSoft EnterpriseOne), and Opera (just to name three of many).
QT runs on Windows, Linux, Mac OS X, and various Unix flavors. It is a C++ toolkit, thus compiled and features maximum native performance. To run it on different platforms, all it takes is a recompile. QT also supports giving the native “look ‘n’ feel” (and behavior) of the host platform.
QT is also extremely easy to develop with. Even though C++ gets a bad rap for being overly complicated (it’s easier with the STL), C++ development with the STL and the QT libraries is brain-dead easy. It gives easy to use containers, and minimizes the amount of dynamic memory allocation required. And what is required is relatively easy to handle. QT also provides a super easy GUI design environment, featuring point and click widgets.
There are cross platform toolkits that compile natively besides QT (wxWidnows, GTK+, etc.), but QT probably does it the best. Oh, by the way, QT binds with other languages, so if you hate C++, you can still use it.
The overall point here (no I’m not an advertisement for QT 😉 ) is that cross platform code can be acheived with natively compiled C++, and done very easily while maintaining max performance, compitible look and feel and behavior, and max user satisfaction.
Java’s WORA promise is great. But it hasn’t lived up to it’s promise, due to the resource hit of the JVM, the ugliness and slowness of SWING, the inherant difficulties of SWT (combining native GUI with WORA byte code, defeating the purpose), and the complexity of the Java APIs – the Java language itself is straight forward, easier than C++, but it’s the huge, complex APIs that make it difficult.
Already has an almost complete binding to their cocoa framework and using the cocoa-java bridge you can easily call extended java classes from Obj-C.
So why don’t people use Java Cocoa instead of Swing for Apple apps?
> Generics+boxing,
Java 1.5
> concurrency support,
If you mean being able to lock objects, Java has had that from the very beginning, I think.
> CLI (Java has no equivalent),
Errm. That has nothing to do with C# as a _language_.
> anonymous functions
Ok, Java doesn’t have that and higher-order functions, but you can work around it by using interfaces (and instantiating them anonymously).
> So why don’t people use Java Cocoa instead of Swing for Apple apps?
1) Because they look the same.
2) If you use Swing, you get a cross-platform GUI for free.
“So why don’t people use Java Cocoa instead of Swing for Apple apps?”
People don’t use Java Cocoa because it limits them to writing an application for only MacOS. The fact of the matter is that Apple’s market share is so insignificant that this is a waste of time for most developers.
> I think Javas biggest trouble from a user standpoint is waiting 5-30 seconds extra for the VM to load.
gebner@schnecke2 ~/work/jsml [0] $ time sablevm -qYc jsml.jar at.gabrielebner.sml.shell.Eval 5+5
10.0
sablevm -qYc jsml.jar at.gabrielebner.sml.shell.Eval 5+5 0,28s user 0,03s system 101% cpu 0,306 total
So how can the _VM_ alone take up to 30 seconds to load if it takes 0.3 seconds to run a small program? Do you really run SableVM on such a machine?
>>”Making development more productive means more features and better interfaces for the user…”
That doesn’t follow. Better software depends on the imagination, skill and insight of developers. Improved development tools won’t give any developer the imagination, skill or insight needed to create something newer and better than the competition.
I don’t know about Limewire and Kazaa. I’m not thirteen.
“And at least Sun has granted everyone free use of their patent to do their own Java implementations if they like.”
Can someone point me to a document that says this please. And mike … why is this better than ISO and ECMA standards? I know it’s a complicated subject and pattents are not the same as starndards – are pattents stronger than open starndards?
http://msdn.microsoft.com/net/ecma/
oh – sorry, Mike was saying (the ever popular) java is safe while c# + cli is not.
Those things are not real, which means no performance increase in Java 1.5. All that crap in Java 1.5 is just syntax sugar.
>> Generics+boxing,
>
> Java 1.5
No, 1.5’s compiler does the trick. The penalties are still there, only the programmer can type less.
>> anonymous functions
>
> Ok, Java doesn’t have that and higher-order functions, but > you can work around it by using interfaces (and
> instantiating them anonymously).
That’s about the same as saying C is OO:
struct x{ int y; }
int x_get_y(*struct x this_x){ return this_x.y; }
no?
The criticisms of the article aren’t good. To sum it up, the problem of Java is that it is a fair step forward from C++, but it only became available 15+ years later. Java looks like what a mediocre C++ person would build from some good ideas put forth by a Smalltalk one. Add to that that there is a vast amount of people who know some Java, it’s all or most they’ve ever known, and cling to it as the holy writ. They ‘know’, even (and mostly) before they look any alternative, that Java is better. While I can understand this behaviour in many areas, I’m just baffled when it comes to PL.
I mean, who can like having to write 10k of repetitive LOC to do something that can be achieved with half or less in many other languages? At least with C/++ or asm you have the case of speed. But with java?
“Those things are not real, which means no performance increase in Java 1.5. All that crap in Java 1.5 is just syntax sugar.”
Exactly. In Java, generics/boxing are implemented as compiler functionality – essentially, the compiler adds in the boxing/casting, resulting in bulkier code. C#’s implementation is part of the CLI, hence it can be optimized at runtime.
generics/boxing are only a nice extra of C# though – there’s plenty of other functionality that for me makes it vastly better than Java.
Concerning C# the language, structs (pass by value objects) can be quite handy, as can the ability to make use of unsafe code with pointers (though to a lesser degree with this).
Concerning the .net API, its event model (using delegates) is much easier to code for than Java’s interface-based event model. The API’s use of properties is also a nice feature, resulting in cleaner code, and better distinction between what’s being done with an object (ie, whether a method that does something is being called, or whether a simple property is being changed/updated/accessed). Plus the ease of calling platform-specific libraries from C# is several orders of magnitude easier than doing it via Java.
Then there’s the issue of exceptions – as C#’s are all unchecked, there’s no need for convoluted try/check clauses all through the code, or throws statements anywhere. Though this is mostly personal preference, Anders Hejlsberg puts forth a good case for using unchecked exceptions in a series of interviews he did a while back (transcripts are available on MSDN).
Jchempaint: 2D chemical drawing program
Jmol: Molecular model viewer
drawswf: Flash presentation maker
Jdiskreport Disk usage visualization
Jedit: Editor
Batik Squiggle: SVG viewer
Limewire: P2P
RSSowl: News aggregator (cool SWT app)
As a Gnome/XFce4 user I think I use Java apps second only to GTK2 apps – So its on my desktop
Chris said:
Can someone point me to a document that says this please. And mike … why is this better than ISO and ECMA standards? I know it’s a complicated subject and pattents are not the same as starndards – are pattents stronger than open starndards?
The Java patent grant was given by James Gosling whene he stated it explicitly in this interview (and OSNews coverage)
http://today.java.net/jag/page7.html#59
http://www.osnews.com/story.php?news_id=6719
I hope you are not holding your breath for Billy Gates to do the same for Mono and DotGNU.
C# the language and core libraries are under ECMA, which is excellent [and Sun should have done the same for Java], but the useful libraries eg. GUI are not and are patented by Microsoft. Check it out for yourself. You must get a license agreement from Microsoft to develop and deploy a compatible C# implementation (which Miguel has acquired for Novell/Ximian’s development of Mono, but in a recent OSNews positing Miguel indicated this license does not extend to other parties to make an implementation, ie. you). For Java, you can make an implementation but you have to pay Sun to ensure it is compatible (which is a good thing) to be able to call it Java (same as Mesa 3D is “OpenGL” without the name, although a compatibility test kit was donated to Brian Paul).
To A.K.H.
As Gabriel Ebner pointed out, the features you mention are in Java 1.5, eg. generics, autoboxing. Sure I know C# 2.0 has them, but it the free/libre implementations also have huge patent issues too. Java has had synchronisation primitives from the beginning, which is one of the first things you learn about Java (perhaps you too should do some *current* research yourself). Java 1.5 delivers things which are promised in Longhorn (ie. hardware accelerated [OpenGL] general advanced 2D composition, which means Swing themes).
Use C# if you want to, but you should realise GPL license won’t protect you from either patent lawsuit or use of the patent to shut your code down. I would love to use C# in a Free Software project, but the risk is too high (yet still people considering tying Gnome to it )
all i want is simply java-nox.
gnome can stand wihout x.
but normal user doesn’t kernel compile for FB/directFB/opengui/svgalib.
say again, no no no no no no no no no x*/x11.
just saying so publically… this is what makes you feel safe??? Come now, there must be something in writing somewhere…http://java.sun.com/docs/books/jls/second_edition/html/jcopyright.d….
Microsoft has already *said* publically that the v 2 stuff will all be submitted to the existing standards. As for Bill Gates standing up and saying that – get real. But *actions* do speak louder than words – haha, not something I particularily want to argue in microsoft’s favor. but anyhow – I’m not pitting one against the other as it seems you are. It’s been said too many times but there is TONS in addition to windows.forms namespaces etc… that should be safe for those with a queezy stomache. I’ll search for this posting by Miguel you say … but it doesn’t sound right. Post it here if you know where it is.
>>the future is becoming more heterogenous not less in the >>O/S space
link? Sure hasn’t been the trend on the desktop….
Why write a crappy UI that runs on multiple platforms when you can write a nice, fast UI more productively that runs on 95% of desktops?
What do I mean by that? 1) swing apps are slow. Swing apps are now “useable” but I really notice the difference when I switch to a native app (or SWT). And to the author’s point, the swing apps don’t behave the same. Right clicks usually don’t give me context menus, the cursor acts differently when I try to size panels, etc. 2) it’s much easier to write a dot net GUI than a swing UI. I still haven’t seen a decent GUI builder for Swing…you end up having to hand code everything. Dot net does a very nice job providing an excellent GUI builder. You can crank out apps very quickly and they perform much better than Swing.
I don’t see the business case for Java GUIs. Server side apps, yes.
i guess open sourcing java is pointless if there are already open source implementations of it.
there is 99% no chance sun will open source it anyway.. thats what im hearing
“native userinterfaces that integrates in your Windows/MacOS/GTK/QT Desktop.”
This sorta defeats the purpose of true-cross platform ability. I’m sure you could already do this with java if you knwo how.
Python + wxWindows
Native look, feel, and mouse behavior for users, without the memory bloat of JAVA.
Portable for developers.
Problem solved.
> I don’t see the business case for Java GUIs.
Well. A customer asked me for a Linux interface to our hardware so they could integrate it into their system. Most of our stuff is Windows but we had written stuff in cross-platform C++ (since we wanted to port to RTAI real-time Linux) and could give them the driver level code straight away. Unfortunately, no GUI for them. Fortunately, still got a several hundred thousand dollar from an (single!) instrument sale. A Java GUI, though not as slick as Win32, would have been more than enough. So I’m aiming to fix that. Yeah, this is pretty niche, but not everyone writes bloggers and word-processors, and it is a real world example not some academic gedanken experiment.
Oh, and I forgot to mention. IL-2 Sturmovik is a game written largely in Java. Check out http://www.il2sturmovik.com/
Shame it ain’t cross-platform through otherwise I would run it on my cellphone
in one word,
http://www.jython.org
Mike Reid wrote:
> use gcj on Linux or Excelsior JET (Windows or Linux).
A little off-topic, but gcj is not Linux only. It works well on Windows, together with SWT. Since gcj is gcc-based, I think gcj will actually work anywhere gcc works.
So, How do I use native libraries or C# on my Nokia phones – or most other phones for that matter?
I mean – Nokia Series 40 phones is gigantic in europe – am I just to ditch that just because I only use C#?
Use the right tool for the job (TM).
I use Java because it makes sense – I like C# too, but I just dont have any reason to deploy it, and especially not considering a 23MB+ runtime(!) – which isn’t likely to decrease, ever. Java is rather large too, but at least Excelsior Jet can handle that for me
Give me a call when the entire specification, is ECMA’ed – the current core crap is just a joke.
> Concerning C# the language, structs (pass by value objects) can be quite handy, as can the ability to make use of unsafe code with pointers (though to a lesser degree with this).
structs — Use a Class and pass a Class! Wow what a feature.
Unsafe code is called UnSafe for a reason. It’s amazing Microsoft and it’s programmers forgot about Memory Leaks when designing .Net. Just to make it easier to use the Windows API? Again, in Java you don’t need to call the windows api BECAUSE everything is coded in a Java Class.
> Concerning the .net API, its event model (using delegates) is much easier to code for than Java’s interface-based event model.
Opinion — interfaces have been pretty easy for me.
> The API’s use of properties is also a nice feature, resulting in cleaner code, and better distinction between what’s being done with an object (ie, whether a method that does something is being called, or whether a simple property is being changed/updated/accessed). Plus the ease of calling platform-specific libraries from C# is several orders of magnitude easier than doing it via Java.
Why is Microsoft still writing API’s?!?
VB and C# are Class languages? aren’t they?
In Java we get Class libraries, we don’t need no stinking API’s.
> Then there’s the issue of exceptions – as C#’s are all unchecked, there’s no need for convoluted try/check clauses all through the code, or throws statements anywhere. Though this is mostly personal preference, Anders Hejlsberg puts forth a good case for using unchecked exceptions in a series of interviews he did a while back (transcripts are available on MSDN).
Then there’s the issue of NO programmer using Microsoft’s .Net actually coding any code for FileNotFoundException, IOException, AddressException…, Until the code BREAKS IN PRODUCTION.
Great Feature.
There’s a reason Java is Strong in the Enterprise.
And it’s because the language and additional extensions to it have to go thru a JCP: Java Community Process, so we get a Design Review, a Code Review and a Testing phase. None of which I’ve ever seen for any Microsoft language development.
Here’s an example of how to Code an exception to throw it back to the caller.
Take a look it’s really not rocket science:
// bad exception handling: eat the exception
public void setFrom( String sInFrom )
{
try
{
iaFrom = new InternetAddress( sInFrom );
}
catch( AddressException ae )
{
// can’t do anything useful here!
}
}
// pass back to the caller, the caller will know what to do, issue a dialog box // message to fix the address
public void setFrom( String sInFrom )
throws AddressException
{
iaFrom = new InternetAddress( sInFrom );
}
Note, that if you throw the exception back to the caller, there is no try/catch block to code here. It’s now the responsibility of the caller.
You DON’T HAVE TO ReThrow anything.
Had a look at ASP.NET.
That .Net multi-language feature is turning into a nightmare over there.
Each feature is only coded in VB OR C#, not both, so as a developer you have to LEARN BOTH LANGUAGES on the Microsoft platform.
God help us if we actually get Cobol.NET.
On Java there’s just the one language to learn.
Cobol .net
http://www.adtools.com/info/whitepaper/net.html
List of languages that target the jvm other than java
http://www.robert-tolksdorf.de/vmlanguages.html
I’m going to go through your list as best as I can – but it’s seems to me you missed the point on everyone of your points!!
>structs — Use a Class and pass a Class! Wow what a feature.
structs are passed by value and not by reference so they are stored on the stack and not the managed heap. That is a feature.
> Why is Microsoft still writing API’s?!?
The author of the statement to which you are commenting is talking about properties as a feature. not the APIs of win32. Were you listening?? Even at that he was also referring the the .net classes and not win32.
> In Java we get Class libraries, we don’t need no stinking API’s.
so does everything .net. all the stuff you see about unsafe code and the like is to support backward compatibility with pre .net stuff – yes, like the win32 APIs.
>Then there’s the issue of NO programmer using Microsoft’s .Net actually coding any code for FileNotFoundException, IOException, AddressException…, Until the code BREAKS IN PRODUCTION. Great Feature.
You really are a freak aren’t you. The way that java does things to my understanding is that you have to catch an exception or pass it on. This creates overhead on the software that microsoft decided to not incure. Yes, the trade off is that you *can* let errors go by but there is a performance gain and error do evenentually get called by the top most object.
I don’t think you are showing a very good example of exception handling – this actually looks kinda bad – you are catching an exception but burrying it so nobody knows?? Maybe I misunderstood your intent from that mess.
If anyone uses MATLAB 6.5, guess what? The UI is written in Java, but the backend is highly optimized C/assembler. The cool think is that it runs on OS X, Linux and Windows out of the box.
I use other Java apps that are developer oriented (JEdit, Netbeans, PoseidonUML, etc) but MATLAB is the first non-programmer app that I use daily that is written in Java.
I can’t believe how ignorant many people are when it comes to Java exceptions. Java has two types of exceptions:
– Runtime exceptions, these are not checked by the compiler. This is exactly the same as C# exceptions.
– Checked exceptions, these are checked by the compiler and you are forced to declare them in your method signature or catch them.
If you don’t want to pass on a checked exception, just convert it to a runtime exception. A simple example:
void myMethod() {
try {
FileInputStream in = new FileInputStream(“somefile”);
…
}
catch (IOException e) {
throw new RuntimeException(e);
}
}
In my personal experience checked exceptions are great to use when you can reasonably expect the user of your class/method to be able to recover from the exception. Typically this is when communicating with external modules like disk, network, database etc. Otherwise you use runtime exceptions. So, in Java you get the best of both worlds.
so are you saying that java exceptions are better/worse/same as c# or were you just teaching us about java? Yes, Java has Runtime exceptions to handle more serious errors … and …
AFAIK runtime exceptions are meant for “programming errors” like null pointers, array bounds and the like. Things that are caused by bugs in the code and will happen in testing, too. The checked execptions are for events that are triggered by events from the outside, something that can never be ruled out. The only bad thing with checked exceptions is that interfaces like JDBC require you to catch Execptions for every call, even for calls that never throw that exception in your implementation, only because another implementation of that interface might need to throw the exception.
Chris, what Sune was trying to explain is that Java has two kinds of exceptions: unchecked and checked. Your assertion that you must catch exceptions or pass them on is simply wrong. An unchecked exception (RuntimeException and its subclasses) does not have to be caught, nor does it have to be declared in the “throws” clause.
There is a school of thought that says that checked exceptions have proven to be unnecessary. Personally, I think that checked exceptions are a great help in writing fault-tolerant programs. (I.e. any application that has to be deployed in the real world, not a toy or weekend hack.)
Yes, checked exceptions can be a pain to deal with but they do force you to deal with unusual or extreme cases (network failure, I/O error, ill-formed XML, etc.) and consequently make your programs more robust. If you just ignore checked exceptions or blindly rethrow them out of pure laziness, then maybe you should consider switching careers.
That all said, I do think that some Java API’s make unnecessary use of checked exceptions in places. A prime example is JDBC which throws SQLException for basically every method call.
(C# and C++ only have unchecked exceptions.)
chris wrote:
> so are you saying that java exceptions are better/worse/same as c# or were you just teaching us about java?
My point was that you shouldn’t say that Java exception handling is worse than C#, because Java has the same exception handling as C# with the addition of checked exceptions. If you don’t like that a certain class library throws checked exceptions (most people use JDBC as an example), you should complain about that library, not about the Java language.
> Yes, Java has Runtime exceptions to handle more serious errors … and …
Not more serious errors, the “seriousness” of an exception has nothing to do with runtime or checked exceptions.
> AFAIK runtime exceptions are meant for “programming errors” like null pointers, array bounds and the like.
Mostly, yes, but not exclusively.
> The only bad thing with checked exceptions is that interfaces like JDBC require you to catch Execptions for every call, even for calls that never throw that exception in your implementation, only because another implementation of that interface might need to throw the exception.
You’re complaining about JDBC, not the Java langauge. You need to separate the use of checked exceptions from the possibility to use checked exceptions.
If one of the implementations of an interface need to throw a checked exception that is not declared in the interface, I would say that the design of the interface or implementation is incorrect. Someone using the interface shouldn’t need to know anything about the implementation, so all checked exceptions must be declared in the interface. It’s very logical when you think about it.
>If one of the implementations of an interface need to throw a checked exception that is not declared in the interface, I would say that the design of the interface or implementation is incorrect. Someone using the interface shouldn’t need to know anything about the implementation, so all checked exceptions must be declared in the interface. It’s very logical when you think about it.
I would say that the more “throws” clauses an interface declares, the less it is suitable for direct use in an application. Rather, these interfaces should be used through a container (for example: servlets and EJBs) or a framework like Spring(which has a wrapper for JDBC operations).
Haven’t used any Java apps, eh? sounds like you haven’t been looking. What about NetBeans? or the recently released Dundjinni? What about scientific programs like Imagene or TFCompanion? or any of the trillions of Java image gallery programs. Ok, sure they are not on Joe average’s desktop, but a lot of that is to do with the quality of the Java coders rather than the language (and there are plenty of crappy C++, VB, and C# projects out there too). Mostly Java suffered because it the GUI was unusably slow until v1.4.2
These apps are all irelevant to the END USERS the article was talking about. They only matter to developers and geek heads. Those are the only kind of users that run such crap.
“Java image gallery programs”? Give me a break!
No end user ever downloaded a Java program, except Limewire.
And Limewire is far from being a succesful P2P client with massive audience.
(Read “No” as in: “fewer than 10,000”).
P.S I program in Java daily professionaly, and used Eclipse and some other Java stuff (Tomcat, JMeter, FindBugs, etc). But concerning “end users usage” a spade is a spade.
Quite a lot of people use MATLAB, and they aren’t geeks or developers…. In fact, most don’t even know its got a Java interface.
Quite a lot of people use MATLAB, and they aren’t geeks or developers…. In fact, most don’t even know its got a Java interface.
So you tell me mathlab is not for geeks? It’s a bloody mathematics package! The fact that it is available for Unix platforms should give you a clue.
Very far from end user software. This is for geeks in mechanics and academia.
http://www.moneydance.com/
http://www.evermoresw.com/weben/index.jsp
http://www.minq.se/products/dbvis/
Java is, like VB, a language that is well suited for custom software. This is not the kind of software you sell in millions of boxes, but none-the-less it is used by end users.
Hmm…. guess engineers/economists/etc are all geeks then. Great. We’ve got a large club 🙂
Java has shown itself to be ill-suited to client-side apps anyways. But that’s okay, because it’s also shown itself to be uniquely well-suited to server-side apps – “the COBOL of the 90’s”.
So forget client-side Java.
If you need a desktop app, choose either the Windows API of the month or one of the bazillions of Open Source cross-platorm ones.
If you need a robust server-side app, use J2ee with web output. Or if you absolutely need a standalone client-side frontend, use Eclipse.
But client-side Java is the wrong idea. Native widgets are only part of it. For one thing, users continue to have limited patience for slow JVM load times, even when the rest of Java performance has improved markedly. For small client-side projects, Java’s verbose and strangulated syntax makes it unsuitable. For large client-side projects, the difficulty of interfacing with non-Java libraries is a major stumbling block.
Server-side and embedded Java are good platforms. Java on the desktop is a toy. Good for training, not for work.
“Very far from end user software. This is for geeks in mechanics and academia.”
Um, no. Many of the mid-level math classes at my university use MatLab as the standard software for doing homework. Not everyone taking DiffEq is a geek.
-Erwos
thanks laurens – that part I did get though. I guess what I was try to provoke was the comparison of c# to java exceptions which was a carry-on from someone else’s post I think. This topic seems to come up rather often and I’m not sure if Java and c# exceptions are created equally or not. What do you know about this?
“thanks laurens – that part I did get though.” and it was appreciated.
Matlab’s java UI is both ugly, slow and cumbersome. If you ask me, its slowness is its lightest fault.
And yes, it’s standard wherever Maths is needed. That doesn’t make it less geeky. I doubt anyone uses it for non-professional work.
The point is, going back to the article, about the only good thing MATLAB derives from its java part is that it is easier (is it really?) for its developers to port it. There is zilch from it for the user.
after looking at unchecked exception handling in c# and java I don’t agree with you – they are not exactly the same. There are differences in the Java language and it’s not an issue to take up with the class designer.
Not much more to say.
For the purpose of working with an API, C# and Java are virtually (though not exactly) identical in how they handle unchecked exceptions. The try/catch/finally idiom works the same in both languages
Now back to checked exceptions. The advantage of checked exceptions is that they become part of the API itself. When you call a method you must take into account the checked exceptions it throws, just as you must take into account the parameters you pass to it and the return value it generates. If a checked exception doesn’t get handled somewhere in the call chain, the compiler signals an error.
IMO, the big disadvantage of unchecked exceptions is that they must be documented explicitly. (The compiler won’t signal that you are leaving the exceptions unhandled.) This is 1) more work for the API designer, who has to document all exceptions that a method might throw and make sure that documentation and source code are, indeed, in sync, and 2) more work the API user, who has to look up the exceptions in the documentation or, worse, in the source code itself.
Hence I think that checked exceptions contribute to writing faul-tolerant programs. (Still, they should be used sparingly.) As a language mechanism, checked exceptions force you to look at the different ways that a program might fail. More in general: checked exceptions serve as a reminder that even with all the niceties that the Java language offers, writing real-world applications is still a *lot* of work.
If you’re really interested in this topic, this page gives a good overview of the differences between C# and Java:
http://www.25hoursaday.com/CsharpVsJava.html
Of particular interest to this discussion is the section on checked exceptions:
http://www.25hoursaday.com/CsharpVsJava.html#checked
Hope this helps.
http://www.moneydance.com/
http://www.evermoresw.com/weben/index.jsp
http://www.minq.se/products/dbvis/
Are you kidding me? Why not mention Jedit too, while you’re at it!
These “applications” are even less used than Limewire.
I never said there are no Java desktop applications. Just that NOBODY uses them, for values of nobody >= 10.000 people.
This application is stuff all three people use.
The only popular Java applications are cellular phone’s games, where lack of a binary application standard makes Java a viable solution (and makes cellular games about 50% less efficient than what they could be).
Are you kidding me? Why not mention Jedit too, while you’re at it!
These “applications” are even less used than Limewire.
I never said there are no Java desktop applications. Just that NOBODY uses them, for values of nobody >= 10.000 people.
And what does that have to do with the programming language? Not many PC users use Linux, but you don’t see people complaining that its because of C. The fact is, desktop applications that are written in Java do exist. *Some* of these are good applications that have poor market penetration due to the developers lack of clout. Its got nothing to do with the programming language used.
the fact that all the examples listed as sufficiently responsive Java apps are geek apps is valid. all it means is that for some reason the companies that are usually involved in developing non-technical end user apps have not invested in getting good java programmers or – because of attitudes similar to those expressed in this forum – they are not even going to concider it.
take for example the anti-desktop-java people on this forum. if you were going to build an app today would you concider java? from your responses i can assume the answer to be no due to your pre-concieved opinions of the language, outdated or not, knowledgeable or not.
and this is the REAL point. people are going on pre-concieved notions. a perfect example is the mac – the age old excuse of the fact that not enough applications exist is still being used. while it may be slightly true for custom apps (the number is getting less and less though) for the majority of the same user group that we are discussing still use that excuse as well.
ask them what they use everyday – MS Office, IE, Netscape, WMP, various P2P APPS, etc. There’s thousands more but once you take Office and IE you have covered at least 75% of the population. but people still throw out this excuse – and its not just the enterprise/development people, just like people throw this thing about java when applications that are 10 times more sophisticated than anything they will ever use are being developed that are responsive.
if anyone wants to write an article like this it should be focused on the tools and their making things easier to write good code. this a valid issue that vendors are aware of and are addressing. also, an article that is intellectually honest would go out of its way to mention this (ie. the current focus of many of the specs/JSRs at the moment is on increasing productivity and simplicity for everyone – developers and end users) but the the author diliberately leaves these out and the end result is debates like the one we are having now. if he had punched holes in the various “simplifying” JSRs then we would have something to discuss. this “user is king” is a veiled attempt at objectivity while being lazy to actually research the industry and see whether the vendors are doing anything and whether the proposed solutions will suffice.
Mike Reid wrote:
And at least Sun has granted everyone free use of their patent to do their own Java implementations if they like.
Turns out this is a not really as it seems. Please be sure to read carefully the Java “copyright” notice where the supposed “patent grant” is:
http://java.sun.com/docs/books/jls/second_edition/html/jcopyright.d…
It amounts to pretty much saying, “we have this toy, and if you’d like to make your own toy that looks like ours, you have to do it *our* way!”. Aside from the fact that, the idea of what they’re offering is ludicrous to begin with (“you can write your own Java implementation, but do it like we say or else”), there’s also the fact that *no* Free software Java implementation follows their “rules” that are listed there anyway.
Maybe I should copyright my likeness, and make a rule that says anyone can draw a picture of my face, but if you do, you can’t put a funny curly mustache on it!
What needs to happen is, the community needs to support GCJ & Classpath, which might also happen to push Sun to put up or shut up. Since GCJ/GCC and Classpath are both GNU projects, Sun would have to take the FSF to court if they wanted to try and enforce their wierd hybrid copyright-license. Since it is currently unenforced, and is also unenforceable, it would be thrown out.
By the way, for any folks who note that Swing is too slow, GCJ’s/Classpath’s Swing/AWT implementation is coming along quickly. My guess is that natively compiled Java Swing apps will be noticeable faster (and start up faster) than their interpreted counterparts. I’m currently on OS X for the moment (GCJ + Swing for OS X is not quite ready yet), but perhaps a GNU/Linux user / Java dev might be interested doing a comparison?
Well I said Swing is a failure and I stand by that, but I’m not against desktop java apps. In fact I’m writing one now using SWT and will be deployed using either JET Excelsior or GCJ.
But I’ve always thought that Sun was full of it when they claimed that WORA was something that people really cared about or that non-native Swing was a good thing.
See JDIC:
https://jdic.dev.java.net/