Can I use Java NIO2? - nio

I am working on a project where I've to implement Distributed File System, so for I/O operations, I was thinking of using NIO2 (JDK7)
JDK7 will be released in August next year.
My questions are:
Would it be good idea to use NIO2 from snapshot of JDK7 ? What problems can I face?
If I compile my code which uses both JDK6 and JDK7 classes is it possible to compile using JDK7 ?

1 - Would it be good idea to use NIO2 from snapshot of JDK7 ? What problems can I face?
For a student / research project I see no major issues, apart from the general ones like:
new APIs may still be in a state of flux, and may change without notice,
you are more likely to encounter JDK/JRE/JVM bugs, and
people who want to try out your project have to use JDK 7.
For a project that needs to go into production before the actual release of JDK 7, you probably should be more cautious.
2 - If I compile my code which uses both JDK6 and JDK7 classes is it possible to compile using JDK7?
You cannot be certain until you actually try it, but I'd be very surprised if the answer is anything other than "yes". The Java team are very aware of the need to maintain backwards compatibility.
(However, it is unlikely that you'll be able to compile using JDK 6 ... unless they decide that it is technically feasible and worthwhile to provide a backport of the feature for JDK 6. For something like NIO2, it could be "no" on both counts.)


Do ubuntu, gcc later version cover older versions?

My professor is using automated scoring program for my programming assignment. It is C programming handling some file stuff.
He asks students to use Ubuntu version 18.xx and gcc 7.xx. and I asked him if I can use the later version of those, which are 20.xx, 9.xx respectively. and he's not so sure about it with saying that might not be the problem but just in case use the exact version.
I don't want to delete the current Ubuntu, gcc and re-downloaded the exact version he mentioned, because it might take some time and I have to keep using this laptop for many more assignments from other classes. I want to use the later version (seems like quite a big gap between 18.xx, 7.xx and 20.xx, 9.xx)!
Are there any potential problems for using my current version?
It would also be possible to check the default standard of the gcc version used by your teacher and use the corresponding std flag : "-std=c11" for example.
(I'm unfortunately in a rush and can't check it yet but when I have more time, I can try to look it up if you still didn't get the information)
It may also be possible that he already uses a specific standard, in that case it's better to ask him.
Bugs might arise but I think it would be pretty negligible if you use the same standard.
Otherwise if you are using a Debian based distro you can also install his gcc version alongside your actual one and use them with "update-alternatives".
If not you can use a Docker container.
Something to look for is also if you are going to use OS specific library or functions : For example Windows is not POSIX compliant so I had to use WSL but linux (and mac aswell if I remember correctly) are.

netbeans 6.1 - cannot gets a variable type hovering the mouse on it

On the netbeans that I am using, I cannot do a basic thing such hovering the mouse over a variable and getting its type as shown in the below picture.
How can I obtain this behaviour?
On my system there is windows XP, Netbeans 6.1 and my application is a Vega7000 Application
Why are you using such an old version? It may well be a bug or simply a missing feature.
So answer is, upgrade!
If you need the old version for release builds, you can perhaps still do the actual development and debugging using a newer and shinier version.
Also, if you are not using one yet, use source control! I prefer git, but this is very subjective, other DVCS are good too. And note that so called distributed VCS works extremely well locally inside one source tree directory, it does not have to be distributed to many places. When working with old fragile complex code you are afraid of breaking, very frequent local commits, and diffing to known-good versions when problems arise are life savers. If you care about publishing work in progress, at least git (presumably all DVCS) allow squashing multiple commits into one before pushing to non-personal repo or branch.

Is there a complete example/tutorial (or at least an alternative to wxODBC) for CodeBlocks + Postgres

I am just starting to program Code::Blocks with Postgres. I haven't tried any other DB platform either with it.
So far I've found that DB connections and coding can be done using wxODBC. wxWidgets is what I use for the UI. I found this:
But I found these lines regarding postgres on the web page.
Does not support the keywords 'ASC' or 'DESC' as of release v6.5.0
Does not support sub-queries in SQL statements
So I'm concerned about even the simplest queries being able to run.
My key question: Is there a complete example/tutorial on how to use wxODBC with Code::Blocks? If so, I'd appreciate a link.
Secondary questions:
If there's such an elementary problem, what is the workaround?
Is wxODBC the default way of doing things or is there a better/easier way of doing it?
A million thanks!
After much searching AND testing, I have come up with the following conclusions as my answer and I hope this will benefit others considering the use of wxWidgets with C++.
There is documentation on but this is not very useful because of the way it's presented.
There's a samples folder that you get with wxWidgets. This provides quite a number of complete examples. Unfortunately if you're a new coder to code::blocks, you'll have trouble opening these projects. This is because most of them are not meant for or built with code::blocks but with other systems like Borland C++ or MS VC++. But you can still open the files using your editor or code::blocks.
I'd advise against the use of wxODBC because with different DB platforms it has different issues. Two such cases are shown in my question above. But I guess this is a 'phase' of the project and I hope it gets fixed. And until then, it's not for me or any other serious business that plans to use my combination (C++ with Postgres).
wxODBC is not the default. there's no such thing as the default. But libpqxx is the standard way of doing things and it's very popular. But it has no GUI support and a lot of conversions to and from wxWidgets is needed when working with PG (at least).
So in conclusion, I am compelled (at least for now), to go with libpqxx for C++ on Code::Blocks.
You should know that wxODBC is essentially dead, it was dropped in the 2.9 branch and won't be in 3 which is due to come out soon. You should probably not consider it at all for new code.

Compatibility of dynamic lib(.so) version

I have a software compiled and running on centos 5, Now i am intrested in running it on Centos 6, unmodified without compilation on new machine.
Here is the challenge:-
My process requires certain lib say but centos 6 has newer version say
I am able to make old software work with any of below hacks
create a symlink( to
copy to new machine(centos 6)
What is recommended between two and are there any known issues with this approach, compiling on centos6 would be my last option.
Creating a sym link like that will sometimes work, depending on what exactly the changes were that led to the new version - they would have to be minimal changes that especially did not remove access to any routines/variables that the old library had or drastically change the signature of any of the routines/variables that remain. If the library uses symbol versioning (like the gcc standard C library does), it's possible the .2 version still contains the full API the previous version provided, but I don't know off the top of my head if libpcap does that...
If the new library does not encapsulate the old API, your safest bet is to recompile. If your application is not mission-critical, and/or you can deal with crashes and the possibility of corrupted data, it shouldn't hurt (much) to just try the sym link route...

Program development

I am writing a C program. What I have seen from my earlier experiences is that I make some changes on a correct version of my program, and after that change, the program is computing incorrectly.
Now, for one occasion it may be easy to detect where I made that change and undo it or do it in some other way, and for other occasions I find it hard (with labor) to detect where exactly the problem is.
Can you suggest some platform or tool which allows you to put the new version and old version of the program side by side and mark the changes that were employed on the new version.
I am using gcc 4.3.2 to compile c programs on Ubuntu 10.04 OS.
Any suggestion is welcome.
Use a version control system. I recommend Subversion. This will allow you to compare your newer version with the older one to see exactly what changed and you can revert to the older working version if you break your code.
If you want a tiny, small, portable, one-file personal control version system, I can suggest fossil. A documentation is available here.
What you are requesting is some diff-like tool. There is a plethora of such tools, ranging from the diff command line utility to GUI frontend such as Most of these tools can be combined with (or have counterparts in) revision control systems as Subversion.
I would do this with some version control system, like Git. Refer to Git for beginners: The definitive practical guide if you're new to version control systems and/or git.
Thats the main purpose of all the version control management software.
I recommand to look at Subversion, GIT or Mercurial.
There are thousands of internet resources for this programs.
And they all have good comparision programs integrated in their GUI Tools.
Also, try to use Git/Mercurial/whatever together with Dropbox, it will allow you to continue developing on other computers. It will also teach you how to collaborate with others and with yourself.
This is slightly easier to do with the newer VCS systems like Git and Mercurial.
If you would use a version control system, such as Git or Mercurial, and follow a few good practices:
committing small, self contained changes (which includes committing, i.e. saving changes to version control, often)
committing known good state (or at least trying to, e.g. ensuring that code compiles before you commit)
you would be always able to go back to known good state.
If bug is/was in your current changes, you can compare current state with previous version: somewhere in changed lines there is bug... or something in changed lines uncovered an existing bug.
If bug was introduced by some earlied, unknknown commit, you can use bisect to search through history to find first commit that exhibits given bug: see for example git bisect manpage.