Stephan van Hulst

Can you guarantee that nothing, not even another application, will ever write to the database? If so, you don't need transactions. But if there's even the slightest chance that something or somebody will write to the database while your application is running, you need transactions when you read something.

Because the formal type of the variable that holds a reference to your object is SimpleAnimal, and the SimpleAnimal interface doesn't expose that method.

Imperative languages are not like math. Imperative languages perform statements one statement at a time.

You're calculating cm before you've asked the user to input ft and in. That means that the result is undefined.

So why don't you use different languages instead?

I think you're forgetting that a large part of a project is not the product, but the project management. You need to keep track of issues, need commitment from participants, a repository for the code, and users that are late to the discussion will find it hard to track the discussion about the changes to the code in relation to the existing code base, without accessing the project history or pull requests off-site. Simply put, I think a forum is just not that good of a medium.

It's probably easier for people who want to learn this way to actually start working on open source projects, and have their code commented on there.

Immutability is a good quality in itself, which doesn't depend on whether an object can be pooled. On the other hand, you can pool objects that are mutable. An example is a thread pool or a connection pool.

So neither is a reason for the other. Having said that, I don't think they would have made a string pool if String was mutable, but having mutable strings would have been complete madness.

Peter Baumarchais wrote:However the changes that I am suggesting are not ultimately as complicated as all the other changes that they have been prepared to make.
...
A quality maths system, with operators, with the option to disable floating point overflow and underflow (for code thats already compiled) is not a particularly greater problem than any of these changes, and is even smaller a change.

First of all, I think you underestimate the complexity of some of your requests in comparison to the features you've mentioned. For instance, writing the enhanced for loop is pretty straightforward, because you only have to tweak the grammar of the language a little bit, and then lift the syntax to regular calls to Iterator. Overflow checking for types that follow an IEEE standard? Heh.

Secondly, many features you've mentioned were already part of the language from the start. It's much easier to implement a feature using a clean slate than when you have to tack it on an existing language, if there's no straightforward way to lift the syntax. While operator overloading for BigDecimal may be lifted to calls to add() etc., the overflow checking for floating point values is new.

Finally, the ease of implementing a feature is not the only factor in deciding whether it will be implemented. The actual formula is more like (chance of implementation) = (community demand) / (difficulty of implementation). There was a MUCH greater demand for the advanced for loop, and yes, even the var keyword.

In short, you will probably have to wait for a long time because you're in the minority that really wants this change, especially so if you can't produce scenarios where you absolutely need this behavior.

Since it's an equation, F is a parameter as well, because I can rewrite it to m = F/a.

No, the symbol commonly used for the physical quantity of energy is E.

Wrong. As Bear has said, GenericServlet handles NO protocol.

You asked the exact same question here: https://coderanch.com/t/695520/frameworks/Model-parameter-Controller-method#3265392

Was the answer not satisfactory?

Peter Baumarchais wrote:I would have thought that arithmetic and functions mathematics were so grass roots that the should have arbitrary support, anyway.

It isn't trivial. Because Java doesn't have operator overloading (which is not as widespread as you seem to think it is), defining these operators for the BigDecimal class is a change to the Java language itself, and all compilers need to be changed as well. The only reference type for which an operator was overloaded (and only ONE operator) was the String class. Arguably, even that was a mistake because string concatenation in loops is expensive compared to using StringBuilder, and outside of loops string interpolation would have been a more elegant solution.

Besides which, their own documentary does use the term arbitrary precision, at any rate. Hence, along with grass roots concerns, the interest in it.

For all intents and purposes. Arbitrary here is meant to be taken that the user can decide on the precision, rather than that the precision is fixed to 32 or 64 bits. The double values 1.0 and 1.0000 have the same precision: 64 bits. The BigDecimal values "1.0" and "1.0000" have a precision of 2 and 5 respectively.

What seems arbitrary (hehehe) to me is that you balk about the limit imposed by a 32 bit scale, but that it's fine if memory runs out. Note that its precision IS limited to the maximum amount of memory available as long as the scale fits inside 32 bits.

Welcome back!

It's important to distinguish between so called "heavyweight" and "lightweight" components. The heavyweight components are implemented through native calls to the windowing system. This is probably done in C or C++ code that is custom to each OS.

Most AWT components are heavyweight, and in Swing, so are the top level containers (JFrame, JWindow, JDialog and JApplet).

Lightweight components are written in Java. They are all the classes that inherit from JComponent. They function by painting themselves on a portion of the top level container using a Graphics object that they receive from the container they're inside of. They receive events to react to by registering listeners with the container they're inside of.

You can actually get a really good feel for lightweight components if you write your own JComponent subclass. If you have never done so, you may start by extending JPanel and overriding the paintComponent() method. Otherwise, it's an interesting challenge to write a completely new JComponent, that also uses the current LookAndFeel when it displays itself.

Finally, for more information refer to the JRootPane class documentation.

Why don't you write a JSR and see what the community does with your demands?