Brett Spell

No, there's no way to set the user of a print job. JobOriginatingUserName is really only intended to be used to query (not set) the user name, which is why you can't assign a value for a PrintRequestAttributeSet.

As far as documentation on this goes, I believe this would be the most relevant page I can find offhand: Attribute Roles.

Basically what it says is that not every attribute is valid in every context.

C Bulow wrote:For frontend it seems divided between using Swing or JavaFX, or perhaps go with a web based like Angular.

Angular or a similar alternative (e.g., React) would probably be the best choice long term.

C Bulow wrote:For Swing and JavaFX, are there any decent GUI builder tools available to speed up development and ease maintenance?

The already-mentioned Window Builder is a popular option for Swing, and a lot of people seem to like Jigloo.

C Bulow wrote:And from what I can remember, building Java Swing GUI by hand was quite tedious but I don't know if that's changed.

No, it hasn't. But in my opinion that tends to be the nature of UI work in general. At least that's been my experience with both desktop and web UI frameworks.

C Bulow wrote:What do you prefer when making GUI?

Personally I don't use GUI builders because they tend to produce code that's hard to maintain "manually" (without the builder), which means that they'll save you time in the short term but cost you time in the long term. Your mileage may vary.

The key to understanding this is to realize that "top-level" (a.k.a. "heavyweight") / window components are represented by two entities: the Java (e.g., JFrame) object, and a counterpart (or "peer") that's managed by the native operating system. It's the "native peer" that you actually see, and the Java object is really just a wrapper around it. Calling dispose() releases the resources associated with the peer, but otherwise doesn't really affect the state of the Java object. The Java object contains information like the title, size, location, etc., so it can easily be used to create a brand new peer later with the same state as the original.

Without an SSCCE, I can only speculate as to what's wrong. My guess would be that either you aren't constructing the component(s) correctly or that you're doing something that blocks the Event Dispatch Thread (EDT), preventing it from painting / displaying the content.

mitchell bat wrote:What would you recommend to use for just one component?

That depends on what the desired behavior is regarding that one component's size and position within its parent container. Without knowing more about that I could only speculate that either FlowLayout or GridBagLayout would be the best choice.

JOptionPane is just a convenience "wrapper" class that creates cookie-cutter instances of JDialog. If I understand correctly what you're trying to do, the easiest way to accomplish it is just to create your own JDialog and use setDefaultCloseOperation() to specify that attempts to close it should be ignored.

This was written in the JavaFX mailing list about six months ago by Donald Smith, Senior Director of Product Managment at Oracle Corporation:

I understand that while there is both Swing and JavaFX available that people will continue to question the existence of each — so be it. Each has it’s own niches and benefits and our strategy, as it has been for years now, is to continue with each (emphasis mine).

Campbell Ritchie wrote:no, they appear to have stopped maintaining Swing.

Why do you say that? I just checked the Swing mailing list, and it has current / recent activity from Oracle employees regarding bug fixes.

Dave Tolls wrote:Swing hasn't been supported for quite some time now.

I guess that depends on your definition of "supported". If you mean adding new features then you're right, but if you mean bug fixes that's not correct.

Dave Tolls wrote:JavaFX is the main desktop UI these days.

Again, what's your definition of "main desktop UI"? JavaFX certainly was marketed heavily in years past by Oracle -- though even that seems to have faded -- but it never gained traction in the marketplace and is far less commonly used than Swing.

Stevens Miller wrote:

Brett Spell wrote:Or look on Stack Overflow.

Dear God, man, don't send a beginner to StackOverflow! They eat beginners alive there and use their bones to pick their teeth.

You're right: I should have clarified that Snark Overflow is prescribed for external (google) use only.

jon ninpoja wrote:at this stage i am a hobbyist programmer who would like to enter the work place in a few years (3-4) time.
i dont want to waste my time on technologies that will not benefit me in future.

My experience matches what Bear and Stevens already posted: there's far more Java work on web applications (mainly back end / web services) these days, so if having the most marketable job skills is what you want then you should focus on back end (RESTful web service) development. If you do go with this approach then you should also seriously consider learning JavaScript, which is often used for the front end (UI) on web applications.

However, if you're determined to stick with desktop development then as Stevens said, Swing is the way to go. It's only "dead" in the Oracle marketing department, whereas JavaFX never took off in the first place and there's no reason to believe that will ever change. Go to any of the job boards and see how many Swing jobs there are versus JavaFX. Or check the relative amount of activity on here for Swing versus JavaFX. Or look on Stack Overflow. You'll see what I mean.

Campbell Ritchie wrote:Now, having "Hello, Brett" appear in an option pane would entail real OO programming

A "Hello, Campbell!" would be at least as good.

Campbell Ritchie wrote:We seem to be in agreement that OP has unfortunately been required to use a less than optimal implementation.

Yes, I agree that this isn't the way I'd want to start someone out who's trying to learn to code in Java. Having said that, though, it is arguably more satisfying to see "Hello, world!" pop up in a GUI (which is what most people think of as a software application) as opposed to the text appearing in a DOS window.

Campbell Ritchie wrote:you should regard option pane as obsolete for a command line application.
...
If you have a non‑GUI app running from an executable .jar, option pane will probably be your favoured method for input and output.

Using option pane isn't "obsolete" for a command line application because it never represented a command-line solution in the first place. Again, if you're advocating mixing command-line and GUI elements in a single application, I'm guessing that you haven't done much desktop development.

Liutauras Vilda wrote:OP not creating a GUI application, he is taking the keyboard input with GUI component (I wouldn't call it a GUI for application)

The application posted contains code to display an option pane, so by definition it is a GUI application.

Liutauras Vilda wrote:Try imagine you have an application window, and for the input pops out another window for input...

I'm not sure how your scenario is relevant since this isn't what the OP described or plans. But since we're speaking hypothetically, try imagining a Swing (or any other GUI) application that suddenly stops responding to the user because it's expecting them to enter text in a shell / DOS widow. Is that really something you'd advocate? If so, I'm guessing you don't do much desktop GUI development.

JOptionPane hasn't been superseded by anything, certainly not Scanner, and in any case the OP said that using JOptionPane is a requirement. Writing a command line-based application would be a reasonable alternative to a GUI application for someone learning to write code, but that's not what's being discussed here.