MM NumericStepper Bug

Hi,
I'm having a strange behaviour with the NumericStepper placed
inside a non-modal Window.
Prelude:
I have made a setup in which I have a "stage" with placed
objects. When one object is selected, I show its parameters in a
window created via the PopupManager. An event is fired up to update
the content of the window.
Problem:
When one object is selected after an other (the contentpath
of the Window is replaced with the new parameters set or the same)
the value of the NumericStepper is changed correctly, but the
display of it (Label or inputField?) disappear.
And worse, when I force a redraw on the component, (with
myValue_ns.redraw(true); ) the downArrow shows below the
component... (an other bug?)
Question:
Is there a way to force the Label or inputField to redraw? Or
what should I do to have a normal behaviour??
Any idea is welcome!!
thanks all!

Similar Messages

[svn:fx-trunk] 8025: NumericStepper keyboard bug

Revision: 8025
Author:   [email protected]
Date:     2009-06-19 17:06:30 -0700 (Fri, 19 Jun 2009)
Log Message:
NumericStepper keyboard bug
http://bugs.adobe.com/jira/browse/SDK-21887 - NumericStepper no longer increments via keyboard keys
Added keyDown listener in capture phase to NumericStepper. Add/remove listeners in the focusIn/Out handler.
QE Notes: None
Doc Notes: None
Bugs: SDK-21887
Reviewer: Alex
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-21887
    http://bugs.adobe.com/jira/browse/SDK-21887
Modified Paths:
    flex/sdk/trunk/frameworks/projects/flex4/src/spark/components/NumericStepper.as
    flex/sdk/trunk/frameworks/projects/flex4/src/spark/components/Spinner.as

error dateField not selecion date 27/11/2002 ?
This is bug flex 3 ?
thanks

[svn:fx-trunk] 5465: Now that padding set on a TextInput does not affect the inner textView, we need to add a custom TextInput skin for the TextInput a Spark NumericStepper contains .

Revision: 5465
Author: [email protected]
Date: 2009-03-20 11:52:56 -0700 (Fri, 20 Mar 2009)
Log Message:
Now that padding set on a TextInput does not affect the inner textView, we need to add a custom TextInput skin for the TextInput a Spark NumericStepper contains. Jim ok'ed the addition of the new FxNumericStepperTextInputSkin.mxml class into the spark.skins and wireframe packaged.
SDK-18275, SDK-19849
Reviewer: Glenn
Checkintests: Pass
Ticket Links:
http://bugs.adobe.com/jira/browse/SDK-18275
http://bugs.adobe.com/jira/browse/SDK-19849
Modified Paths:
flex/sdk/trunk/frameworks/projects/flex4/src/mx/components/FxNumericStepper.as
flex/sdk/trunk/frameworks/projects/flex4/src/mx/skins/spark/FxNumericStepperSkin.mxml
flex/sdk/trunk/frameworks/projects/wireframe/src/wireframe/FxNumericStepperSkin.mxml
Added Paths:
flex/sdk/trunk/frameworks/projects/flex4/src/mx/skins/spark/FxNumericStepperTextInputSkin .mxml
flex/sdk/trunk/frameworks/projects/wireframe/src/wireframe/FxNumericStepperTextInputSkin. mxml

Revision: 5465
Author: [email protected]
Date: 2009-03-20 11:52:56 -0700 (Fri, 20 Mar 2009)
Log Message:
Now that padding set on a TextInput does not affect the inner textView, we need to add a custom TextInput skin for the TextInput a Spark NumericStepper contains. Jim ok'ed the addition of the new FxNumericStepperTextInputSkin.mxml class into the spark.skins and wireframe packaged.
SDK-18275, SDK-19849
Reviewer: Glenn
Checkintests: Pass
Ticket Links:
http://bugs.adobe.com/jira/browse/SDK-18275
http://bugs.adobe.com/jira/browse/SDK-19849
Modified Paths:
flex/sdk/trunk/frameworks/projects/flex4/src/mx/components/FxNumericStepper.as
flex/sdk/trunk/frameworks/projects/flex4/src/mx/skins/spark/FxNumericStepperSkin.mxml
flex/sdk/trunk/frameworks/projects/wireframe/src/wireframe/FxNumericStepperSkin.mxml
Added Paths:
flex/sdk/trunk/frameworks/projects/flex4/src/mx/skins/spark/FxNumericStepperTextInputSkin .mxml
flex/sdk/trunk/frameworks/projects/wireframe/src/wireframe/FxNumericStepperTextInputSkin. mxml

