The 2.0 packages are in OSGeo4W for testing and wokshop use at FOSS4G. 2.0 will be announced at FOSS4G.
It's not considered a final build yet, or an official release, as there is still some minor things to sort out.
Watch @qgis, QGIS on Facebook, QGIS on Google+, and qgis.org for the offical release announcement.
You are still free to use the 2.0 package from OSGeo4W just be aware like I said it's not an official release just yet.
I rarely use the OSGEO4W shell, although I have it because I used it to download some utilities. If you have QGIS you have most of the GDAL tools in the QGIS install directory already. If you prefer you can download 32 and 64 bit GDAL/OGR from http://www.gisinternals.com/sdk/ I did because I wanted the lib and include files but find that version works well with the utilities as well.
In order to use GDAL/OGR on the command line without invoking the shell you must set some environment variables so that required files can be found; I use windows so the environments are windows flavored but I assume that Mac and Linux are similar.
// GDAL folders from http://www.gisinternals.com/sdk/
GDAL_DATA C:\Program Files\GDAL\gdal-data // csv's and stuff
GDAL_DRIVER_PATH C:\Program Files\GDAL\gdalplugins // gdal_ECW_JP2ECW.dll, gdal_HDF6.dll...
GEOTIFF_CSV C:\Program Files\GDAL\gdal-data // csv's and stuff
PROJ_LIB C:\Program Files\GDAL\projlib // nad.lst...
PATH %PATH%;C:\Program Files\GDAL // GDAL_TRANSLATE.exe ...
// QGIS folders
GDAL_DATA C:\Program Files\QGIS Dufour\share\gdal // csv's and stuff
GDAL_DRIVER_PATH C:\Program Files\QGIS Dufour\bin\gdalplugins // gdal_ECW_JP2ECW.dll, gdal_HDF6.dll...
GEOTIFF_CSV C:\Program Files\QGIS Dufour\share\epsg_csv // csv's and stuff
PROJ_LIB C:\Program Files\QGIS Dufour\share\proj // nad.lst...
PATH %PATH%;C:\Program Files\QGIS Dufour\bin // GDAL_TRANSLATE.exe ...
After you have set these environment variables GDAL should work just fine in a normal command (cmd) window.
Interrogate your PATH environment before setting, you might find the path already contains the right folder. Be aware that when windows searches for programs it looks in the current folder and then the paths (separaed by semi-colons ';') from first to last, earlier instances in the path will be executed as soon as there's a match! The order of extensions, unless implicitly supplied (like do_this.py is calling specifically for a python file), is governed by the pathext environment (usually .COM; .EXE; .BAT; .CMD; .VBS; .VBE; .JS; .JSE; .WSF; .WSH; .MSC)
For example: when you call gdal_translate the system looks in the current folder for a file called gdal_translate (not case sensitive) and then looks in the first path, the next and all the paths and then if it's not found returns 'is not recognized as an internal or external command operable program or batch file.' so it is not really needed to modify the path if you are in the folder that the program is.
Best Answer
You can see the source code for a gdalinfo java implementation here - https://svn.osgeo.org/gdal/trunk/gdal/swig/java/apps/gdalinfo.java
The polygonize function should be available in the java bindings, you may look at the source of gdal_polygonize.py to see how it's used - http://svn.osgeo.org/gdal/trunk/gdal/swig/python/scripts/gdal_polygonize.py