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.
12-Factor Apps suggest that you configure your application using environment variables. So far, so good. I can easily imagine that this is a good way to do it if you need to set a connection string, e.g.
But what if you have more complex configuration with lots and lots of values? I for sure do not want to have 50+ environment variables, do I?
How could I solve this, and still be compliant to the idea of 12-Factor Apps?
From a quick read of the configure link you provided, I agree with the author's claim that there is a widespread problem, but I am not convinced that their proposed solution is going to always be best. Like you, I don't relish the idea of having to define dozens of environment variables to configure an application. So here are some alternative ideas.
First, read Chapter 2 of the Config4* Getting Started Guide (disclaimer: I am the main author of that software). In particular, notice that its support for what I call adaptive configuration can go a long way towards addressing the concern that you ask about. Is Config4* the ultimate solution? Possibly not, but I think it is a good step in the right direction.
Second, the chances are that whatever application you are developing/maintaining has already settled on a particular configuration technology, such as XML files or Java property files, and it won't be feasible to migrate to using Config4*. This raises the question: is there anything you can do to avoid having a proliferation of, say, XML-based configuration files when you have multiple environments (such as dev, UAT, staging and production) in which the application will be deployed? I have outlined an approach for dealing with this issue in another StackOverflow article.
I'm a bit new to actionscript, but find myself investigating good programming practices from other OO languages (java/C#) into an actionscript environment. I've given Mock4as and mockito-flex a purusal and was interested in using both.
Has anyone had good/bad experiences using either?
I started out mocking for FlexUnit with mock4as, and it does its job. But it made me spend way too much time writing boilerplate code for my taste. I haven't tried mockito-flex, but I'll check it out - the Java version I really like.
Recently, I've been really happy with mockolate. Drew Bourne does a really nice job with that - give it a try!
I have had excellent experience with Mockito-flex for the past couple years. The primary reason I enjoy Mockito-flex over Mocholate is that Mockito lets you test your code using the actual class signatures, thus refactor tools will update your Tests.
Mocholate on the other hand requires that you hardcode the method names with a string, which means no auto-complete help when your creating your tests, and poorer refactoring support if any if you rename and API.
While less important, Mockito is available for multiple languages. This means that you can use the same mocking syntax in your entire tech stack. Or you can more easily transfer you mocking skills to another language.
I am looking to do some work around mysql and node.js and have found a few different modules out there but I cannot get a good bead on their stability/maturity. I know each author puts very hard work into each one, but for the work we're doing I need to know I've got a solid mysql foundation. The modules I've found that look pretty good are:
db-mysql This appears pretty active.
node-mysql This is a pretty pervasive module I've seen so far, it appears to be in a maintenance phase, and seems solid.
node-mysql-native I like the async work being done here, but I'm not sure how well it works yet.
node-mysql-libmysqlclient I'm not sure about this one, but it appears to be active as well.
I don't have many needs that are too far out of the ordinary. I need regular query support, extras would be nice, I just need a good foundation to start from. Any input as to the strengths and weaknesses of these modules would be great. If there is another quality contender I have not found I am not at all against considering another option.
I'm the author of node-mysql-native driver, from my point of view the differences are
no prepared statements support (yet) in node-mysql
according to my benchmarks node-mysql is 10-20% slower than node-mysql-native
node-mysql has much wider adoption, more tests and users. If you need stability, better use it
node-mysql-libmysqlclient is 2 to 3 times faster on fast queries. However, if you have a lot of slow queries and use connection pools it could be even slower than native JS driver because libmysqlclient async calls are based on nodejs thread pool and not on event loop.
update
As of 11/07/2013
(2). no longer valid (mysql-native is a bit slower than node-mysql)
have this alternative to node-mysql, on some benchmarks it's 2-3 times faster, has same API + support for prepared statements, SSL and compression. Also implements simple subset of server side protocol - see for example MySQL -> Postgres proxy.
node-mariasql is also a very good option (if it's ok to use binary addon) - fast, stable, async, prepared statements support, compression and SSL.
I went through a similar search and ended up settling on node-mysql. I like it's simplicity, the fact that it's pure js, and that it's well supported. It was slower in tests that I did than some of the mixed modules (those that used non-js libs), but I did a minor patch that helped considerably with that for my cases:
https://github.com/geochap/node-mysql
I'm trying to find a library to access a database from an OCaml program. After trying ocaml-sqlite, I'm not satisfied, since it's somewhat slow.
I've seen a MySQL module, but it doesn't seem to be maintained.
Have you checked the Caml Hump? It has links to plenty of database bindings.
Good, mature, bindings that I can recommend are PG'OCaml by Richard Jones and postgresql-ocaml by Markus Mottl. They are both targeted at Postgresql (which is a probably a better choice for you considering you're into Ocaml).
ocaml-mysql works without problems here - mysql api for connect/query/fetch doesn't change that much :)
It lacks prepared statements though, had to implement mysql_stmt_* wrappers myself.
I'm quite surprised that you find the ocaml-sqlite bindings slow. sqlite is fast on its own, and I believe the sqlite bindings are very well written. You should make sure you're using the up-to-date binding from Markus Mottl's page
If your database is PostgreSQL, I recommend ocaml-postgresql. (There is also ocaml-sql, which makes some SQL operations more convenient when using ocaml-postgresql.)
Since PG'OCaml heavily relies on the OCaml's compile-time type system, it is impossible to compose queries at runtime, which makes it, in my opinion, not useful in most real-world scenarios.