[svn:fx-trunk] 8530: Change Slider and NumericStepper default value

Revision: 8530
Author:   [email protected]
Date:     2009-07-13 11:17:46 -0700 (Mon, 13 Jul 2009)
Log Message:
Change Slider and NumericStepper default value
http://bugs.adobe.com/jira/browse/SDK-18380 - FxHSlider and FxVSlider have default max of 100, should be 10
Changed the default value for Slider by setting the value to 10 in the constructor. I changed NumericStepper?\226?\128?\153s implementation to match Slider. The problem with NumericStepper?\226?\128?\153s previous implementation was that it wasn?\226?\128?\153t calling Range?\226?\128?\153s maximum setter. Thus there was some important logic in Range.commitProperties that wasn?\226?\128?\153t called.
QE Notes: Update tests with new default
Doc Notes: Update docs with new default
Bugs: SDK-18380
Reviewer: Hans
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-18380
    http://bugs.adobe.com/jira/browse/SDK-18380
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/NumericStepper.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/supportClasses/Slider.as

[svn:fx-trunk] 11208: More styling bug fixes:

Revision: 11208
Author:   [email protected]
Date:     2009-10-27 16:30:03 -0700 (Tue, 27 Oct 2009)
Log Message:
More styling bug fixes:
- Add borderAlpha, borderColor, and borderVisible to NumericStepper
- Make LinkButtonSkin respond to cornerRadius, rollOverColor, and selectionColor
- Draw opaque white background behind data grid header so contentBackgroundColor doesn't bleed through
- ItemRenderer/DefaultItemRenderer no longer draw contentBackgroundColor. In the "normal" states, the background of the renderer is transparent so the skin background color shows through.
QE Notes: 5 DataGrid bitmaps need to be regenerated.
Doc Notes: None
Bugs: SDK-23437, SDK-23367, SDK-23351, SDK-23345, SDK-23339
Reviewer: Kevin, Ryan
API Change: no
Is noteworthy for integration: No
tests: checkintests gumbo/components/NumericStepper components/DataGrid
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23437
    http://bugs.adobe.com/jira/browse/SDK-23367
    http://bugs.adobe.com/jira/browse/SDK-23351
    http://bugs.adobe.com/jira/browse/SDK-23345
    http://bugs.adobe.com/jira/browse/SDK-23339
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/NumericStepper.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/supportClasses/ItemRenderer .as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/skins/spark/DefaultItemRenderer.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/skins/spark/NumericStepperSkin.mxml
    flex/sdk/trunk/frameworks/projects/sparkskins/src/mx/skins/spark/DataGridHeaderBackground Skin.mxml
    flex/sdk/trunk/frameworks/projects/sparkskins/src/mx/skins/spark/LinkButtonSkin.mxml

This bug figures out also when creating a custom spark ComboBox, then trying to programatically update the userProposedSelectedIndex property. The proposed selected index is selected, but does not apply the same skin as when mouse is on rollover or item is selected due to up and down keys.
The issue seems like updating the status of the item renderer to rollover or selected to get the same skin applied.
Please could you attach DropDow nList.as that you edited ?
Thank you so much.

Some problems with NumericStepper, IME, Japanese Numeric Characters

Hello World!
I've some problems to input Japanese Numeric Characters in NumericStepper.
I work on Mac OSX 10.6.8 with Debug Flash Player 10.3.183.x and I built my project with SDK 4.5.1.
I've made a sample project to debug it. This project has a TextArea and a NumericStepper.
I've switched my IME to "Hiragana" characters.
I can put every characters in TextArea. But when I want to put a numeric value in NumericStepper. There are just the characters typed with the numeric keypad, which are considered.
for exemple :
numeric keypad characters : 123 (considered)
japanese numeric characters (above the alphabetic characters on the keyboard) : １２３ (not considered)
I've tried many different combination with :
IME.enabled
IME.conversionMode
IMEConversionMode.ALPHANUMERIC_FULL
focusIn/focusOut on NumericStepper to change IME behavior.
imeMode option on NumericStepper
But I never found a clever solution.
It's very boring for my Japanese Customers.
I've scoured google without found a solution.
What should I do to make NumericStepper accept numeric characters Japanese?
I hope you can help me.
Thanks!

