Paul Clapham

I would recommend not using an IDE, or at least not using one which tries to write Swing code on your behalf. Instead I would recommend starting by writing the code yourself. (You can do this in an IDE, but just limit yourself to typing the code into a blank screen to start with.) There's a lot of Swing tutorials out there on the web, Oracle wrote a whole series of them back a decade and a half ago when Swing was more of a thing. They even come with prewritten code which you can examine and then play with. Try this one for a start: How to Use Text Fields.

If you're going to continue down that road, I would suggest starting with the simplest possible example. (I would suggest that anyway.) One form, one text field. See if you can get that working.

I find it hard to believe that the XML you just posted actually generated the code you showed us earlier.

However I notice that this line of XML:
         <text value="The textField should be populated when this form first opens"/>
is in a place where it looks like it should apply to a JLabel, rather than the JTextField which is described later.

It looks to me like you're trying to learn Swing and IntelliJ at the same time, which I think would be harder than doing it one at a time. I would expect you to run into problems where you can't tell whether it's Swing or IntelliJ that you don't quite understand.

I don't understand why you feel the need to use a listener to initialize that text field.

First of all you don't even create a text field, so you're just going to get NullPointerExceptions when you run that code. Your SecondForm class simply needs some code which creates a JTextField, adds it to the JFrame, and initializes its value. You'd put that before line 27. Unless there's some other requirement that I'm missing.

And, welcome to the Ranch!

Eugene Dakin wrote:What Java Listener should be used when populating a textField in a new form with data?

Well, this clearly isn't a question about IntelliJ so I'll move the thread to the Swing forum.

Thanks for posting your code here, by the way.

Would I be correct that you're asking about Swing components?

(By the way, asking people to install IntelliJ IDEA and download a zip file will substantially reduce the number of people who might consider answering your question. If you have a small example code -- which would be an excellent idea -- it would be better to post it here where everybody can read it.)

Yes, engineers have been using floating-point arithmetic basically since it was first available in computers. That would have been in the 1950's. People studying Numerical Analysis (who sometimes called themselves applied mathematicians) quickly discovered problems like that and developed rules to avoid them.

Jesse Silverman wrote:One of my first interactions with Team CodeRanch where I was exposed to be "That Guy" was showing how in recent versions of Java, it appeared that the String Constants now DO get interned lazily, rather than at load time as in days of yore.

Oh yeah, that thread. I was definitely in the "don't care" group so I didn't post to the thread. However other people's mileage may vary, and if they want to learn more about the minutiae of garbage collection in Java then I'm certainly not going to bug them about it. Go for it, I say.

Petros Papatheodoru wrote:it seems that some special rules apply to string literals, namely, that every method that uses a string literal, holds an implicit reference to it, so for the whole duration of the method, the string object in the pool is not eligible for GC

Not quite. Methods aren't objects and so they can't contain references to any objects. Instead, it's the class which naturally holds references to its objects. This includes the String literals which it contains. If I'm not mistaken its String literals are all added to the String pool at the time the class is loaded. If you're interested in a high level of detail about the String pool, you might want to look into that.

But even if the String literals were loaded into the String pool lazily (i.e. only the first time a method containing one would cause it to be added to the pool), it still wouldn't make sense for a String to be available for GC after calling a method caused it to be loaded. If, for example, that was a method which was run hundreds of thousands of times, that could result in its being repeatedly added to the pool and then garbage-collected. That would be a waste of time. So my expectation is that a String in the pool isn't available for GC until the class which caused it to be put there has been unloaded. Or more precisely, until all of the classes which caused it to be put there have been unloaded.

Petros Papatheodoru wrote:When the s1 reference goes out of scope (the inner scope), even if a minor GC event is triggered, the string object of the pool would not be collected. Not until method "Foo" finishes executing.

This is not correct. As the Stack Overflow thread which you linked to says, that string object cannot be garbage-collected until it is certain that method Foo will never again be executed. So as long as the class which contains that method is still loaded, it's possible that Foo could be executed at some future time.

