On Thu, Oct 04, 2012 at 04:02:05PM +0100, Andrew Ross wrote: > On Wed, Oct 03, 2012 at 07:35:01PM -0700, Alan Irwin wrote: > > On 2012-10-03 23:27+0100 Andrew Ross wrote: > > > > > This [revision 12238] all still works fine for me with openjdk on Ubuntu. > > > > > > It still leaves the issues with running the examples using openjdk > > > with Debian testing (but not with Ubuntu). Do the examples run fine > > > with gcj? > > > > Yes. test_noninteractive gives > > > > java > > Missing examples : > > Differing postscript output : > > Missing stdout : > > Differing stdout : > > > > I guess if openjdk works find on Ubuntu but not on Debian, and other > > Debian java tool chains such as gcj also work fine at run time, we can > > write off the openjdk on Debian run-time errors you observe as due to > > some specific Debian packaging error for openjdk. > > I suspect it is more a version issue (Debian testing is a more recent > build of openjdk).
Interestingly I've been unable to reproduce this with plplot svn head and openjdk-6 from Debian unstable in a pbuilder chroot environment so perhaps it is a transient issue. > > > Of course, for gcj there is the long-standing issue of lots of build > > warnings, e.g., (just to pick the the ones associated with x00.java) > > > > /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/java/x00.java:55: > > warning: The static field plplotjavacConstants.PL_PARSE_FULL should be > > accessed directly > > pls.parseopts( args, PLStream.PL_PARSE_FULL | > > PLStream.PL_PARSE_NOPROGRAM ); > > ^^^^^^^^^^^^^ > > /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/java/x00.java:55: > > warning: The static field plplotjavacConstants.PL_PARSE_NOPROGRAM should be > > accessed directly > > pls.parseopts( args, PLStream.PL_PARSE_FULL | > > PLStream.PL_PARSE_NOPROGRAM ); > > > > ^^^^^^^^^^^^^^^^^^ > > 2 problems (2 warnings) > > > > After some experimentation I finally discovered the warnings are completely > > squelched by > > using this call to parseopts instead. > > > > pls.parseopts( args, plplotjavacConstants.PL_PARSE_FULL | > > plplotjavacConstants.PL_PARSE_NOPROGRAM ); > > > > but before we turn all our java examples into this form, is there a > > way to shorten the name of the plplotjavacConstants names down within > > each example to say pls_con? > > > > I hope this result puts you on the track of completely solving these > > warning messages while also using a short alias of the name of the > > plplotjavacConstants namespace. > > > > If you do find an aliased solution, please commit it to x00.java, and > > I can do the rest of the editing of the java examples myself to help > > take some of the PLplot load off you. > > I think again this warning is a new gcj-4.7 features. I've checked > with gcj-4.6 on Ubuntu and there were only 3 warnings, all now fixed. > I could fix this by deriving a new class with a shorter name which > inherits from the plplotjavaConstants class, but that is an ugly > solution. I'd tend just to stick with the long name for now, or try to > get swig to generate a shorter name. This would be an API change > however... I'll investigate if there are any neater ways of achieving > this. Turns out that what we were doing is no longer recommended (see for example http://www.javapractices.com/topic/TopicAction.do?Id=32). I've implemented an alternative method using the static import feature to import all the plplot constants into the current namespace for the examples. Personally this doesn't seem like a particularly nice workaround, but it is neater than using the full plplotjavacConstants interface namespace for all the constants. I've also cleaned up all the unnecessary casts. Again I'm not sure this is a really good thing. The casts make it absolutely clear that the type is changing even if they are not strictly required and avoid those hard to track down rounding problems that can occur otherwise. Anyway, these changes make the gcj compile of the java examples free of warnings. Andrew ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