Hi,
Thank,
Ok, I've done it.
The issue ticket : http://bugs.adobe.com/jira/browse/SDK-31732

[svn:fx-trunk] 8591: Fix for SDK-18328 - NumericStepper not stripping leading zeroes upon commit .

Revision: 8591
Author:   [email protected]
Date:     2009-07-15 12:39:05 -0700 (Wed, 15 Jul 2009)
Log Message:
Fix for SDK-18328 - NumericStepper not stripping leading zeroes upon commit.
Bugs: SDK-18328
QE Notes: None
Doc Notes: None
Reviewer: Deepa
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-18328
    http://bugs.adobe.com/jira/browse/SDK-18328
Modified Paths:
    flex/sdk/trunk/frameworks/projects/framework/src/mx/controls/NumericStepper.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/NumericStepper.as

NumericStepper with stepSize=0.1 set value to NaN

I have a spark NumericStepper :
<s:NumericStepper value="0" stepSize="0.1" />
When I first click on the NumericStepper to increment the value, it goes from "0" to "0.1", it's ok.
But when I click again to increment or decrement, it displays "NaN".
I debug the NumericStepper and it seems my default locale is fr_FR and it waits for the "," decimal separator instead of "."
But if I try to set stepSize="0,1" I have a compilation error because 0,1 can't be cast to a Number.
Is it a bug ? is there a workaround to have a decimal stepSize with french locale ?

There are really two separate issues here:
(1) Halo NumberValidator produces a validation error for decimal values when locale is set to fr_FR
(2) Spark NumericStepper does not change decimal separator based on locale
I will file a separate issue for the Halo NumberValidator issue. The issue filed by Bill can be used to track the decimal separator not changing based on locale.
As a workaround, you can change the way the value is displayed by the NumericStepper by using the valueFormatFunction and valueParseFunction.
For example, the following will replace the "." decimal separator with a ",".
<fx:Script>
<![CDATA[
private function myFormatFunc(val:Number):String
return val.toString().replace(".",",");
private function myParseFunc(val:String):Number
var stringVal:String = val.replace(",",".");
return Number(stringVal);
]]>
</fx:Script>
<s:NumericStepper id="ns" stepSize="0.1" value="0" valueFormatFunction="myFormatFunc" valueParseFunction="myParseFunc"/>

[svn:fx-trunk] 10905: NumericStepper needs a textFieldClass style.

Revision: 10905
Author:   [email protected]
Date:     2009-10-07 06:28:43 -0700 (Wed, 07 Oct 2009)
Log Message:
NumericStepper needs a textFieldClass style.
QE notes:
Doc notes:
Bugs:
Reviewer: Gordon
Tests run: checkintests
Is noteworthy for integration: no
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/MXFTEText.css

[svn:fx-trunk] 10889: Add FTETextTests which check that a Label and NumericStepper configured to use FTEText have a textField and textInput , respectively, of type UIFTETextField and MXFTETextInput.

Revision: 10889
Author:   [email protected]
Date:     2009-10-06 09:29:53 -0700 (Tue, 06 Oct 2009)
Log Message:
Add FTETextTests which check that a Label and NumericStepper configured to use FTEText have a textField and textInput, respectively, of type UIFTETextField and MXFTETextInput. The components are configured via style properties rather than by theme which would require another version/compile of the BasicTests.swf.
QE notes:
Doc notes:
Bugs:
Reviewer: Alex
Tests run: basictests
Is noteworthy for integration: no
Modified Paths:
    flex/sdk/trunk/frameworks/tests/basicTests/BasicTests-config.xml
    flex/sdk/trunk/frameworks/tests/basicTests/BasicTests.mxml
Added Paths:
    flex/sdk/trunk/frameworks/tests/basicTests/halo/scripts/FTETextTestScript.mxml
    flex/sdk/trunk/frameworks/tests/basicTests/halo/views/FTETextTests.mxml