The SO thread goes on to talk about situations in which a class might be unloaded and thus possibly allow for garbage collection of string literals created by that class. But it doesn't go into details about how a garbage collector might identify such string literals and it doesn't say that any garbage collectors actually do that. I would also remind you that there is more than one garbage collector, which makes the task of finding out how "the garbage collector" works more difficult. (There's even a garbage collector whose only feature is that it never collects any objects.)

People used to use decompilers to convert the bytecode back to Java code, which they could then edit for whatever changes they needed to make. This was done when the original source code was unavailable.

Of course the unavailability of the source code was often done on purpose by its owner and this process was of dubious correctness, but "The dog ate my source code" could be used to cover that up. And occasionally it was true -- the source code was lost to a disk crash but the compiled classes were accessible on the computer where they had been installed.

However that hasn't been feasible since about Java 5. That's when generics arrived to complicate the process with "erasure", and subsequent Java features made it even more infeasible.

But anyway it seems that the OP does have the source code, so that's not relevant. Personally I wouldn't dare to mess with the bytecode either.

Jesse Silverman wrote:The input validation exceptions we are discussing here are "RuntimeException" classes, right?

Yes, NumberFormatException, which can be thrown by Integer.parseInt(String), is a subclass of RuntimeException. Referring to the original post (and not the large quantity of tangential content following it), it mentions "validation of keyboard input". There's a lot of other situations where you might be given a String value and you want to convert it to a numeric (e.g. Integer) value, but let's just consider that. (You might be getting the data from a text file or a spreadsheet cell or an HTTP request or you name it.)

The original post says that this conversion "could easily be handled without try or catch". It's true that you could write some code which converts String to Integer without too much difficulty, although String to Double is considerably harder. But really. Why should the beginner with two days of Java learning under their belt be required to do that as part of writing their code which wants to get a number from the console? Just dealing with getting input from the console is enough to drive some beginners to drink. And so we have the parseInt and parseDouble and so on methods.

And of course when parsing a String value to a numeric value, you have to consider the possibility that there's going to be a problem because the input isn't a valid numeric value (for whatever "numeric" means in the current context). Languages without exceptions would have used various hacks to deal with that, but Java has exceptions built into the language and when exceptional situations occur then you should use exceptions to deal with them. This is in no way an anti-pattern, not in Java anyway. I don't see why errors in user input should be treated differently than errors with network connections or database queries.

But back to why NumberFormatException is a runtime exception, whereas FileNotFoundException is a checked exception: I have no idea why they did that -- as I just said or implied, I wouldn't have done it that way. Finding non-numeric data in Strings which are only supposed to contain numeric data is not a programming error, like using a null value where it shouldn't be found or using an array index which points outside the array. Those things can be checked simply by code and avoided, so they can be classified as programming errors, but checking data for numericness is not simple to do and it's not reasonable to expect the programmer to write code which does that.

That class disappeared when Java 9 was released, and probably you have recently upgraded to Java 9 or later.

However this Stack Overflow thread describes what you need to do instead -- I just tried it and it does compile, at least.

The constructor of TreeRow that you declared starting at line 125 must start by calling a constructor of its superclass, which is Row, via the "super" keyword. Alternatively, if the superclass has a constructor with zero parameters then this requirement may be ignored, and the compiler will silently insert a call to that constructor. Or your third choice is to call a constructor of the same class, via the "this" keyword. That's a rule of Java.

But apparently Row doesn't have a zero-parameter constructor so you need to call one of its constructors. I don't know what those constructors are since Row isn't declared there, so you would have to check the documentation.

But note the other constructor at line 121, which calls another TreeRow constructor using the "this" keyword. That compiles correctly, but it is kind of a problem because it totally disregards the TreeBasedTable parameter which is passed to it. Ignoring that data points to some kind of a design problem.

You said (sort of) that you didn't write that code, though. Probably when you said you "imported a package" that meant you downloaded the code from somewhere. There's nothing wrong with that, people do it all the time. But you aren't guaranteed to get workable code when you do that, so when you run into problems you either have to fix them yourself or track down the people who wrote the code and get them to help.

Notice the annotation at line 21: @Beta. That (to me) implies that the code is beta-version code, meaning that there are definitely no guarantees. Although not even compiling is a bit surprising.

James, I have about 700 classes in the app that I wrote and still use. Would you advise me to put them all in one file?