|
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.
|
|
|
|
|
jschell wrote: Then it would in fact be international.
You may notice that English is a well known and much used language in England. US trade with England is certainly international.
English is also a commonly used language in business between countries that have different national languages, but with English as a common language that they both (/all) understand.
If you really meant to say "If you are from the US and do not intend to have anything to do with anyone outside the US, or with anyone inside the US speaking other languages, being named or naming their businesses according to non-English conventions" - then abbreviating it to "English" is going much too far. The reader will think you are talking about the language, not a subset of trade with a single country.
You should be aware that there are lots of communities within the US of A where French or Spanish are commonly used languages. Their naming conventions often follows French/Spanish conventions as well.
Is there a federal law requiring all street names in the US to be written using A-Z only, with no strange accents? Does it apply e.g. within native reservations as well? Some of the native languages use completely different scripts, but when transcribed to Latin characters, you can see personal names using additional characters/accents. I do not know if that also goes for local place names within native reservations.
I have heard (no URL available) that in the old days, immigrants to the US of A carrying "strange" names that didn't fall naturally into the English language were forced to change their name. In some cases they were simply assigned a name with no relationship to their original name.
As far as I know, this is no longer the case. If you move to the US of A, you are allowed to keep your name - even if you settle in an English-speaking area. Even if your name contains characters outside of A-Z.
First be aware that I have been delivering internationalized products for decades. And then I fail to understand why you suggest to spend the effort of giving special treatment to speakers of one language within one country. Why not handle everyone, everywhere, the same way? Where is the gain of using 7-bit ASCII and nothing else to a subgroup of potential customers - especially considering that 7-bit ASCII is a true subset of UTF-8, so there is no expense in terms of space if your text is in fact limited to ASCII.
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. I allow myself to add to what you said. Just repeating your statements is meaningless.
This thread certainly has to do with which characters can be represented in various formats. Now that it is clear that the internal Java representation can not handle all Unicode characters, it is relevant to point out that UTF-8 can. I'd think that is is more relevant than to bring in, as you do, that communicating in English within a single current country can use even simpler codings.
Do you know that Java uses UTF-16 not UTF-8? That has been stated several times in this thread. If you want to be pedantic, it isn't 100% correct: Java uses a subset of UTF-16 that excludes surrogate pairs (and "variant selectors").
Some sources referenced in this discussion claim that UTF-16 at some point in time was "extended" to include surrogates. That is not true: UTF-16 was always designed to encode the entire Unicode character set (just like UTF-8). For a number of years, it seemed as if 65536 characters (the Basic Multilingual Plane, BMP) would be enough for everybody, so lots of coders (including the Java developers) gambled on surrogates never being required, treating Unicode as a 16 bit character set, period. I remember well when the first first "supplementary" characters where introduced, causing a big discussion which would be simpler: Going to an internal 32 bit representation, or be prepared for surrogates. What happened "at some point in time" is that a lot of programmers suddenly realized that they could no longer ignore the concept of surrogates.
I suspect - correct me if I am wrong - that the concept of "variant selector" was introduced into Unicode at a later point, long after UTF-16 including surrogates. If you can handle surrogates properly, then the step to handle variant selectors isn't that long. (Actually, it is longer if you went for a 32 bit internal working format!)
Note that there is a distinction between internal working format and external storage format. You certainly know that, but sometimes it seems as if you do not (want to) keep them strictly separate. Java character representation is an internal working format while a string is being temporarily processed in memory (just like the interernal working format in Windows). When you write
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 Then you (note: you, not me) are moving out of the temporary internal working format domain. My comment about UTF-8 was given in that context. I am strongly in favor of storing all text in a database as UTF-8; certainly not as UTF-16.
Even though I have in fact delivered solutions on slower modems than that, it still has nothing to do with most business programming now. Consider it backgound information to explain to youngsters why a majority of Internet protocols (those based on RFC 822, 5322 today, which includes the majority of protocols seen by a user, such as SMTP, FTP, HTPP, SNMP for oldtimers ...) cannot handle even ISO 8859 - a fixed-size, 8 bit, extension of ASCII, the standard character set in 16-bit Windows. I bet that there are still *nix tool that stall if you give it ISO 8859 text!
I maintain that giving special attention to English when used in a limited context, the way you suggest, is a poor idea. Write all your software to always be prepared for non-ASCII characters, in any context - even when communicating in English with native English speakers within the US of A!
|
|
|
|
|
trønderen wrote: Java uses a subset of UTF-16 that excludes surrogate pairs
Ah...I wondered why your comments were so off base. No you are incorrect. It includes surrogate pairs. And it always has.
String (Java Platform SE 8 )[^]
"A String represents a string in the UTF-16 format in which supplementary characters are represented by surrogate pairs"
Matter of fact you can also use other languages in the code. Also something that has always been possible.
Java: Unicode in Source Code[^]
I am going to ignore the rest of your comments related to that since your initial assumption was wrong.
-----------------------------------------
trønderen wrote: You may notice that English is a well known...
As I already said, I have delivered internationalized products for decades.
And I have delivered products that were specifically limited to the United States. By their very nature.
trønderen wrote: 7-bit ASCII and nothing else to a subgroup of potential customers
Not sure exactly what you are referring to but I work in high volume applications. And thus the size of the data matters. Both on the wire and in storage.
And a lot of text even for international applications is not something that users see. So differentiating between the two is a design consideration.
trønderen wrote: storing all text in a database as UTF-8;
There are performance implications to doing that.
trønderen wrote: cannot handle even ISO 8859
And cars didn't have seat belts for decades. Hindsight means nothing.
trønderen wrote: Write all your software to always be prepared for non-ASCII characters, in any context
Absolutely not.
Just like I would not write an application to support 4 billion users just in case it might happen.
When I write software I get paid for writing it. Not for spinning endlessly about possibilities that very likely might never happen.
And I, perhaps unlike you, have worked on applications which would NEVER be used anywhere else. I am not going to detail that but consider if I had worked on a US defense contract for a nuclear missile. Do you think it will need to support the Russian language?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