I'm also having this problem. I'm using Flash Builder 4.6, AIR 3.4 and I've made a DLL (e.g. ExtensionDll.dll) which needs to call functions in another DLL (e.g. DllUsedByExtensionDll.dll) . I've made sure my ANE is working with the ExtensionDll.dll already, so there are no issues with my actionscript code or my ANE packaging or my DLL compilation. However, once I start calling functions from the other DLL, it starts throwing me Error #3500. Even if I call this function (e.g. abc()) in ExtensionDll.dll, but I never actually use the function from actionscript, and I call another function (e.g. def()) from actionscript, the Error #3500 still appears, so it does not seem to depened on the whether the code is used or not.
It's similar to this problem.
http://stackoverflow.com/questions/9823504/how-to-use-external-dll-in-air-native-extension
Does anyone have a solution or at least a way to debug this?

Index with "or" clause (BUG still exists?)

The change log for 2.3.10 mentions "Fixed a bug that caused incorrect query plans to be generated for predicates that used the "or" operator in conjunction with indexes [#15328]."
But looks like the Bug still exists.
I am listing the steps to-repro. Let me know if i have missed something (or if the bug needs to be fixed)
DATA
dbxml> openContainer test.dbxml
dbxml> getDocuments
2 documents found
dbxml> print
<node><value>a</value></node>
<node><value>b</value></node>
INDEX (just one string equality index on node "value")
dbxml> listIndexes
Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
Index: node-element-equality-string for node {}:value
2 indexes found.
QUERY
setVerbose 2 2
preload test.dbxml
query 'let $temp := fn:compare("test", "test") = 0
let $results := for $i in collection("test.dbxml")
where ($temp or $i/node[value = ("a")])
return $i
return <out>{$temp}{$results}</out>'
When $temp is true i expected the result set to contain both the records, but that was not the case with the index. It works well when there is no index!
Result WITH INDEX
dbxml> print
<out>true<node><value>a</value></node></out>
Result WITHOUT INDEX
dbxml> print
<out>true<node><value>a</value></node><node><value>b</value></node></out>

