I am using eclipse to develop a web application. Just today I have updated my struts version by changing the JAR file. I am getting warnings at some places that methods are deprecated, but the code is working fine.
I want to know some things
Is it wrong to use Deprecated methods or classes in Java?
What if I don't change any method and run my application with warnings that I have, will it create any performance issue.
1. Is it wrong to use Deprecated methods or classes in Java?
From the definition of deprecated:
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
The method is kept in the API for backward compatibility for an unspecified period of time, and may in future releases be removed. That is, no, it's not wrong, but there is a better way of doing it, which is more robust against API changes.
2. What if I don't change any method and run my application with warnings that I have, will it create any performance issue.
Most likely no. It will continue to work as before the deprecation. The contract of the API method will not change. If some internal data structure changes in favor of a new, better method, there could be a performance impact, but it's quite unlikely.
The funniest deprecation in the Java API, is imo, the FontMetrics.getMaxDecent. Reason for deprecation: Spelling error.
Deprecated. As of JDK version 1.1.1, replaced by getMaxDescent().
You can still use deprecated code without performance being changed, but the whole point of deprecating a method/class is to let users know there's now a better way of using it, and that in a future release the deprecated code is likely to be removed.
Terminology
From the official Sun glossary:
deprecation: Refers to a class, interface, constructor, method or field that is no longer recommended, and may cease to exist in a future version.
From the how-and-when to deprecate guide:
You may have heard the term, "self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.
The #Deprecated annotation went a step further and warn of danger:
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
References
java.sun.com Glossary
Language guide/How and When to Deprecate APIs
Annotation Type Deprecated API
Right or wrong?
The question of whether it's right or wrong to use deprecated methods will have to be examined on individual basis. Here are ALL the quotes where the word "deprecated" appears in Effective Java 2nd Edition:
Item 7: Avoid finalizers: The only methods that claim to guarantee finalization are System.runFinalizersOnExit and its evil twin Runtime.runFinalizersOnExit. These methods are fatally flawed and have been deprecated.
Item 66: Synchronize access to shared mutable data: The libraries provide the Thread.stop method, but this method was deprecated long ago because it's inherently unsafe -- its use can result in data corruption.
Item 70: Document thread safety: The System.runFinalizersOnExit method is thread-hostile and has been deprecated.
Item 73: Avoid thread groups: They allow you to apply certain Thread primitives to a bunch of threads at once. Several of these primitives have been deprecated, and the remainder are infrequently used. [...] thread groups are obsolete.
So at least with all of the above methods, it's clearly wrong to use them, at least according to Josh Bloch.
With other methods, you'd have to consider the issues individually, and understand WHY they were deprecated, but generally speaking, when the decision to deprecate is justified, it will tend to lean toward wrong than right to continue using them.
Related questions
Difference between a Deprecated and Legacy API?
Aside from all the excellent responses above I found there is another reason to remove deprecated API calls.
Be researching why a call is deprecated I often find myself learning interesting things about the Java/the API/the Framework. There is often a good reason why a method is being deprecated and understanding these reasons leads to deeper insights.
So from a learning/growing perspective, it is also a worthwhile effort
It certainly doesn't create a performance issue -- deprecated means in the future it's likely that function won't be part of the library anymore, so you should avoid using it in new code and change your old code to stop using it, so you don't run into problems one day when you upgrade struts and find that function is no longer present
It's not wrong, it's just not recommended. It generally means that at this point there is a better way of doing things and you'd do good if you use the new improved way. Some deprecated stuff are really dangerous and should be avoided altogether. The new way can yield better performance than the deprecated one, but it's not always the case.
You may have heard the term, "self-deprecating humor". That is humor that minimizes your importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that it should no longer be used at all, as it will probably cease to exist in the future.
Try to avoid it
Generally no, it's not absolutely wrong to use deprecated methods as long as you have a good contingency plan to avoid any problems if/when those methods disappear from the library you're using. With Java API itself this never happens but with just about anything else it means that it's going to be removed. If you specifically plan not to upgrade (although you most likely should in the long run) your software's supporting libraries then there's no problem in using deprecated methods.
No.
Yes, it is wrong.
Deprecated methods or classes will be removed in future versions of Java and should not be used. In each case, there should be an alternative available. Use that.
There are a couple of cases when you have to use a deprecated class or method in order to meet a project goal. In this case, you really have no choice but to use it. Future versions of Java may break that code, but if it's a requirement you have to live with that. It probably isn't the first time you had to do something wrong in order to meet a project requirement, and it certainly won't be the last.
When you upgrade to a new version of Java or some other library, sometimes a method or a class you were using becomes deprecated. Deprecated methods are not supported, but shouldn't produce unexpected results. That doesn't mean that they won't, though, so switch your code ASAP.
The deprecation process is there to make sure that authors have enough time to change their code over from an old API to a new API. Make use of this time. Change your code over ASAP.
It is not wrong, but some of the deprecated methods are removed in the future versions of the software, so you will possibly end up with not working code.
Is it wrong to use Deprecated methods or classes in Java?"
Not wrong as such but it can save you some trouble. Here is an example where it's strongly discouraged to use a deprecated method:
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
Why is Thread.stop deprecated?
Because it is inherently unsafe.
Stopping a thread causes it to unlock
all the monitors that it has locked.
(The monitors are unlocked as the
ThreadDeath exception propagates up
the stack.) If any of the objects
previously protected by these monitors
were in an inconsistent state, other
threads may now view these objects in
an inconsistent state. Such objects
are said to be damaged. When threads
operate on damaged objects, arbitrary
behavior can result. This behavior may
be subtle and difficult to detect, or
it may be pronounced. Unlike other
unchecked exceptions, ThreadDeath
kills threads silently; thus, the user
has no warning that his program may be
corrupted. The corruption can manifest
itself at any time after the actual
damage occurs, even hours or days in
the future.
What if don't change any method and run my application with warnings that I have, will it create any performance issue.
There should be no issues in terms of performance. The standard API is designed to respect some backward compatibility so applications can be gradually adapted to newer versions of Java.
Is it wrong to use Deprecated methods or classes in Java?
It is not "wrong", still working but avoid it as much as possible.
Suppose there is a security vulnerability associated with a method and the developers determine that it is a design flaw. So they may decide to deprecate the method and introduce the new way.
So if you still use the old method, you have a threat. So be aware of the reason to the deprecation and check whether how it affects to you.
what if don't change any method and run my application with warnings that I have, will it create any performance issue.
If the deprecation is due to a performance issue, then you will suffer from a performance issue, otherwise there is no reason to have such a problem. Again would like to point out, be aware of the reason to deprecation.
In Java it's #Deprecated, in C# it's [Obsolete].
I think I prefer C#'s terminology. It just means it's obsolete. You can still use it if you want to, but there's probably a better way.
It's like using Windows 3.1 instead of Windows 7 if you believe that Windows 3.1 is obsolete. You can still use it, but there's probably better features in a future version, plus the future versions will probably be supported - the obsolete one won't be.
Same for Java's #Deprecated - you can still use the method, but at your own risk - in future, it might have better alternatives, and might not even be supported.
If you are using code that is deprecated, it's usually fine, as long as you don't have to upgrade to a newer API - the deprecated code might not exist there. I suggest if you see something that is using deprecated code, to update to use the newer alternatives (this is usually pointed out on the annotation or in a Javadoc deprecated comment).
Edit: And as pointed out by Michael, if the reason for deprecation is due to a flaw in the functionality (or because the functionality should not even exist), then obviously, one shouldn't use the deprecated code.
Of course not - since the whole Java is getting #Deprecated :-) you can feel free to use them for as long as Java lasts. Not going to notice any diff anyway, unless it's something really broken. Meaning - have to read about it and then decide.
In .Net however, when something is declared [Obsolete], go and read about it immediately even if you never used it before - you have about 50% chance that it's more efficient and/or easier to use than replacement :-))
So in general, it can be quite beneficial to be techno-conservative these days, but you have to do your reading chore first.
I feel that deprecated method means; there is an alternate=ive method available which is better in all aspects than existing method. Better to use the good method than existing old method. For backward compatibility, old methods are left as deprecated.
Related
I've read this post about how inherently unsafe ruby's timeout method is, but I it looks like JRuby has natively implemented the Timeout class and I was wondering if those issues are still relevant in JRuby 1.7? From what I can decipher from the source, it looks like there is a reusable thread pool being used so that should take out a lot of the performance issues of launching a new thread for every single use, but I was wondering about the safety issues, specifically for when its being used extensively in Net::HTTP. Is there some kind of mutex locking going on to solve those safety problems now? (sorry i don't know java well enough to tell definitively from the source).
Long question short: is Timeout::timeout, and by extention Net::HTTP which uses it a ton, safe and performant to use in JRuby 1.7?
Yup, still unsafe in general:
No timeout library can solve this problem unless they are able to guarantee they'll never fire within any ensure blocks
Although, when used in Net::HTTP around pieces of code that don't have any ensure blocks, it should probably be fine I'm guessing. (Though they should really be using nonblocking io and select)
This question already has answers here:
Why shouldn't I use mysql_* functions in PHP?
(14 answers)
Closed 9 years ago.
When I attempt to connect to a MySQL server from PHP, I see the following error:
Deprecated: The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /path/to/filename.php on line 123
The code on the referenced line is:
mysql_connect($server, $username, $password);
I am certain that the arguments are correct, and this exact code has been working for years without problem. Indeed, I obtained it from a well-sourced tutorial on PHP.
Why is this happening?
How can I fix it?
I understand that it's possible to suppress deprecation errors by setting error_reporting in php.ini to exclude E_DEPRECATED:
error_reporting = E_ALL ^ E_DEPRECATED
What will happen if I do that?
Why is this happening?
The entire ext/mysql PHP extension, which provides all functions named with the prefix mysql_, was officially deprecated in PHP v5.5.0 and removed in PHP v7.
It was originally introduced in PHP v2.0 (November 1997) for MySQL v3.20, and no new features have been added since 2006. Coupled with the lack of new features are difficulties in maintaining such old code amidst complex security vulnerabilities.
The manual has contained warnings against its use in new code since June 2011.
How can I fix it?
As the error message suggests, there are two other MySQL extensions that you can consider: MySQLi and PDO_MySQL, either of which can be used instead of ext/mysql. Both have been in PHP core since v5.0, so if you're using a version that is throwing these deprecation errors then you can almost certainly just start using them right away—i.e. without any installation effort.
They differ slightly, but offer a number of advantages over the old extension including API support for transactions, stored procedures and prepared statements (thereby providing the best way to defeat SQL injection attacks). PHP developer Ulf Wendel has written a thorough comparison of the features.
Hashphp.org has an excellent tutorial on migrating from ext/mysql to PDO.
I understand that it's possible to suppress deprecation errors by setting error_reporting in php.ini to exclude E_DEPRECATED:
error_reporting = E_ALL ^ E_DEPRECATED
What will happen if I do that?
Yes, it is possible to suppress such error messages and continue using the old ext/mysql extension for the time being. But you really shouldn't do this—this is a final warning from the developers that the extension may not be bundled with future versions of PHP (indeed, as already mentioned, it has been removed from PHP v7). Instead, you should take this opportunity to migrate your application now, before it's too late.
Note also that this technique will suppress all E_DEPRECATED messages, not just those to do with the ext/mysql extension: therefore you may be unaware of other upcoming changes to PHP that would affect your application code. It is, of course, possible to only suppress errors that arise on the expression at issue by using PHP's error control operator—i.e. prepending the relevant line with #—however this will suppress all errors raised by that expression, not just E_DEPRECATED ones.
What should you do?
You are starting a new project.
There is absolutely no reason to use ext/mysql—choose one of the other, more modern, extensions instead and reap the rewards of the benefits they offer.
You have (your own) legacy codebase that currently depends upon ext/mysql.
It would be wise to perform regression testing: you really shouldn't be changing anything (especially upgrading PHP) until you have identified all of the potential areas of impact, planned around each of them and then thoroughly tested your solution in a staging environment.
Following good coding practice, your application was developed in a loosely integrated/modular fashion and the database access methods are all self-contained in one place that can easily be swapped out for one of the new extensions.
Spend half an hour rewriting this module to use one of the other, more modern, extensions; test thoroughly. You can later introduce further refinements to reap the rewards of the benefits they offer.
The database access methods are scattered all over the place and cannot easily be swapped out for one of the new extensions.
Consider whether you really need to upgrade to PHP v5.5 at this time.
You should begin planning to replace ext/mysql with one of the other, more modern, extensions in order that you can reap the rewards of the benefits they offer; you might also use it as an opportunity to refactor your database access methods into a more modular structure.
However, if you have an urgent need to upgrade PHP right away, you might consider suppressing deprecation errors for the time being: but first be sure to identify any other deprecation errors that are also being thrown.
You are using a third party project that depends upon ext/mysql.
Consider whether you really need to upgrade to PHP v5.5 at this time.
Check whether the developer has released any fixes, workarounds or guidance in relation to this specific issue; or, if not, pressure them to do so by bringing this matter to their attention. If you have an urgent need to upgrade PHP right away, you might consider suppressing deprecation errors for the time being: but first be sure to identify any other deprecation errors that are also being thrown.
It is absolutely essential to perform regression testing.
From reading revision N3242 of the c++11 draft, it appears that some components of the standard library's interfaces (notably threading and locking) depend on exception handling.
Since I do a lot of work with exceptions disabled, I am wondering which library components/features will be (practically or logically) unusable without exception handling enabled?
First of all (just as a reminder), disabling exceptions and RTTI are compiler specific extensions the Standard has no consideration for.
Since the Standard Library is usually tied to the compiler, it may be that your implementation of the Standard Library has been specifically designed to cope with this (and in particular, to cope with new returning null pointers instead of raising std::bad_alloc).
Therefore, what you ask for is non-sensical. Check the documentation of your own library for a complete list.
That being said, the Standard does guarantee that a number of operations will never throw. I don't know of any operation that swallows exceptions, I would suppose that most of them are actually safe to use as-is.
For example, all algorithms should be safe.
Still, once again, I can only recommend reading the documentation of your implementation.
This question is over one month old, and unanswered.
I am providing an answer which can be considered a community wiki, add to it as needed.
std::thread Section 30.2.2. Transitive. Abstraction implemented using native implementations.
std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex. Section 30.4.1, Intransitive if you supply your own exception free locking (via BasicLockable, Lockable, TimedLockable). Abstraction implemented using native implementations.
std::condition_variable Section 30.5. Transitive. Abstraction implemented using native implementations.
note: There will be more.
I always end up using my own minimalistic wrapper for JSON-RPC (because it's trivially simple): am I missing out on something compared to standard libraries?
Yes it's simple. In past I took similar approach as yours and had my own minimal json-rpc implementation. Now I use jsonrpc2 for a fairly complex application. What I was missing earlier
Didn't have batched call support
All error code supported
better tested library
more goodies like rpc processor (check jsonrpc2's documentation)
other obvious advantages of open source :-)
If your looking for a .net jsonrpc2 server. Check out http://jsonrpc2.codeplex.com/
I would also add to Shekhar's list
Speed of development by skipping the 'roll your own' step.
Cost - is most cost effective to use a library supported by the community.
Its likely better tested, and more stable then a roll your own solution.
Performance of the json-rpc server is likely better then you would get with a roll your own solution.
** maintainability ** There is documentation around Json-Rpc 2. Another developer will be able to contribute on your project or fix bugs better if the protocol has a defined spec. They may be familiar with it already.
In the case of Json-Rpc.net, to make a method a json-rpc method, all you have to do is add an attribute to the method. So another plus for using a real json-rpc implementation.
I'm not looking so much for language-specific answers, just general models for implementing a plugin system (if you want to know, I'm using Python). I have my own idea (register callbacks, and that's about it), but I know others exist. What's normally used, and what else is reasonable?
What do you mean by a plugin system? Does Dependency Injection and IOC containers sounds like a good solution?
I mean, uh, well, a way to insert functionality into the base program without altering it. I didn't intend to define it when I set out. Dependency Injection doesn't look particularly suitable for what I'm doing, but I don't know much about them.
A simple plugin architecture can define a plugin interface with all the methods the plugin ought to implement. The plugin handles event from the application, and can use the application's standard code, model objects, etc. to get things done. Basically the same as an ASP.NET Form does, except that you're overriding rather than implementing.
Nobody taught me this part, and I'm no expert, but I feel: In general a plugin will be less stable than its application, so the application should always be in control and only give the plugin periodic opportunities to act. If a plugin can register an Observer, then calls to the delegate should be tried/caught.
There is a very good episode of Software Engineering Radio, which you may be interested in.
For future reference, I have reproduced here the "Rules for Enablers" (alternative link) given in the excellent Contributing to Eclipse by Erich Gamma, Kent Beck.
Invitation Rule - Whenever possible, let others contribute to your contributions.
Lazy Loading Rule - Contributions are only loaded when they are needed.
Safe Platform Rule - As the provider of an extension point, you must protect yourself against misbehavior on the part of extenders.
Fair Play Rule - All clients play by the same rules, even me.
Explicit Extension Rule - Declare explicitly where a platform can be extended.
Diversity Rule - Extension points accept multiple extensions.
Good Fences Rule - When passing control outside your code, protect yourself.
Explicit API Rule - separate the API from internals.
Stability Rule - Once you invite someone to contribute, don?t change the rules.
Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.
In Python you can use the entry-point system provided by setuptools and pkg_resources. Each entry point should be a function that returns information about the plugin -- name, author, setup and teardown functions, etc.
How about abstract factory? Your base program defines how the abstract concepts interact with each other, but the caller has to provide the implementation.