GUI: the look and feel of the Graphical User Interfaces written in Java using Swing may not be the same as the widget look and feel of the underlying operating system. For example, on almost every Windows system, the Swing look & feel differ significantly from the GUI look and feel of the native applications. One possible solution is AWT, but it has its own limitations regarding the support of high-end widgets.
Floating point Arithmetic: Java largely supports IEEE 754 floating point arithmetic, but certain features are not supported even with the use of the ‘strictfp’ modifier in Java. For example, IEEE 754 recommends Exception Flags and Directed Roundings, but these features are not supported in Java.
Bytecode: while bytecodes make Java a portable language to a great extent, they cause the performance to slow down to a certain extent as well. If you use Java Interpreter while running the bytecodes on a certain JVM, then it’s considerably slower than the usual native code execution on that platform as the process adds an extra phase of translation of the bytecode instruction into the corresponding native code instruction. If we use JIT compiler to convert entire bytecodes into native code during load time or runtime, then also it incurs an initial penalty for the completion of the compilation. So, JIT compilation may be inconvenient especially for those applications which are either short-lived or which contain large amount of code. In the first case, the penalty will be too frequent while in the latter case, the penalty will be one time only, but this initial penalty will be huge :-)
Automatic memory management: Java uses the automatic garbage collector to handle all the memory management and the programmer has no control on it. Even, the execution of the garbage collection can not be controlled by the programmer. System.gc() will only result in a possible increment of the priority of the next garbage collection execution and that too is dependent on the particular J2EE implementation as the specification mandates nothing regarding this. If you deliberately want to free some important system resources like DB Connection, File Handles, etc. then you’re helpless and you got to rely on the sporadic execution of the garbage collection to do that for you. If you have enough system resources then you may not mind this, but in a crunch situation you’ll certainly not appreciate this limited/no control on memory management.
Different JVM for different platform: this is what makes Java a portable language, which is undoubtedly one of the major reasons for the popularity of Java, but it has its own share of limitations as well. Most of the implementations usually follow all the specifications, but they add certain implementation-specific flavors as well. If you somehow use any of those features then you compromise with the portability of your code. Even worse, your implementation may not be up-to-date with the latest specifications as well and this will cause compatibilities issues for the code written on an updated implementation. Having an implementation lagging in years with other popular implementations is not that bizarre either :-)
Being too strict may bother you: Java, being a strictly type-safe language, may pose certain problems to your comfort level with other languages which are comparatively generous. Automatic bounds checking for arrays, automatic virtual function indirection, run-time type checking, etc. may add little more inconvenience especially when you’re trying to prototype sample applications/modules/programs just to check certain functionality or maybe just to try and find few solution approaches to choose the best from. Extensive exception handling (usually a boon for the developers) will require you to write many lines of extra code for the successful compilation of the program. This may bother you while writing test-code/prototype.
Read more - Why Java doesn't have Clear Screen functionality? This article tries to explain why we can't have such functionalities in Java. It covers Java 6 updates as well.
 |