Hi Vijay,
This is a completely different bug, relating to predicate expressions that do not examine nodes. Please try the following patch, to see if it fixes this bug for you:
--- dbxml-2.3.10-original/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-04-18 10:05:24.000000000 +0100
+++ dbxml-2.3.10/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-08-08 11:32:10.000000000 +0100
@@ -1566,11 +1572,12 @@
     else if(name == Or::name) {
          UnionQP *unionOp = new (&memMgr_) UnionQP(&memMgr_);
+          result.operation = unionOp;
          for(VectorOfASTNodes::iterator i = args.begin(); i != args.end(); ++i) {
               PathResult ret = generate(*i, ids);
               unionOp->addArg(ret.operation);
+               if(ret.operation == 0) result.operation = 0;
-          result.operation = unionOp;
     // These operators use the presence of the node arguments, not their valueJohn

Bug report follow-up

is there a way to follow-up on a bug report that i submitted? i have the bug number, but would like to see if the report was understood, filled out properly and determine the status of the bug report.
thanks,
doug

They comment on bugs if actions were taken. Otherwise - don't expect any feedback.

Solaris8 and 9 (possibly 7) /dev/poll driver bug report.

Hello,
I'd like to report a bug in the solaris 8 and 9 /dev/poll driver (poll(7d)).
As i do not have a support account with sun or anything like that, there
seems to be no other way to do that here (which is of course a very sad
thing).
Bug details:
The /dev/poll device provides an ioctl-request (DP_ISPOLLED) for checking
if a particular filedescriptor is currently in the set of monitored
filedescriptors for that particular /dev/poll fd set (open /dev/poll fd).
A quote from the documentation of the poll(7d) manual page taken from
Solaris9:
"DP_ISPOLLED ioctl allows you to query if a file descriptor is already in
the monitored set represented by fd. The fd field of the pollfd structure
indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1
if the file descriptor is in the set. The events field contains the
currently polled events. The revents field contains 0. The ioctl returns 0
if the file descriptor is not in the set. The pollfd structure pointed by
pfd is not modified. The ioctl returns a -1 if the call fails."
It says that when you query for an filedescriptor which is currently being
monitored in the set, that it would return 1, and change the events field of
the pollfd structure to the events it's currently monitoring that fd for.
The revents field would be set to zero.
However the only thing which actually happens here, is that FD_ISPOLLED
returns 1 when the fd is in the set and 0 if not. When the fd is in the
set, when FD_ISPOLLED returns 1, the events field remains unmodified, but
the revents field gets changed.
A small sample code to illustrate:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/devpoll.h>
main() {
struct pollfd a;
int dp_fd = open("/dev/poll", O_WRONLY);
a.fd = 0; /* stdin */
a.events = POLLIN; /* we monitor for readability, POLLIN=1 */
a.revents = 0;
write(dp_fd, &a, sizeof(a));
a.fd = 0;
a.events = 34; /* filled in with bogus number to show malfunctioning */
a.revents = 0;
printf("DP_ISPOLLED returns: %d\n", ioctl(dp_fd, DP_ISPOLLED, &a));
printf("a.fd=%d, a.events=%hd, a.revents=%hd\n", a.fd, a.events,
a.revents);
According to the documentation of /dev/poll and namely DP_ISPOLLED this
program is supposed to print the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=1, a.revents=0
However it prints the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=34, a.revents=1
You can take any number instead of '34' and it will simply remain untouched
after the DP_ISPOLLED ioctl-request.
I hope it's clear now that the solaris8 and solaris9 (and probably solaris7
with /dev/poll patch too) DP_ISPOLLED implementation is broken.
This bug is also easily illustrated by looking at the solaris8 kernel sourcecode:
<snippet osnet_volume/usr/src/uts/common/io/devpoll.c:dpioctl()>
case DP_ISPOLLED:
pollfd_t pollfd;
polldat_t *pdp;
if (pollfd.fd < 0) {
mutex_exit(&pcp->pc_lock);
break;
pdp = pcache_lookup_fd(pcp, pollfd.fd);
if ((pdp != NULL) && (pdp->pd_fd == pollfd.fd) &&
(pdp->pd_fp != NULL)) {
pollfd.revents = pdp->pd_events;
if (copyout(&pollfd, (caddr_t)arg,
sizeof(pollfd_t))) {
mutex_exit(&pcp->pc_lock);
DP_REFRELE(dpep);
return (set_errno(EFAULT));
*rvalp = 1;
</snippet>
its' clearly visible that the code writes the current monitored events to
the revents field:
'pollfd.revents = pdp->pd_events;'
and that it doesnt set revents to zero.
It's funny to see that this has been like this since Solaris8 (possibly 7). That means nobody ever used DP_ISPOLLED that way or people were simply to lazy to file a bug report.
Another funny thing related to this. is that Hewlett-Packard did seem to know about this. Since HP-UX11i version 1.6 they also support /dev/poll. From their manual page i ll quote some sentences from their WARNING session:
"The ioctl(DP_ISPOLLED) system call also returns its result in the revents member of the pollfd structure, in order to be compatible with the implementation of the /dev/poll driver by some other vendors."
Hopefully this will get fixed.
I also like to reexpress my very negative feelings towards the fact that you're not able to file bug reports when you do not have a support contract. Ridiculous.
Thanks,
bighawk

Have I mentioned how much i love my playbook now Great job on os 2.0

[bdb bug]repeatly open and close db may cause memory leak

my test code is very simple :
char *filename = "xxx.db";
char *dbname = "xxx";
for( ; ;)
DB *dbp;
DB_TXN *txnp;
db_create(&dbp,dbenvp, 0);
dbenvp->txn_begin(dbenvp, NULL, &txnp, 0);
ret = dbp->open(dbp, txnp, filename, dbname, DB_BTREE, DB_CREATE, 0);
if(ret != 0)
printf("failed to open db:%s\n",db_strerror(ret));
return 0;
txnp->commit(txnp, 0);
dbp->close(dbp, DB_NOSYNC);
I try to run my test program for a long time opening and closing db repeatly, then use the PS command and find the RSS is increasing slowly:
ps -va
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1986 pts/0 S 0:00 466 588 4999 980 0.3 -bash
2615 pts/0 R 0:01 588 2 5141 2500 0.9 ./test
after a few minutes：
ps -va
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1986 pts/0 S 0:00 473 588 4999 976 0.3 -bash
2615 pts/0 R 30:02 689 2 156561 117892 46.2 ./test
I had read bdb's source code before, so i tried to debug it for about a week and found something like a bug:
If open a db with both filename and dbname, bdb will open a db handle for master db and a db handle for subdb,
both of the two handle will get an fileid by a internal api called __dbreg_get_id, however, just the subdb's id will be
return to bdb's log region by calling __dbreg_pop_id. It leads to a id leak if I tried to open and close the db
repeatly, as a result， __dbreg_add_dbentry will call realloc repeatly to enlarge the dbentry area, this seens to be
the reason for RSS increasing.
Is it not a BUG?
sorry for my pool english :)
Edited by: user9222236 on 2010-2-25 下午10:38

I have tested my program using Oracle Berkeley DB release 4.8.26 and 4.7.25 in redhat 9.0 (Kernel 2.4.20-8smp on an i686) and AIX Version 5.
The problem is easy to be reproduced by calling the open method of db handle with both filename and dbname being specified and calling the close method.
My program is very simple:
#include <stdlib.h>
#include <stdio.h>
#include <sys/time.h>
#include "db.h"
int main(int argc, char * argv[])
int ret, count;
DB_ENV *dbenvp;
char * filename = "test.dbf";
char * dbname = "test";
db_env_create(&dbenvp, 0);
dbenvp->open(dbenvp, "/home/bdb/code/test/env",DB_CREATE|DB_INIT_LOCK|DB_INIT_LOG|DB_INIT_TXN|DB_INIT_MPOOL, 0);
for(count = 0 ; count < 10000000 ; count++)
DB *dbp;
DB_TXN *txnp;
db_create(&dbp,dbenvp, 0);
dbenvp->txn_begin(dbenvp, NULL, &txnp, 0);
ret = dbp->open(dbp, txnp, filename, dbname, DB_BTREE, DB_CREATE, 0);
if(ret != 0)
printf("failed to open db:%s\n",db_strerror(ret));
return 0;
txnp->commit(txnp, 0);
dbp->close(dbp, DB_NOSYNC);
dbenvp->close(dbenvp, 0);
return 0;
DB_CONFIG is like below:
set_cachesize 0 20000 0
set_flags db_auto_commit
set_flags db_txn_nosync
set_flags db_log_inmemory
set_lk_detect db_lock_minlocks
Edited by: user9222236 on 2010-2-28 下午5:42
Edited by: user9222236 on 2010-2-28 下午5:45

Multiple return values (Bug-ID 4222792)

I had exactly the same request for the same 3 reasons: strong type safety and code correctness verification at compile-time, code readability and ease of mantenance, performance.
Here is what Sun replied to me:
Autoboxing and varargs are provided as part of
JSRs 14 and 201
http://jcp.org/en/jsr/detail?id=14
http://jcp.org/en/jsr/detail?id=201
See also:
http://forum.java.sun.com/forum.jsp?forum=316
http://developer.java.sun.com/developer/earlyAccess/adding_generics/index.html
Multiple return values is covered by Bug-ID 4222792
Typically this is done by returning an array.
http://developer.java.sun.com/developer/bugParade/bugs/4222792.html
That's exactly the problem: we dynamically create instances of array objects that would better fit well within the operand stack without stressing the garbage collector with temporary Array object instances (and with their backing store: 2 separate allocations that need to be recycled when it is clearly a pollution that the operand stack would clean up more efficiently)
If you would like to engage in a discussion with the Java Language developers, the Generics forum would be a better place:
http://forum.java.sun.com/forum.jsp?forum=316
I know that (my report was already refering to the JSR for language extension) Generics is not what I was refering to (even if a generic could handle multiple return values, it would still be an allocated Object
instance to pack them, i.e. just less convenient than using a static class for type safety.
The most common case of multiple return values involve values that have known static datatypes and that should be checked with strong typesafety.
The simple case that involves returning two ints then will require at least two object instances and will not solve the garbage collection overhead.
Using a array of variable objects is exactly similar, except that it requires two instances for the components and one instance for the generic array container. Using extra method parameters with Integer, Byte, ... boxing objects is more efficient, but for now the only practical solution (which causes the least pollution in the VM allocator and garbage collector) is to use a custom class to store the return values in a single instance.
This is not natural, and needlessly complexifies many interfaces.
So to avoid this pollution, some solutions are used such as packing two ints into a long and returning a long, depacking the long after return (not quite clean but still much faster at run-time for methods that need to be used with high frequencies within the application. In some case, the only way to cut down the overhead is to inline methods within the caller code, and this does not help code maintenance by splitting the implementation into small methods (something that C++ can do very easily, both because it supports native types parameters by reference, and because it also supports inline methods).
Finally, suppose we don't want to use tricky code, difficult to maintain, then we'll have to use boxing Object types to allow passing arguments by reference. Shamely boxed native types cannot be allocated on the operand stack as local variables, so we need to instanciate these local variables before call, and we loose the capacity to track the cases where these local variables are not really initialized by an effective call to the method that will assign them. This does not help debugging, and is against the concept of a strongly typed language like Java should be:
Java makes lots of efforts to track uninitialized variables, but has no way to determine if an already instanciated Object instance refered in a local variable has effectively received an effective assignment because only the instanciation is kept. A typical code will then need to be written like this:
Integer a = null;
Integer b = null;
if (some condition) {
//call.method(a, b, 0, 1, "dummy input arg");
// the method is supposed to have assigned a value to a and b,
// but can't if a and b have not been instanciated, so we perform:
call.method(a = new Integer(), b = new Integer(), 0, 1, "dummy input
arg");
// we must suppose that the method has modified (not initialized!)
the value
// of a and b instances.
now.use(a.value(), b.value())
// are we sure here that a and b have received a value????
// the code may be detected at run-time (a null exception)
// or completely undetected (the method() above was called but it
// forgot to assign a value to its referenced objects a and b, in which
// case we are calling in fact: now.use(0, 0); with the default values
// or a and b, assigned when they were instanciated)
Very tricky... Hard to debug. It would be much simpler if we just used:
int a;
int b;
if (some condition) {
(a, b) = call.method(0, 1, "dummy input arg");
now.use(a, b);
The compiler would immediately detect the case where a and b are in fact not always initialized (possible use bere initialization), and the first invoked call.method() would not have to check if its arguments are not null, it would not compile if it forgets to return two values in some code path...
There's no need to provide extra boxing objects in the source as well as at run-time, and there's no stress added to the VM allocator or garbage collector simply because return values are only allocated on the perand stack by the caller, directly instanciated within the callee which MUST (checked at compile-time) create such instances by using the return statement to instanciate them, and the caller now just needs to use directly the variables which were referenced before call (here a and b). Clean and mean. And it allows strong typechecking as well (so this is a real help for programmers.
Note that the signature of the method() above is:
class call {
(int, int) method(int, int, String) { ... }
id est:
class "call", member name "method", member type "(IILjava.lang.string;)II"
This last signature means that the method can only be called by returning the value into a pair of variables of type int, or using the return value as a pair of actual arguments for another method call such as:
call.method(call.method("dummy input arg"), "other dummy input arg")
This is strongly typed and convenient to write and debug and very efficient at run-time...

Can anyone give me some real-world examples where
multiple return values aren't better captured in a
class that logically groups those values? I can of
course give hundreds of examples for why it's better
to capture method arguments as multiple values instead
of as one "logical object", but whenever I've hankered
for multiple return values, I end up rethinking my
strategy and rewriting my code to be better Object
Oriented.I'd personally say you're usually right. There's almost always a O-O way of avoiding the situation.
Sometimes though, you really do just want to return "two ints" from a function. There's no logical object you can think of to put them in. So you end up polluting the namespace:
public class MyUsefulClass {
public TwoInts calculateSomething(int a, int b, int c) {
public static class TwoInts {
    //now, do I use two public int fields here, making it
    //in essence a struct?
   //or do I make my two ints private & final, which
   //requires a constructor & two getters?
//and while I'm at it, is it worth implementing
//equals(), how about hashCode()? clone()?
//readResolve() ?
}The answer to most of the questions for something as simple as "TwoInts" is usually "no: its not worth implementing those methods", but I still have to think about them.
More to the point, the TwoInts class looks so ugly polluting the top level namespace like that, MyUsefulClass.TwoInts is public, that I don't think I've ever actually created that class. I always find some way to avoid it, even if the workaround is just as ugly.
For myself, I'd like to see some simple pass-by-value "Tuple" type. My fear is it'd be abused as a way for lazy programmers to avoid creating objects when they should have a logical type for readability & maintainability.
Anyone who has maintained code where someone has passed in all their arguments as (mutable!) Maps, Collections and/or Arrays and "returned" values by mutating those structures knows what a nightmare it can be. Which I suppose is an argument that cuts both ways: on the one hand you can say: "why add Tuples which would be another easy thing to abuse", on the other: "why not add Tuples, given Arrays and the Collections framework already allow bad programmers to produce unmainable mush. One more feature isn't going to make a difference either way".
Ho hum.

MM NumericStepper Bug

Similar Messages

Maybe you are looking for