Search Results

Search found 80 results on 4 pages for 'bigdecimal'.

Page 1/4 | 1 2 3 4  | Next Page >

  • Ruby BigDecimal Round: Is this an error?

    - by peterdp
    While writing a test with a value that gets represented as a BigDecimal, I ran into something weird and decided to dig into it. In brief, '0.00009' when rounded to two decimal places is returned as 0.01 instead of 0.00. Really. Here's my script/console capture: >> bp = BigDecimal('0.09') => #<BigDecimal:210fe08,'0.9E-1',4(8)> >> bp.round(2,BigDecimal::ROUND_HALF_DOWN).to_f => 0.09 >> bp = BigDecimal('0.009') => #<BigDecimal:210bcf4,'0.9E-2',4(8)> >> bp.round(2,BigDecimal::ROUND_HALF_DOWN).to_f => 0.01 >> bp = BigDecimal('0.0009') => #<BigDecimal:2107a8c,'0.9E-3',4(12)> >> bp.round(2,BigDecimal::ROUND_HALF_DOWN).to_f => 0.0 >> bp = BigDecimal('0.00009') => #<BigDecimal:2103428,'0.9E-4',4(12)> >> bp.round(2,BigDecimal::ROUND_HALF_DOWN).to_f => 0.01 >> bp = BigDecimal('0.000009') => #<BigDecimal:20ff0f8,'0.9E-5',4(12)> >> bp.round(2,BigDecimal::ROUND_HALF_DOWN).to_f => 0.0 Oh, and I get the same results if I use the default mode, like so: >> bd = BigDecimal('0.00009') => #<BigDecimal:2152ed8,'0.9E-4',4(12)> >> bd.round(2).to_f => 0.01 Here are my versions: ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.2.2] Rails 2.3.4 Has anyone seen anything like this?

    Read the article

  • Avoid the problem with BigDecimal when migrating to Java 1.4 to Java 1.5+

    - by romaintaz
    Hello, I've recently migrated a Java 1.4 application to a Java 6 environment. Unfortunately, I encountered a problem with the BigDecimal storage in a Oracle database. To summarize, when I try to store a "7.65E+7" BigDecimal value (76,500,000.00) in the database, Oracle stores in reality the value of 7,650,000.00. This defect is due to the rewritting of the BigDecimal class in Java 1.5 (see here). In my code, the BigDecimal was created from a double using this kind of code: BigDecimal myBD = new BigDecimal("" + someDoubleValue); someObject.setAmount(myBD); // Now let Hibernate persists my object in DB... In more than 99% of the cases, everything works fine. Except that in really few case, the bug mentioned above occurs. And that's quite annoying. If I change the previous code to avoid the use of the String constructor of BigDecimal, then I do not encounter the bug in my uses cases: BigDecimal myBD = new BigDecimal(someDoubleValue); someObject.setAmount(myBD); // Now let Hibernate persists my object in DB... However, how can I be sure that this solution is the correct way to handle the use of BigDecimal? So my question is to know how I have to manage my BigDecimal values to avoid this issue: Do not use the new BigDecimal(String) constructor and use directly the new BigDecimal(double)? Force Oracle to use toPlainString() instead of toString() method when dealing with BigDecimal (and in this case how to do that)? Any other solution? Environment information: Java 1.6.0_14 Hibernate 2.1.8 (yes, it is a quite old version) Oracle JDBC 9.0.2.0 and also tested with 10.2.0.3.0 Oracle database 10.2.0.3.0

    Read the article

  • BigDecimal, division & MathContext - very strange behaviour

    - by blackliteon
    CentOs 5.4, OpenJDK Runtime Environment (build 1.6.0-b09) MathContext context = new MathContext(2, RoundingMode.FLOOR); BigDecimal total = new BigDecimal("200.0", context); BigDecimal goodPrice = total.divide(BigDecimal.valueOf(3), 2, RoundingMode.FLOOR); System.out.println("divided price=" + goodPrice.toPlainString()); // prints 66.66 BigDecimal goodPrice2 = total.divide(BigDecimal.valueOf(3), new MathContext(2, RoundingMode.FLOOR)); System.out.println("divided price2=" + goodPrice2.toPlainString()); // prints 66 BUG ?

    Read the article

  • java.bigDecimal divide in ruby environment

    - by Eyal
    I right script in Ruby that include java classes require 'java' include_class 'java.math.BigDecimal' include_class 'java.math.RoundingMode' during the script I need to divide 2 java.bigDecimal one = BigDecimal.new("1") number1 = BigDecimal.new("3") number1 = one.divide(number1,RoundingMode.new(HALF_EVEN)) since I don't have intellisense in this IDE I'm not sure the syntax is right and the runtime error is: uninitialized constant::HALF_EVEN do I combine java object in the ruby scrpit in the right way? how should I divide two java.bigDecimal object in ruby env?

    Read the article

  • ArithmeticException thrown during BigDecimal.divide

    - by polygenelubricants
    I thought java.math.BigDecimal is supposed to be The Answer™ to the need of performing infinite precision arithmetic with decimal numbers. Consider the following snippet: import java.math.BigDecimal; //... final BigDecimal one = BigDecimal.ONE; final BigDecimal three = BigDecimal.valueOf(3); final BigDecimal third = one.divide(three); assert third.multiply(three).equals(one); // this should pass, right? I expect the assert to pass, but in fact the execution doesn't even get there: one.divide(three) causes ArithmeticException to be thrown! Exception in thread "main" java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result. at java.math.BigDecimal.divide It turns out that this behavior is explicitly documented in the API: In the case of divide, the exact quotient could have an infinitely long decimal expansion; for example, 1 divided by 3. If the quotient has a non-terminating decimal expansion and the operation is specified to return an exact result, an ArithmeticException is thrown. Otherwise, the exact result of the division is returned, as done for other operations. Browsing around the API further, one finds that in fact there are various overloads of divide that performs inexact division, i.e.: final BigDecimal third = one.divide(three, 33, RoundingMode.DOWN); System.out.println(three.multiply(third)); // prints "0.999999999999999999999999999999999" Of course, the obvious question now is "What's the point???". I thought BigDecimal is the solution when we need exact arithmetic, e.g. for financial calculations. If we can't even divide exactly, then how useful can this be? Does it actually serve a general purpose, or is it only useful in a very niche application where you fortunately just don't need to divide at all? If this is not the right answer, what CAN we use for exact division in financial calculation? (I mean, I don't have a finance major, but they still use division, right???).

    Read the article

  • java - BigDecimal

    - by Mk12
    I was trying to make my own class for currencies using longs, but Apparently I should use BigDecimal (and then whenever I print it just add the $ sign before it). Could someone please get me started? What would be the best way to use BigDecimals for Dollar currencies, like making it at least but no more than 2 decimal places for the cents, etc. The api for BigDecimal is huge, and I don't know which methods to use. Also, BigDecimal has better precision, but isn't that all lost if it passes through a double? if I do new BigDecimal(24.99), how will it be different than using a double? Or should I use the constructor that uses a String instead? EDIT: I decided to use BigDecimals, and then use: private static final java.text.NumberFormat moneyt = java.text.NumberFormat.getCurrencyInstance(); { money.setRoundingMode(RoundingMode.HALF_EVEN); } and then whenever I display the BigDecimals, to use money.format(theBigDecimal). Is this alright? Should I have the BigDecimal rounding it too? Because then it doesn't get rounded before it does another operation.. if so, could you show me how? And how should I create the BigDecimals? new BigDecimal("24.99") ? Well, after many comments to Vineet Reynolds (thanks for keeping coming back and answering), this is what I have decided. I use BigDecimals and a NumberFormat. Here is where I create the NumberFormat instance. private static final NumberFormat money; static { money = NumberFormat.getCurrencyInstance(Locale.CANADA); money.setRoundingMode(RoundingMode.HALF_EVEN); } Here is my BigDecimal: private final BigDecimal price; Whenever I want to display the price, or another BigDecimal that I got through calculations of price, I use: money.format(price) to get the String. Whenever I want to store the price, or a calculation from price, in a database or in a field or anywhere, I use (for a field): myCalculatedResult = price.add(new BigDecimal("34.58")).setScale(2, RoundingMode.HALF_EVEN); .. but I'm thinking now maybe I should not have the NumberFormat round, but when I want to display do this: System.out.print(money.format(price.setScale(2, RoundingMode.HALF_EVEN); That way to ensure the model and things displayed in the view are the same. I don't do: price = price.setScale(2, RoundingMode.HALF_EVEN); Because then it would always round to 2 decimal places and wouldn't be as precise in calculations. So its all solved now, I guess. But is there any shortcut to typing calculatedResult.setScale(2, RoundingMode.HALF_EVEN) all the time? All I can think of is static importing HALF_EVEN... EDIT: I've changed my mind a bit, I think if I store a value, I won't round it unless I have no more operations to do with it, e.g. if it was the final total that will be charged to someone. I will only round things at the end, or whenever necessary, and I will still use NumberFormat for the currency formatting, but since I always want rounding for display, I made a static method for display: public static String moneyFormat(BigDecimal price) { return money.format(price.setScale(2, RoundingMode.HALF_EVEN)); } So values stored in variables won't be rounded, and I'll use that method to display prices.

    Read the article

  • Does Scala's BigDecimal violate the equals/hashCode contract?

    - by oxbow_lakes
    As the Ordered trait demands, the equals method on Scala's BigDecimal class is consistent with the ordering. However, the hashcode is simply taken from the wrapped java.math.BigDecimal and is therefore inconsistent with equals. object DecTest { def main(args: Array[String]) { val d1 = BigDecimal("2") val d2 = BigDecimal("2.00") println(d1 == d2) //prints true println(d1.hashCode == d2.hashCode) //prints false } } I can't find any reference to this being a known issue. Am I missing something?

    Read the article

  • Why is there an implicit conversion from Float/Double to BigDecimal, but not from String?

    - by soc
    Although the situation of conversion from Doubles to BigDecimals has improved a bit compared to Java scala> new java.math.BigDecimal(0.2) res0: java.math.BigDecimal = 0.20000000000000001110223024625156... scala> BigDecimal(0.2) res1: scala.math.BigDecimal = 0.2 and things like val numbers: List[BigDecimal] = List(1.2, 3.2, 0.7, 0.8, 1.1) work really well, wouldn't it be reasonable to have an implicit conversion like implicit def String2BigDecimal(s: String) = BigDecimal(s) available by default which can convert Strings to BigDecimals like this? val numbers: List[BigDecimal] = List("1.2", "3.2", "0.7", "0.8", "1.1") Or am I missing something and Scala resolved all "problems" of Java with using the BigDecimal constructor with a floating point value instead of a String, and BigDecimal(String) is basically not needed anymore in Scala?

    Read the article

  • BigDecimal to_s does not match to_f

    - by Chris Bisignani
    Is the BigDecimal class broken? It seems like the following should never, ever occur: Note that a.to_f != a.to_s.to_f a.class = BigDecimal a.to_f = 18658.1072928 a.to_s = "10865.81072928" b.class = BigDecimal b.to_f = 10000.0 b.to_s = "10000.0" (a - b).to_f = 865.81072928 a.to_f - b.to_f = 8658.1072928 Any ideas as to what might be going wrong?

    Read the article

  • BigDecimal serialization in GWT

    - by Domchi
    What is your preferred approach to serializing BigDecimal in GWT? Are there any clever workarounds, or do you simply use Double or String? Of all of the GWT pains this is so far the biggest; I'd hate to create two models, one for server and one for GWT, and transform data from one to the other. On the other hand, while I don't care much about using String instead of, say, javax.xml.datatype.Duration, I have to use BigDecimal on the server because of the calculations, which means either two models and conversion, or tons of tiny conversions to BigDecimal for every calculation.

    Read the article

  • Check if BigDecimal is integer value

    - by Adamski
    Can anyone recommend an efficient way of determining whether a BigDecimal is an integer value in the mathematical sense? At present I have the following code: private boolean isIntegerValue(BigDecimal bd) { boolean ret; try { bd.toBigIntegerExact(); ret = true; } catch (ArithmeticException ex) { ret = false; } return ret; } ... but would like to avoid the object creation overhead if necessary. Previously I was using bd.longValueExact() which would avoid creating an object if the BigDecimal was using its compact representation internally, but obviously would fail if the value was too big to fit into a long. Any help appreciated.

    Read the article

  • Ruby BigDecimal sanity check (floating point newb)

    - by Andy
    Hello, Hoping to get some feedback from someone more experienced here. I haven't dealt with the dreaded floating-point calculation before... Is my understanding correct that with Ruby BigDecimal types (even with varying precision and scale lengths) should calculate accurately or should I anticipate floating point shenanigans? All my values within a Rails application are BigDecimal type and I'm seeing some errors (they do have different decimal lengths), hoping it's just my methods and not my object types... Thanks!

    Read the article

  • JAXB, BigDecimal or double?

    - by Alex
    I working on different web-services, and I always use WSDL First. JAXB generates for a Type like: <xsd:simpleType name="CurrencyFormatTyp"> <xsd:restriction base="xsd:decimal"> <xsd:totalDigits value="13"/> <xsd:fractionDigits value="2"/> <xsd:minInclusive value="0.01"/> </xsd:restriction> </xsd:simpleType> a Java binding type BigDecimal (as it's mentioned in JAXB specification). When I then do some simple arithmetic operation with values of the type double (which are stored in a database and mapped via hibernate to the type double) I run into trouble. <ns5:charge>0.200000000000000011102230246251565404236316680908203125</ns5:charge> <ns5:addcharge>0.0360000000000000042188474935755948536098003387451171875</ns5:addcharge> <ns5:tax>0.047199999999999998900879205621095024980604648590087890625</ns5:tax> <ns5:totalextax>0.2360000000000000153210777398271602578461170196533203125</ns5:totalextax> What would be the right way? Convert all my values into double (JAXB binding from BigDecimal to double) Hibernate mapping double to Bigdecimal and do all my arithmetic operations in one object type.

    Read the article

  • BigDecimal.floatValue versus Float.valueOf

    - by Frank
    Has anybody ever come across this: System.out.println("value of: " + Float.valueOf("3.0f")); // ok, prints 3.0 System.out.println(new BigDecimal("3.0f").floatValue()); // NumberFormatException I would argue that the lack of consistency here is a bug, where BigDecimal(String) doesn't follow the same spec as Float.valueOf() (I checked the JDK doc). I'm using a library that forces me to go through BigDecimal, but it can happen that I have to send "3.0f" there. Is there a known workaround (BigDecimal is inaccessible in a library).

    Read the article

  • BigDecimal precision not persisted with javax.persistence annotations

    - by dkaczynski
    I am using the javax.persistence API and Hibernate to create annotations and persist entities and their attributes in an Oracle 11g Express database. I have the following attribute in an entity: @Column(precision = 12, scale = 9) private BigDecimal weightedScore; The goal is to persist a decimal value with a maximum of 12 digits and a maximum of 9 of those digits to the right of the decimal place. After calculating the weightedScore, the result is 0.1234, but once I commit the entity with the Oracle database, the value displays as 0.12. I can see this by either by using an EntityManager object to query the entry or by viewing it directly in the Oracle Application Express (Apex) interface in a web browser. How should I annotate my BigDecimal attribute so that the precision is persisted correctly? Note: We use an in-memory HSQL database to run our unit tests, and it does not experience the issue with the lack of precision, with or without the @Column annotation.

    Read the article

  • Groovy as a substitute for Java when using BigDecimal?

    - by geejay
    I have just completed an evaluation of Java, Groovy and Scala. The factors I considered were: readability, precision The factors I would like to know: performance, ease of integration I needed a BigDecimal level of precision. Here are my results: Java void someOp() { BigDecimal del_theta_1 = toDec(6); BigDecimal del_theta_2 = toDec(2); BigDecimal del_theta_m = toDec(0); del_theta_m = abs(del_theta_1.subtract(del_theta_2)) .divide(log(del_theta_1.divide(del_theta_2))); } Groovy void someOp() { def del_theta_1 = 6.0 def del_theta_2 = 2.0 def del_theta_m = 0.0 del_theta_m = Math.abs(del_theta_1 - del_theta_2) / Math.log(del_theta_1 / del_theta_2); } Scala def other(){ var del_theta_1 = toDec(6); var del_theta_2 = toDec(2); var del_theta_m = toDec(0); del_theta_m = ( abs(del_theta_1 - del_theta_2) / log(del_theta_1 / del_theta_2) ) } Note that in Java and Scala I used static imports. Java: Pros: it is Java Cons: no operator overloading (lots o methods), barely readable/codeable Groovy: Pros: default BigDecimal means no visible typing, least surprising BigDecimal support for all operations (division included) Cons: another language to learn Scala: Pros: has operator overloading for BigDecimal Cons: some surprising behaviour with division (fixed with Decimal128), another language to learn

    Read the article

  • Regarding BigDecimal

    - by arav
    i do the below java print command for this double variable double test=58.15; When i do a System.out.println(test); and System.out.println(new Double(test).toString()); It prints as 58.15. When i do a System.out.println(new BigDecimal(test)) I get the below value 58.14999999999999857891452847979962825775146484375 I am able to understand "test" double variable value is internally stored as 58.1499999. But when i do the below two System.out.println i am getting the output as 58.15 and not 58.1499999. System.out.println(test); System.out.println(new Double(test).toString()); It prints the output as 58.15 for the above two. Is the above System.out.println statements are doing some rounding of the value 58.1499999 and printing it as 58.15?

    Read the article

  • Scala and Java BigDecimal

    - by geejay
    I want to switch from Java to a scripting language for the Math based modules in my app. This is due to the readability, and functional limitations of mathy Java. For e.g, in Java I have this: BigDecimal x = new BigDecimal("1.1"); BigDecimal y = new BigDecimal("1.1"); BigDecimal z = x.multiply(y.exp(new BigDecimal("2")); As you can see, without BigDecimal operator overloading, simple formulas get complicated real quick. With doubles, this looks fine, but I need the precision. I was hoping in Scala I could do this: var x = 1.1; var y = 0.1; print(x + y); And by default I would get decimal-like behaviour, alas Scala doesn't use decimal calculation by default. Then I do this in Scala: var x = BigDecimal(1.1); var y = BigDecimal(0.1); println(x + y); And I still get an imprecise result. Is there something I am not doing right in Scala? Maybe I should use Groovy to maximise readability (it uses decimals by default)?

    Read the article

  • Why is BigDecimal.equals specified to compare both value and scale individually?

    - by bacar
    This is not a question about how to compare two BigDecimal objects - I know that you can use compareTo instead of equals to do that, since equals is documented as: Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method). The question is: why has the equals been specified in this seemingly counter-intuitive manner? That is, why is it important to be able to distinguish between 2.0 and 2.00? It seems likely that there must be a reason for this, since the Comparable documentation, which specifies the compareTo method, states: It is strongly recommended (though not required) that natural orderings be consistent with equals I imagine there must be a good reason for ignoring this recommendation.

    Read the article

  • How to create a simple adf dashboard application with EJB 3.0

    - by Rodrigues, Raphael
    In this month's Oracle Magazine, Frank Nimphius wrote a very good article about an Oracle ADF Faces dashboard application to support persistent user personalization. You can read this entire article clicking here. The idea in this article is to extend the dashboard application. My idea here is to create a similar dashboard application, but instead ADF BC model layer, I'm intending to use EJB3.0. There are just a one small trick here and I'll show you. I'm using the HR usual oracle schema. The steps are: 1. Create a ADF Fusion Application with EJB as a layer model 2. Generate the entities from table (I'm using Department and Employees only) 3. Create a new Session Bean. I called it: HRSessionEJB 4. Create a new method like that: public List getAllDepartmentsHavingEmployees(){ JpaEntityManager jpaEntityManager = (JpaEntityManager)em.getDelegate(); Query query = jpaEntityManager.createNamedQuery("Departments.allDepartmentsHavingEmployees"); JavaBeanResult.setQueryResultClass(query, AggregatedDepartment.class); return query.getResultList(); } 5. In the Departments entity, create a new native query annotation: @Entity @NamedQueries( { @NamedQuery(name = "Departments.findAll", query = "select o from Departments o") }) @NamedNativeQueries({ @NamedNativeQuery(name="Departments.allDepartmentsHavingEmployees", query = "select e.department_id, d.department_name , sum(e.salary), avg(e.salary) , max(e.salary), min(e.salary) from departments d , employees e where d.department_id = e.department_id group by e.department_id, d.department_name")}) public class Departments implements Serializable {...} 6. Create a new POJO called AggregatedDepartment: package oramag.sample.dashboard.model; import java.io.Serializable; import java.math.BigDecimal; public class AggregatedDepartment implements Serializable{ @SuppressWarnings("compatibility:5167698678781240729") private static final long serialVersionUID = 1L; private BigDecimal departmentId; private String departmentName; private BigDecimal sum; private BigDecimal avg; private BigDecimal max; private BigDecimal min; public AggregatedDepartment() { super(); } public AggregatedDepartment(BigDecimal departmentId, String departmentName, BigDecimal sum, BigDecimal avg, BigDecimal max, BigDecimal min) { super(); this.departmentId = departmentId; this.departmentName = departmentName; this.sum = sum; this.avg = avg; this.max = max; this.min = min; } public void setDepartmentId(BigDecimal departmentId) { this.departmentId = departmentId; } public BigDecimal getDepartmentId() { return departmentId; } public void setDepartmentName(String departmentName) { this.departmentName = departmentName; } public String getDepartmentName() { return departmentName; } public void setSum(BigDecimal sum) { this.sum = sum; } public BigDecimal getSum() { return sum; } public void setAvg(BigDecimal avg) { this.avg = avg; } public BigDecimal getAvg() { return avg; } public void setMax(BigDecimal max) { this.max = max; } public BigDecimal getMax() { return max; } public void setMin(BigDecimal min) { this.min = min; } public BigDecimal getMin() { return min; } } 7. Create the util java class called JavaBeanResult. The function of this class is to configure a native SQL query to return POJOs in a single line of code using the utility class. Credits: http://onpersistence.blogspot.com.br/2010/07/eclipselink-jpa-native-constructor.html package oramag.sample.dashboard.model.util; /******************************************************************************* * Copyright (c) 2010 Oracle. All rights reserved. * This program and the accompanying materials are made available under the * terms of the Eclipse Public License v1.0 and Eclipse Distribution License v. 1.0 * which accompanies this distribution. * The Eclipse Public License is available at http://www.eclipse.org/legal/epl-v10.html * and the Eclipse Distribution License is available at * http://www.eclipse.org/org/documents/edl-v10.php. * * @author shsmith ******************************************************************************/ import java.lang.reflect.Constructor; import java.lang.reflect.InvocationTargetException; import java.util.ArrayList; import java.util.List; import javax.persistence.Query; import org.eclipse.persistence.exceptions.ConversionException; import org.eclipse.persistence.internal.helper.ConversionManager; import org.eclipse.persistence.internal.sessions.AbstractRecord; import org.eclipse.persistence.internal.sessions.AbstractSession; import org.eclipse.persistence.jpa.JpaHelper; import org.eclipse.persistence.queries.DatabaseQuery; import org.eclipse.persistence.queries.QueryRedirector; import org.eclipse.persistence.sessions.Record; import org.eclipse.persistence.sessions.Session; /*** * This class is a simple query redirector that intercepts the result of a * native query and builds an instance of the specified JavaBean class from each * result row. The order of the selected columns musts match the JavaBean class * constructor arguments order. * * To configure a JavaBeanResult on a native SQL query use: * JavaBeanResult.setQueryResultClass(query, SomeBeanClass.class); * where query is either a JPA SQL Query or native EclipseLink DatabaseQuery. * * @author shsmith * */ public final class JavaBeanResult implements QueryRedirector { private static final long serialVersionUID = 3025874987115503731L; protected Class resultClass; public static void setQueryResultClass(Query query, Class resultClass) { JavaBeanResult javaBeanResult = new JavaBeanResult(resultClass); DatabaseQuery databaseQuery = JpaHelper.getDatabaseQuery(query); databaseQuery.setRedirector(javaBeanResult); } public static void setQueryResultClass(DatabaseQuery query, Class resultClass) { JavaBeanResult javaBeanResult = new JavaBeanResult(resultClass); query.setRedirector(javaBeanResult); } protected JavaBeanResult(Class resultClass) { this.resultClass = resultClass; } @SuppressWarnings("unchecked") public Object invokeQuery(DatabaseQuery query, Record arguments, Session session) { List results = new ArrayList(); try { Constructor[] constructors = resultClass.getDeclaredConstructors(); Constructor javaBeanClassConstructor = null; // (Constructor) resultClass.getDeclaredConstructors()[0]; Class[] constructorParameterTypes = null; // javaBeanClassConstructor.getParameterTypes(); List rows = (List) query.execute( (AbstractSession) session, (AbstractRecord) arguments); for (Object[] columns : rows) { boolean found = false; for (Constructor constructor : constructors) { javaBeanClassConstructor = constructor; constructorParameterTypes = javaBeanClassConstructor.getParameterTypes(); if (columns.length == constructorParameterTypes.length) { found = true; break; } // if (columns.length != constructorParameterTypes.length) { // throw new ColumnParameterNumberMismatchException( // resultClass); // } } if (!found) throw new ColumnParameterNumberMismatchException( resultClass); Object[] constructorArgs = new Object[constructorParameterTypes.length]; for (int j = 0; j < columns.length; j++) { Object columnValue = columns[j]; Class parameterType = constructorParameterTypes[j]; // convert the column value to the correct type--if possible constructorArgs[j] = ConversionManager.getDefaultManager() .convertObject(columnValue, parameterType); } results.add(javaBeanClassConstructor.newInstance(constructorArgs)); } } catch (ConversionException e) { throw new ColumnParameterMismatchException(e); } catch (IllegalArgumentException e) { throw new ColumnParameterMismatchException(e); } catch (InstantiationException e) { throw new ColumnParameterMismatchException(e); } catch (IllegalAccessException e) { throw new ColumnParameterMismatchException(e); } catch (InvocationTargetException e) { throw new ColumnParameterMismatchException(e); } return results; } public final class ColumnParameterMismatchException extends RuntimeException { private static final long serialVersionUID = 4752000720859502868L; public ColumnParameterMismatchException(Throwable t) { super( "Exception while processing query results-ensure column order matches constructor parameter order", t); } } public final class ColumnParameterNumberMismatchException extends RuntimeException { private static final long serialVersionUID = 1776794744797667755L; public ColumnParameterNumberMismatchException(Class clazz) { super( "Number of selected columns does not match number of constructor arguments for: " + clazz.getName()); } } } 8. Create the DataControl and a jsf or jspx page 9. Drag allDepartmentsHavingEmployees from DataControl and drop in your page 10. Choose Graph > Type: Bar (Normal) > any layout 11. In the wizard screen, Bars label, adds: sum, avg, max, min. In the X Axis label, adds: departmentName, and click in OK button 12. Run the page, the result is showed below: You can download the workspace here . It was using the latest jdeveloper version 11.1.2.2.

    Read the article

1 2 3 4  | Next Page >