|
Just curious why/how you expect two comparisons?
|
|
|
|
|
For doubles, I believe there is a positive zero and a negative zero.
|
|
|
|
|
There is only ever a single comparison made for each comparison operator, so if your code only has a single '==' operator, the JIT'd code will only generate a single IL comparison.
-0.0 does occur when a negative floating-point value is so small that is cannot be represented. That does NOT mean it's a different 0 from positive 0.0. You can see this is you try to convert an extremely small value to a string and output it. You can get -0.0.
If your code, the compiler will evaluate the comparison and optimize it out, replacing the expression with just 'true'. The resulting code, and what you see in the disassembly, will be very close to:
if (true) System.out.println("they're equal");
or, depending on code around this, maybe even:
System.out.println("they're equal");
If you want to know how numbers are represented in Java, and most other languages, read The IEEE Standard for Floating-Point Arithmetic (IEEE 754)[^]
modified 12-Jan-24 18:49pm.
|
|
|
|
|
Hi everyone! I want to integrate ChatGPT into my Spring Boot app. How can I do this?
|
|
|
|
|
Go to the ChatGPT website and ask them.
|
|
|
|
|
My first thought was "Why?". My second was yours.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: "Why?"
Probably because he doesn't understand ... anything. 
|
|
|
|
|
Steps
1. Learn Spring Boot and Java if needed.
2. Get a basic app running in Sprint Boot
3. Figure out what exactly the functionality will be with ChatGPT. There is no code involved in this. You will need to figure out what data goes into ChatGPT and what comes out.
4. Write a test app to work with 3. Use that until you figure out how to do everything for 3.
5. Write new code based on 4, and 2 which does whatever it is that you want.
|
|
|
|
|
I am using IntelliJ IDEA 2023.3.1 (Community Edition), and I'm seeing some weirdness.
I made a simple test.
public class SimpleBreakTest {
public static void main(String[] args) {
String a = null;
a.toUpperCase();
}
}
I put a breakpoint on the first line:
String a = null;
Then, I debugged the program, and it stopped at the breakpoint. Then, I pressed the "Stop" button in the debugger.
Instead of stopping execution, it looks like it continued because it printed out this message:
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.toUpperCase()" because "a" is null
at SimpleBreakTest.main(SimpleBreakTest.java:5)
Any ideas why the stop button in the debugger doesn't seem to work right?
Thanks.
|
|
|
|
|
... because a to upper without an assignment makes no sense anyway.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Well that is true specifically but in general it isn't relevant. The code is a valid statement. If it was a different method it might do something. And there is no way the debugger should be figuring that out.
|
|
|
|
|
Valid, not valid. He's created an "illogical" scenario what with null assignments, etc. Sorry, I don't blame the compiler or run time. (I frankly have no patience for this type of "nonsense"). And it's hearsay ... Did you "test" it?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
All of that is true to the extent that it isn't worth spending time on anyways (which I stated in my other post.)
Gerry Schmitz wrote: Did you "test" it?
Not relevant. If the OP can replicate it and I can't then nothing is proven. If I can replicate it then it still doesn't change the fact that it is not worth spending time on figuring it out. Not for me at least.
|
|
|
|
|
Are you certain you pressed the stop button?
|
|
|
|
|
It is of course not really worth figuring it out. And presuming you can replicate it.
But if you are just curious and have time...
Try adding a few more statements and see what happens. Statements before and/or after.
The only thing I can think of is that code optimization is in play. Generally I would not expect that but perhaps that is exactly the cause.
If it is an optimization then I would expect the following might fix it (in that Stop will work.)
String a = null;
int i = 3;
a.toUpperCase();
System.out.println("i=" + i);
|
|
|
|
|
I am using JDK 18.0.2, and the compiler optimises out those two lines, as they obviously serve no purpose. I cannot find an option to prevent the optimisation.
[edit]
I had the wrong configuration settings. Tried again and it did exactly the same. I think the debugger stops, but it runs the code to the end of the current method. More tests may help to confirm this.
[/edit]
modified 23-Dec-23 4:36am.
|
|
|
|
|
Friends, how do I use that NetBeens form called "desktop panel", like putting one form inside another. It's that form that traps the other inside it, not letting the form leave the delimited area.
I'm using Intelli
|
|
|
|
|
|
I heard that Java string characters are 16-bit. Is this true?
Does this mean that certain Unicode characters can't be represented since there are about 150,000 Unicode characters?
Thank you.
|
|
|
|
|
|
|
Being an old codger, I find Google is quite intelligent enough for me.
|
|
|
|
|
That is an incomplete question.
First for java a string contains a character set. So whatever that character set does is what java does.
From the other response the relevant part then is the following
"A String represents a string in the UTF-16 format in which supplementary characters are represented by surrogate pairs"
You would need to look up 'surrogate pairs' to understand that.
In practical business programming however that is not generally relevant. I know for example that Egyptian hieroglyphics are in the extended set. Certainly Americas, Europe, most of Asia is in the normal set. Not sure about Japanese (etc) like Kanji might or might not be. But supporting those requires other business changes also.
In practical business programming, with anything except English you still must be careful how you store (database) the text. A 'varchar' does represent a character set and you better understand the implications of that before making a decision on what to use. Just a general easy decision to make everything UTF in a database is not necessarily a good idea and there can be unexpected implications of making that decision.
|
|
|
|
|
jschell wrote: In practical business programming, with anything except English
You should not exclude English. Even if you and your company's home is in the USA, and you do all your business correspondence in English, you soon run into partners - persons or organizations - with names or addresses using characters outside 7-bit ASCII. Under some circumstances, simply replacing non-ASCII characters with whatever ASCII character you think resembles the original most closely can lead to misunderstandings and failure to find essential information in a search. Sometimes, the replacement can lead to what is in the original language a rude word, an insult etc.
UTF-8 always could handle the entire Unicode range, and for most of your text (if you don't have any business contacts with non-ASCII names or addresses, it goes for all of it), UTF-8 is just as compact as ASCII (*). If your software uses UTF-16 as an internal format, the best thing is if it can handle surrogates, but you can get a long way with handling the basic plane only. (Until you go crazy with emoticons, using all there is available - but that is not too common in business correspondence).
(*) Certainly: ASCII can be transmitted over a US style 56 kbps digital line, with 7 bits to the character. UTF-8 cannot; it requires 8 bits per byte. Even US digital lines were 8 bits per byte, 64 kbps, but for every 6 byte, the phone switch stole the LSB to use for its communication with other switches, so only 7 of the 8 bits were reliable in data transfer. I don't know whether 56 kbps lines are still used in the US of A (please enlighten me!). If they are, you can send 7-bit ASCII untransformed, but not UTF-8. Most likely, it will be transformed anyway - there is a whole crowd of different standard ways of transforming any data stream to 7-bit bytes. MIME alone provides three alternatives!
|
|
|
|
|
First be aware that I have been delivering internationalized products for decades.
trønderen wrote: you soon run into partners - persons or organizations
Then it would in fact be international.
If the intent is to only deliver in the US then no it is not a factor.
trønderen wrote: UTF-8 always could handle the entire Unicode range
So? That has nothing to do with what I said. And nothing to do with this thread.
Do you know that Java uses UTF-16 not UTF-8?
trønderen wrote: Certainly: ASCII can be transmitted over a US style 56 kbps digital line, with 7 bits to the character
Even though I have in fact delivered solutions on slower modems than that, it still has nothing to do with most business programming now.
And I use "most" exactly as defined. Not as an absolute but as a category that means, excluding explicit and documented (which is not in the OP) differences, it applies.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