RSS Feed (xml)
15 comments:
another limitation is that you cannot ( easily ) make a commad line driven prgram in java... something we do in c/c++ eg linked list program enter 1 to add node , enter 2 delete node ... even if you make one , it will break the paradigm of write once run any where.. more details to follow !!
Lavnish: we can easily achieve the same thing using I/O in Java as well. It may not exactly look like a command line input, but the purpose gets solved easily. Why to consider that as a limitation then? Can you plz explain?
To give a precise answer ... It would defeat the purpose of platform-independance, since not all platforms have the concept of a "console".
For full details check out
http://lavnish.blogspot.com/2008/05/clear-screen-in-java.html
also pls elaborate on ... "the same thing using I/O in Java as well" ... How can you use I/O to clear a DOS Console .. or a Linux console ?
Lavnish: I couldn't sort of gather from your first comment that you were talking about clear screen kinda thing. I thought by saying 'you cannot ( easily ) make a commad line driven prgram in java..' you compared the ease with which we accept input from the user in C/C++ and the same in Java. That's why I wrote 'It may not exactly look like a command line input, but the purpose gets solved easily..'
Anyway, now it's quite clear what exactly you wanted to say. I believe we are on the same page now :-)
Thanks for explaining that to me.
Good interaction guys... Keep it up! This will certainly make this place far better for everyone of us.
Thanks Lavnish for raising the point. Excellent post.
~Geek
Vijay .. i was thinking in some other terms ... as we know that the System.out is an object of class PrintStream .. I check the API ... http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#out thinking that there may be some function like PrintStream.clear() , but ( ?? wonder why ?? ) thats not the case
because even if NOT all platform support concept of CONSOLE ... all platform will run System.out.println("hello") somewhere ... so System.out.clear() also makes sense .. simply clear the output ...
Again to contradict my self ... in servlet if i write System.out.println("hello") .. it goes to log file ... is it ok for System.out.clear() to CLEAR all the logs ( of present & past ) by ALL users ??
I think NO
probably can google for more input on this
People (like me :-)) who are not very comfortable with the details of IEEE standard can go through this wiki link (http://en.wikipedia.org/wiki/IEEE_floating-point_standard) to understand the 'Limitations of Java: IEEE' better.
Thanks Manish for sharing the link. I believe, it's be good read for all of us. Added the link to the post.
~Geek
Clear Screen functionality has not been implemented in Java as it's simply not possible without sacrificing the Platform Independence feature. There are few platform dependent workarounds to achieve it, but the best way still remains the same - using JNI.
In Java, we don't have the concept of a typical console as we have in C/C++. Instead everything is treated as a stream only in Java. I don't think Clear Screen can be implemented for a stream as the steam may point to a file, a printer (this will be a real challenge, isn't it?), or may be to a console on certain systems. Since, you never know what this stream would be pointing to at run time, you can't assume it to be a console and have that functionality. Clear Screen will obviously make sense only for clearing the console and certainly not for a file (logs etc.).
System.out.println() is far more easier to implement in all environments maintaining platform independence as irrespective of what the stream points to at runtime, it can always be written on. That's why 'printf()' works fine in all environments in case of C/C++ (Now in Java also ... Java 5.0 onwards) and not 'clrscr()'.
Even in C++, clear screen function is not part of a class based on streams. It's a separate method altogether and it has a specific implementation only for those environments which have the concept of Console.
Similar explanation can be given for other related platform dependent task such as 'accepting input without ENTER getting pressed - a functionality getch() provides in C/C++', 'applying font color, background color, etc. on the console', and so on. Such tasks have not been implemented consistently across platforms in C/C++, so forget about Java. The goals of Java will probably never allow such tasks to be implemented not at least by using standard library functions. You got to use platform-dependent vendor specific packages to achive them unless of course, all the environments start following the same standards for console and other related stuff.
Sorry for posting such a long comment, but I hope the information helps at least to some extent. Thanks Lavnish for raising such an important point. I'm planning to post an article mentioning all this as most of our visitors may skip such an important topic by not reading the comments section of the current post.
Contradicting my self I recently discovered ... Recently learnt that with Java 6 , Its very much possible ...
In Java 6 a better way of interacting with the command prompt was introduced, the java.io.Console class.
Together with the utility class java.util.Scanner introduced in Java 5 this new API can be used to develop more advanced Java console applications.
For more detaisl checkout
http://java.dzone.com/news/console-applications-java-6
http://java.sun.com/javase/6/docs/api/java/io/Console.html
Java 6.0 has gone C/C++ way to facilitate better interaction with character-based console devices by using standard library functions. It seems that it wasn't possible for them to have such features for traditional Java Streams and hence they created a new Java Class named java.io.Console. This Class is mainly for reading from and writing to the Console and not for clearing it (as of now).
The Sun Java Doc of this class clearly says that the class contains methods to access the character-based console device, if any, associated with the current JVM. We can obviously see a compromise with Platform Independence here as the code written using this Class can never be guaranteed to behave uniformly across all platforms and hence not portable. System.console() method simply returns 'null' on the platforms which doesn't have an associated Console with the underlying JVM.
On the platforms where it finds a Console, it probably uses JNI internally to get the task done. We always have such solutions provided by third party vendors and the only good thing about the addition of this new class is probably that it's now a part of the standard library and it might be having little more efficient code than the code supplied by the third party vendors.
BTW, the center of our discussion 'Clear Screen functionality' is still not there in this class. Let's see if at all they provide that also in the newer releases of Java.
The bottom line remains the same - we would probably never have any such functionality without compromising Platform Independence and in most of the cases the APIs would probably be using JNI only. A true Java solution to this problem still remains a topic of research. So, I don't think you (Lavnish) contradicted yourself. It's just that they made few of the functionalities available in Std Lib. But, a true Java solution wasn't available earlier and it's not available even now. Let's see if they can really come up with one.
U simply rock Geek. So nice post with lots of info and then so informative comments. Great!
Thanks for all the kind words Rohit. I hope you'll keep finding the place interesting. Keep visiting/posting!
Post a Comment