Java

Re: How can I integrate ChatGPT into my Spring Boot application?

27-Dec-23 23:47

Go to the ChatGPT website and ask them.

Gerry Schmitz28-Dec-23 6:41

Gerry Schmitz

28-Dec-23 6:41

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

Re: How can I integrate ChatGPT into my Spring Boot application?

Richard MacCutchan28-Dec-23 6:58

Re: How can I integrate ChatGPT into my Spring Boot application?

28-Dec-23 6:58

Gerry Schmitz wrote:
"Why?"

Probably because he doesn't understand ... anything. Roll eyes | :rolleyes:

jschell29-Dec-23 5:19

debugger stop button behaving weirdly

29-Dec-23 5:19

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.

mike741120-Dec-23 19:08

mike7411

20-Dec-23 19:08

I am using IntelliJ IDEA 2023.3.1 (Community Edition), and I'm seeing some weirdness.

I made a simple test.

Java

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.

Gerry Schmitz20-Dec-23 20:45

Gerry Schmitz

20-Dec-23 20:45

... because a to upper without an assignment makes no sense anyway.

jschell21-Dec-23 3:41

21-Dec-23 3:41

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.

Gerry Schmitz21-Dec-23 7:41

Gerry Schmitz

21-Dec-23 7:41

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?

jschell22-Dec-23 6:00

22-Dec-23 6:00

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.

Richard MacCutchan20-Dec-23 22:09

20-Dec-23 22:09

Are you certain you pressed the stop button?

jschell21-Dec-23 3:48

21-Dec-23 3:48

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);

Richard MacCutchan21-Dec-23 23:09

21-Dec-23 23:09

~~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.

Intellij

anderson mendes 202312-Dec-23 9:13

anderson mendes 2023

12-Dec-23 9:13

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

Re: Intellij

Richard MacCutchan12-Dec-23 22:04

12-Dec-23 22:04

Probably be studying the documentation for the types you are trying to use. Without more information as to your exact problem it is impossible to say more.

See GUI Designer Basics | IntelliJ IDEA Documentation[^]

modified 13-Dec-23 5:49am.

Java strings

mike74114-Dec-23 16:12

mike7411

4-Dec-23 16:12

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.

Richard MacCutchan4-Dec-23 22:17

String (Java Platform SE 8 )[^]

4-Dec-23 22:17

Andre Oosthuizen5-Dec-23 8:47

Andre Oosthuizen

5-Dec-23 8:47

Plain and simple Google, not AI... Is Java string characters 16-bit [^]

Richard MacCutchan5-Dec-23 9:26

5-Dec-23 9:26

Being an old codger, I find Google is quite intelligent enough for me.

jschell5-Dec-23 5:26

5-Dec-23 5:26

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.

trønderen5-Dec-23 11:29

trønderen

5-Dec-23 11:29

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!

jschell6-Dec-23 6:33

6-Dec-23 6:33

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.

trønderen6-Dec-23 9:53

trønderen

6-Dec-23 9:53

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!

jschell7-Dec-23 4:43