|
Just add that option to your javac command, or project options in NetBeans. Alternatively find the deprecated method you are calling and change it for the latest version; the documentation will tell you how.
BTW the link in your title links back here.
|
|
|
|
|
Thanks Richard MacCutchan it really helps me.
For those who don't know here's the details
It's just for NetBeans IDE 7.0.1 I don't know how to do it on other IDE.
1. Right click on your project you can see it on the left side of the IDE project tab and select properties.
2. In the project property window just click compiling on the left side of the window.
3. Find this option after clicking the compiling "Additional Compiling Options:" it is located on the lowest side and add your compiling option in my case I add this on the textbox.
-Xlint:deprecation
4. Click OK and your done.
5. Try debugging your project and your will see a message like this on the output option of debugging.
C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java:93: warning: [deprecation] disable() in javax.swing.JComponent has been deprecated
cmbTime.disable();
C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java:190: warning: [deprecation] disable() in javax.swing.JComponent has been deprecated
cmbTime.disable();
C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java:206: warning: [deprecation] enable() in javax.swing.JComponent has been deprecated
cmbTime.enable();
Hope this helps. I really google it and there's no detailed info on how to do it. I am thankful to Richard MacCutchan for saying its on the project option.
|
|
|
|
|
I am providing an interface to one of my products as a 'C' language DLL, compiled using Microsoft Visual Studio 2008. The interface may be used in a Java application. I don't know Java, so I could use some guidance on things I need to do in my DLL to make it as easy to use as possible.
The functions in my DLL only take arguments in the form of 32-bit signed integers, pointers to integers, and constant UNICODE (const wchar_t*) strings, and return 32-bit signed integers. I would like to let them use callback functions with similar signatures. The target environment could be Windows XP, Windows 7 (32-bit), or Windows 7 (64-bit).
I've done some preliminary reading, and it appears that Java Native Access[^] (JNA) is the easiest way for a Java client to use functions in a DLL like this.
Are there any gotchas I need to be aware of?
Software Zen: delete this;
|
|
|
|
|
Personally I would fully encapsulate the DLL.
Where I've done this before, I have used a pure interface class mapping to the dll, but kept it package level.
Then create a public class that accesses the DLL.
This gives future proofing, for example if you need to move to a new version of windows and the API [shock! horror!] changes you only need to update the internal DLL interface and not the entire project.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Hmm. I should have made this clearer.
I'm mainly concerned about how to do things in the functions the DLL provides:
Are const wchar_t * strings okay? Or should I use const char *, and insist on UTF-8 encoding (these are things like file paths)?
I assume returning values via int * arguments will work?
Can I use callback functions? I have asynchronous events that I would like to use a callback function for. The caller would pass the DLL a function pointer, which I would then call as needed for an event.
Software Zen: delete this;
|
|
|
|
|
|
Very  Richard. I had seen the JNA, but hadn't read too much about it. Thanks!
Software Zen: delete this;
|
|
|
|
|
Thanks; I have only used JNI myself, and although it's a bit of a learning curve it works well. From my reading of the JNA documentation that may be an easier option.
|
|
|
|
|
I don't actually want to give the users of this DLL the Java required to use it. They have a pronounced case of "Not Invented Here" syndrome. I'm just trying to reduce the amount of grief I get from them.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I don't actually want to give the users of this DLL the Java required to use it.
In that case they will have to write it (via JNA/JNI) themselves; but that is their choice. Alternatively you could ask them to give you the Java code they want to use and then you (or someone who knows Java) write the interface to the DLL. Ultimately one of you will have to produce the Java specification and code.
|
|
|
|
|
what happen when main method is declare private?
SGS
|
|
|
|
|
Sarika G Shinde wrote: what happen when main method is declare private?
The Java run time will not be able to find it. It's declared public and static for a reason; that is, so the JRE can load it by finding the method via reflection without needing to know any specific details about the class other than its name.
|
|
|
|
|
One slight err. When you build a jar, the main class is declared so the JRE knows exactly which method to call..
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Yes, I had not considered jars (see below), but that's because it's not obvious which class in the jar has the main method.
Normally when I think of jars I have ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) in mind.
|
|
|
|
|
Nagy Vilmos wrote: When you build a jar, the main class is declared so the JRE knows exactly which method to call..
No.
When you build an 'executable jar' that is the case. And there are generally other constraints that one must deal with when creating that specialized jar.
Most jars are not of that type but can certainly have a main method. Actually they can have many main methods since each class can have one.
|
|
|
|
|
I think Willie's answer was quite correct in the context of this question.
|
|
|
|
|
Re-reading several times I still don't see that.
|
|
|
|
|
Well since you confirm it in the first sentence of your response I cannot understand what it is that you don't see.
|
|
|
|
|
Because 'jar' does not equal 'executable jar'
No more than 'programming language' equals 'java'.
In each the second is is a subset of the first.
In each there are many more cases of the first than the second.
In each there are many specific details that impact the second.
|
|
|
|
|
I said "within the context of this question" where it is fairly obvious we (i.e. everyone except you) are talking about executables.
|
|
|
|
|
The JRE requires a method with the signature:
public static void main(String [] args)
It must be public, or else it can't be accessed.
It must be static as it is called before anything has been instantiated.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Nagy Vilmos wrote: The JRE requires a method with the signature
If you are using Java 1.5 or later you can also use the signature:
<br />
public static void main(String... args)<br />
There is a difference between the two, although not really significant for a main method. The following works with the vararg signature, not with the array signature:
<br />
MyClass.main("A", "B");<br />
This will not compile if you are using the main(String[] args) form. But how often do you do this with a main method anyway?
|
|
|
|
|
j
modified on Tuesday, September 13, 2011 8:00 AM
|
|
|
|
|
This is far too much code for anyone to read through. Explain what you are trying to do, what fails, and where it goes wrong.
|
|
|
|
|
I'll give you some general tips to start with:
0. The client needs to run on two threads, one to receive messages and one to send. Normally the main thread will be the sending thread and also the UI.
1. I would separate the communication from the processing into two classes. Have another class in the server, something like ClientSession that deals with any logic. This would have the name of the client session and a reference to the main chat server.
2. As with the connection, the server should be separated into UI and logic. By having these separated it will eb clearer to see what is what. A simple call-back from the server will update the UI.
3. Check your names, you have so many different styles it becomes confusing. Do not use underscores. All variables should use camel case likeThis and classes should be pascal case ThisWay.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
