We Keep Coding

What's the proper way for a `BasicLookAndFeel` subclass to activate anti-aliasing in Java 11?

I have this in-house Swing Look&Feel, and as is usual for a migration to Java 11, usages of SwingUtilities2 members are to be replaced by official APIs.
Most are solved, but I haven't found any working advice how to crack anti-aliasing.
The L&F is built as a subclass of BasicLookAndFeel, which has mechanisms for anti-aliasing; however, these seem to require activation through defaults.put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, AATextInfo.getAATextInfo(SwingUtilities2.isLocalDisplay()));, which replicates what other Swing L&Fs are doing to enable AA, but with Java 11 this API isn't accessible anymore.
I have fiddled with setting RenderingHints in many likely and even some unlikely places, to no avail; for some reason, the settings never gain traction.
I am almost done analyzing the situation using the debugger (breakpoint on the L&F's LabelUI.paint() function and single-stepping through all the decisionmaking logic), but I found that BasicLookAndFeel seems to be hardcoded to use AATextInfo objects to pass hints, which I can't use if I maintain my own L&F.
So... what are my options?
I could probably use a different base class, but that's... scary.
(I know that #kleopatra has called anti-aliasing a "story-without-happy-ending", but this is about picking up the preconfigured hints and properly applying them, not about wilfully switching AA on or off.)

Anti-aliasing settings from the Look&Feel are picked up by JComponent.setUI().
In Java 8, it does UIManager.getDefaults().get(SwingUtilities2.AA_TEXT_PROPERTY_KEY).
In Java 9, it does UIManager.getDefaults().get(RenderingHints.KEY_TEXT_ANTIALIASING).
There is no gradual transition so that you can clean up the API in one step and transition to a newer Java in a separate step, you have to do both at the same time.

Can I use deprecated classes?

Will using deprecated classes cause severe problems to the program?
What is the meaning of deprecated?
Can I still work with deprecated classes?
An example for it is the ProgressDialog view in Android. It deprecated from API 26 and the replacement is the ProgressBar view. What happens if I will still use the ProgressDialog? It is extremely comfortable and exactly what I was aiming for.

From the documentation:
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. Compilers warn when a deprecated program element is used or overridden in non-deprecated code.
So you can use some deprecated methods but it won't be the best practice because there are better alternative exists(but in some cases this can even be dangerous)

Yes and no. You can use them for maintaining old API levels, tacking into account that in newer android versions these classes may be removed. So usually you would wrap its usage in a if/else condition to use them only to maintain such functionality in old Android versions, only when there is no compatible replacement in newer versions.

Google has a bad habit of not maintaining back-compatibility which is an essential best practice in computer science and technology. I appreciate that deprecated means there are better alternatives and the comment "In theory, the deprecated libraries you are using should be supported indefinitely. However, the Google Play Store may at some point not support your API level, which means you might not be able to keep updating your app." is very pertinent. API level should be able to continue supporting those "deprecated" classes. I am very sure many of us can find several examples where so called "deprecated" are much better than their "updated" alternatives.

XML vs Programmatically for android user interface [duplicate]

This question has been bugging me for some time. I've already developed a couple of apps on the Android platform and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable? Or should XML files be the go-to approach? I usually find XML a more tedious approach and often, these layouts don't look the same on all devices. I just don't get it. From a professional viewpoint, has anyone really been able to develop apps with complex views purely using XML files? This question is killing me because Google recommends using XML but the UI never looks the same on all devices unless done programmatically. Or am I doing something wrong?
Note that I'm referring to Android 2.2 and 2.3, which majority of the users use.

I use XML layouts on pretty much every fragment and activity of every app I write. I very rarely see any need to create Views dynamically, tho configuration of ListViews, showing/hiding views, etc needs doing in code. For me the advantages of XML are:
Ability to use layout editors (Eclipse)
Easier to preview layouts
Possible to benefit from auto-localisation of layouts
Easily maintain different parallel layouts for difference devices (screens)
Can get a sense of the layout by looking at it (easier than code)
Easy to break layouts down into pieces (fragments, includes, etc) to remove duplication
Keeps a separation between the visual design, and the functionality behind it
I can't think of any good reasons to put all my layouts into code - that sounds like hell.
I expect the reason your layouts don't look the same is because your XML is not defining the layouts correctly. Bear in mind the Android tools convert XML layouts into code, so there's no inherent problem with using XML layouts versus dynamic - both end up as code.

OckhamsRazor,
The answer very much depends on your needs, flexibility, and knowledge. The first thing to understand is that every Layout, whether created via XML or programmatically can be tweaked specifically or made to conform to many screens via properties.
... and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable?
Yes, it is. Android makes those available so you can do just that. However, the benefits of managing layouts via XML include standard MVC segregation, simpler debugging, and an easier time modifying the resource, if needed. Additionally, you may maintain multiple copies of Layouts depending on device configuration easily.
... has anyone really been able to develop apps with complex views purely using XML files?
Absolutely! There are some amazing programs that fully utilize XML rather than programmatic views. The key to them is how much information (that is non-standard view properties) is required from parental Views. Even in those cases there are ways to pass that information provided you know where and how to do so.
Or am I doing something wrong?
I don't think so. Honestly, I've run both ways depending on need. I'd say it really comes down to your lack of knowledge of the quirks. But the job is to get the job done. Here's an example: There are some times when I don't know how big everything needs to be until its run on the device, and there are times that I make the device conform to my layout's needs. Ultimately, I use the following chart to make my determinations.
Do I need information from parental Layouts that is aside from view properties
Do I need to dynamically size more than one element independently.
Is the View type pre-determined or will it change as well?
If the answer to 2 out of 3 of those is "yes", I will use some level of programmatic layout. If not, I will go pure XML. That being said, programming is one of those professions that encourages ingenuity (provided it is safe) and nearly anything can be accomplished in any number of ways. Ultimately, I'd say do whatever makes your job making quality apps easier.
Google makes its recommendations based on their own knowledge of software programmers and their general practices. They also created the platform, so they know which things are optimized in which ways. Its all about experience and we all have our own. If you have trouble utilizing XML, its worth taking the time to figure out the quirks simply so that it is another tool to utilize. Also, it will give you the information you need to answer this question for yourself.
To sum things up: I could say chocolate is better, but if you like vanilla, you'll disagree. Be aware of the drawbacks and benefits of each and take the time to learn how to accomplish the same tasks with both methods. It will make you a better programmer and give you a better sense of when to use which technique.
Hope this helps,
FuzzicalLogic

I typically do a lot of work with highly customizable UIs, where large portions of it need to be done in code. That being said, wherever possible I try to use layout fragments and inflate them, so as UI sections are added, removed, or rearranged I'm still just doing some of the layout, not all of it.
That being said, it's not that hard doing layout via code. The big advantage to it is compile-time checking. I'll find issues that way faster than using the preview pane. The preview pane can be nice for initial layout, but I use the Hierarchy Viewer for figuring out why my layouts don't look right.

It really depends on what type of project it is, or piece of a project, and what type of programmer you are. Some people just prefer pure code, while others like leaning as much on other tools for design as possible.
XML definitely has some benefits, like being able to switch between interface designs quickly. For specific design themes that are repetitive, is definitely useful for most programmers.
I personally prefer doing everything programmatically, and it is quicker for me to develop than writing XML, with the libraries and classes I have created. XML is quicker straight out of the box.
As for performance, there really isn't a difference worth mentioning unless you are using the same view so repetitively, at the same time, to the point that it no longer fits on the screen many fold. I did a test of how many text views Android could render on a Moto X - Android 4.4, and it couldn't get much over 5000, but there is never a purpose for that. If you are at that point, you are either need to dynamically load and unload data or are just doing something very wrong to begin with.
So learn both sides of it, definitely get to know the pros and cons with your style of programming, because there is no right answer for everyone, and let loose and have fun.

It is much better to separate the layout and put it in the xml file. I occasionally have to adjust the layout in code, but it is always an exception and only when I determine that it cannot be done in the layout .xml. If you use the layout views correctly, the application should look very similar on all devices.

Is it wrong to use Deprecated methods or classes in Java?

I am using eclipse to develop a web application. Just today I have updated my struts version by changing the JAR file. I am getting warnings at some places that methods are deprecated, but the code is working fine.
I want to know some things
Is it wrong to use Deprecated methods or classes in Java?
What if I don't change any method and run my application with warnings that I have, will it create any performance issue.

1. Is it wrong to use Deprecated methods or classes in Java?
From the definition of deprecated:
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
The method is kept in the API for backward compatibility for an unspecified period of time, and may in future releases be removed. That is, no, it's not wrong, but there is a better way of doing it, which is more robust against API changes.
2. What if I don't change any method and run my application with warnings that I have, will it create any performance issue.
Most likely no. It will continue to work as before the deprecation. The contract of the API method will not change. If some internal data structure changes in favor of a new, better method, there could be a performance impact, but it's quite unlikely.
The funniest deprecation in the Java API, is imo, the FontMetrics.getMaxDecent. Reason for deprecation: Spelling error.
Deprecated. As of JDK version 1.1.1, replaced by getMaxDescent().

You can still use deprecated code without performance being changed, but the whole point of deprecating a method/class is to let users know there's now a better way of using it, and that in a future release the deprecated code is likely to be removed.

Terminology
From the official Sun glossary:
deprecation: Refers to a class, interface, constructor, method or field that is no longer recommended, and may cease to exist in a future version.
From the how-and-when to deprecate guide:
You may have heard the term, "self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.
The #Deprecated annotation went a step further and warn of danger:
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
References
java.sun.com Glossary
Language guide/How and When to Deprecate APIs
Annotation Type Deprecated API
Right or wrong?
The question of whether it's right or wrong to use deprecated methods will have to be examined on individual basis. Here are ALL the quotes where the word "deprecated" appears in Effective Java 2nd Edition:
Item 7: Avoid finalizers: The only methods that claim to guarantee finalization are System.runFinalizersOnExit and its evil twin Runtime.runFinalizersOnExit. These methods are fatally flawed and have been deprecated.
Item 66: Synchronize access to shared mutable data: The libraries provide the Thread.stop method, but this method was deprecated long ago because it's inherently unsafe -- its use can result in data corruption.
Item 70: Document thread safety: The System.runFinalizersOnExit method is thread-hostile and has been deprecated.
Item 73: Avoid thread groups: They allow you to apply certain Thread primitives to a bunch of threads at once. Several of these primitives have been deprecated, and the remainder are infrequently used. [...] thread groups are obsolete.
So at least with all of the above methods, it's clearly wrong to use them, at least according to Josh Bloch.
With other methods, you'd have to consider the issues individually, and understand WHY they were deprecated, but generally speaking, when the decision to deprecate is justified, it will tend to lean toward wrong than right to continue using them.
Related questions
Difference between a Deprecated and Legacy API?

Aside from all the excellent responses above I found there is another reason to remove deprecated API calls.
Be researching why a call is deprecated I often find myself learning interesting things about the Java/the API/the Framework. There is often a good reason why a method is being deprecated and understanding these reasons leads to deeper insights.
So from a learning/growing perspective, it is also a worthwhile effort

It certainly doesn't create a performance issue -- deprecated means in the future it's likely that function won't be part of the library anymore, so you should avoid using it in new code and change your old code to stop using it, so you don't run into problems one day when you upgrade struts and find that function is no longer present

It's not wrong, it's just not recommended. It generally means that at this point there is a better way of doing things and you'd do good if you use the new improved way. Some deprecated stuff are really dangerous and should be avoided altogether. The new way can yield better performance than the deprecated one, but it's not always the case.

You may have heard the term, "self-deprecating humor". That is humor that minimizes your importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that it should no longer be used at all, as it will probably cease to exist in the future.
Try to avoid it

Generally no, it's not absolutely wrong to use deprecated methods as long as you have a good contingency plan to avoid any problems if/when those methods disappear from the library you're using. With Java API itself this never happens but with just about anything else it means that it's going to be removed. If you specifically plan not to upgrade (although you most likely should in the long run) your software's supporting libraries then there's no problem in using deprecated methods.
No.

Yes, it is wrong.
Deprecated methods or classes will be removed in future versions of Java and should not be used. In each case, there should be an alternative available. Use that.
There are a couple of cases when you have to use a deprecated class or method in order to meet a project goal. In this case, you really have no choice but to use it. Future versions of Java may break that code, but if it's a requirement you have to live with that. It probably isn't the first time you had to do something wrong in order to meet a project requirement, and it certainly won't be the last.
When you upgrade to a new version of Java or some other library, sometimes a method or a class you were using becomes deprecated. Deprecated methods are not supported, but shouldn't produce unexpected results. That doesn't mean that they won't, though, so switch your code ASAP.
The deprecation process is there to make sure that authors have enough time to change their code over from an old API to a new API. Make use of this time. Change your code over ASAP.

It is not wrong, but some of the deprecated methods are removed in the future versions of the software, so you will possibly end up with not working code.

Is it wrong to use Deprecated methods or classes in Java?"
Not wrong as such but it can save you some trouble. Here is an example where it's strongly discouraged to use a deprecated method:
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
Why is Thread.stop deprecated?
Because it is inherently unsafe.
Stopping a thread causes it to unlock
all the monitors that it has locked.
(The monitors are unlocked as the
ThreadDeath exception propagates up
the stack.) If any of the objects
previously protected by these monitors
were in an inconsistent state, other
threads may now view these objects in
an inconsistent state. Such objects
are said to be damaged. When threads
operate on damaged objects, arbitrary
behavior can result. This behavior may
be subtle and difficult to detect, or
it may be pronounced. Unlike other
unchecked exceptions, ThreadDeath
kills threads silently; thus, the user
has no warning that his program may be
corrupted. The corruption can manifest
itself at any time after the actual
damage occurs, even hours or days in
the future.
What if don't change any method and run my application with warnings that I have, will it create any performance issue.
There should be no issues in terms of performance. The standard API is designed to respect some backward compatibility so applications can be gradually adapted to newer versions of Java.

Is it wrong to use Deprecated methods or classes in Java?
It is not "wrong", still working but avoid it as much as possible.
Suppose there is a security vulnerability associated with a method and the developers determine that it is a design flaw. So they may decide to deprecate the method and introduce the new way.
So if you still use the old method, you have a threat. So be aware of the reason to the deprecation and check whether how it affects to you.
what if don't change any method and run my application with warnings that I have, will it create any performance issue.
If the deprecation is due to a performance issue, then you will suffer from a performance issue, otherwise there is no reason to have such a problem. Again would like to point out, be aware of the reason to deprecation.

In Java it's #Deprecated, in C# it's [Obsolete].
I think I prefer C#'s terminology. It just means it's obsolete. You can still use it if you want to, but there's probably a better way.
It's like using Windows 3.1 instead of Windows 7 if you believe that Windows 3.1 is obsolete. You can still use it, but there's probably better features in a future version, plus the future versions will probably be supported - the obsolete one won't be.
Same for Java's #Deprecated - you can still use the method, but at your own risk - in future, it might have better alternatives, and might not even be supported.
If you are using code that is deprecated, it's usually fine, as long as you don't have to upgrade to a newer API - the deprecated code might not exist there. I suggest if you see something that is using deprecated code, to update to use the newer alternatives (this is usually pointed out on the annotation or in a Javadoc deprecated comment).
Edit: And as pointed out by Michael, if the reason for deprecation is due to a flaw in the functionality (or because the functionality should not even exist), then obviously, one shouldn't use the deprecated code.

Of course not - since the whole Java is getting #Deprecated :-) you can feel free to use them for as long as Java lasts. Not going to notice any diff anyway, unless it's something really broken. Meaning - have to read about it and then decide.
In .Net however, when something is declared [Obsolete], go and read about it immediately even if you never used it before - you have about 50% chance that it's more efficient and/or easier to use than replacement :-))
So in general, it can be quite beneficial to be techno-conservative these days, but you have to do your reading chore first.

I feel that deprecated method means; there is an alternate=ive method available which is better in all aspects than existing method. Better to use the good method than existing old method. For backward compatibility, old methods are left as deprecated.

Matisse or Jigloo?

We have a dilemma; developing desktop application using Matisse or Jigloo..
Matisse has this XML form files which we are afraid of maintaining later, we don't even know should MyEclipse further support Matisse, even Netbeans - do you think they will give up OS support of Matisse?
More or less Jigloo and Matisse have similar behaviour, although Jigloo obeys more designers wish, Matisse has this strange alignment behaviour from time to time.
Jigloo generates Java code which can be edited and which in turn can cause visual editor not being able to draw form. That is probably the reason why Matisse wants to have definition of elements in more stable XML form from which it generates java code.
Matisse would not help much if there is an error in instantiating a GUI element, so putting custom elements can be also nightmare.
When typing code in Jigloo, the visual editor likes to erase picture so you have to wait for picture to show up after editing code. In Matisse you can have errors in class and still editing GUI.
Please help us by voting, what do you prefer more and why.

Please don't use either! As with this answer, it's my strong opinion (after writing Swing GUIs for 10 years), that using GUI builders is, in all but the most edge-cases, a bad idea. HAND CODE YOUR GUI!
Whether you choose Matisse or Jigloo, it is not a standard, will fall out of favour and a better tool will come along. At that point, you will have legacy code that is nigh on impossible to maintain. This has already happened several times in the history of Java GUI builders.
You should avoid forcing your developers to use one IDE and it is a huge overhead to expect devs to switch to a particular IDE when looking at the GUI code. They'll be frustrated as they can't remember key bindings, project setup is out-of-date, they have the wrong version installed etc. People will make quick-fixes without the builder. At this point your code is unmaintainable in both your IDE of choice, and in the GUI builder istelf! The whole thing is a mess.
Designing a GUI is not, in my experience, a particularly onerous task and probably accounts for no more than 5-10% of the total development time of an application. Even if initially using Matisse or Jigloo provides you with a 50% time advantage over hand-coding the GUI, this is insignificant in the grand scheme of things. It is certainly not worth the hidden costs and impending maintenance disasters that lie ahead.
GridBagLayout is not hard. It just isn't! It's really simple, in fact. It will take you a few minutes to learn and after that you'll never look back. Your GUIs will look like how you want them to look and your code will be more maintainable as a result. Use GridBagLayout!
I have spent a good deal of time warning people about this before and been proven correct.

I have personally had a handful of occasions where the XML file backing a Matisse form somehow became out of sync with the code and had to resort to a backup to get it working again. This was enough to scare me away. I have no experience with Jigloo, though.
My current projects use TableLayout, extensively. It is easy to understand and (of all the layout managers I've tried) maintain. I have not found any other solution in GUI design for Java that I feel more comfortable with than coding the GUIs by hand. Moving forward, it seems like the best "future-proof" way of coding my GUIs.
I agree with Chintan on using Matisse or similar to mock up your design and then convert the layout to another layout (like TableLayout). Personally, I like using pencil and paper to do most of it. Not exactly high-tech, but it gets the job done.

I wouldn't go with either. The best thing I've found so far is Instantiations Swing Designer. It is not free, but not expensive either. It supports all major Swing layouts and DOES NOT create any additional artifacts except pure Java code.
Here is the link, if your are interested.

I would prefer Matisse since Netbeans is backed by Sun Microsystems and the possibility of the project being scrapped in the near futures seems blissfully low.
Also, I do not know the size of your project but I have developed some small ones and I personally use matisse to see how the layout would look and then go ahead and code everything using the Miglayout library. It increases the amount of coding a lot but gives good control and flexibility. And there is a possibility this library might be included in Java 7, consequently embedded into Matisse.

I prefer Netbeans Matise. Even if it is impossible to edit generated code, it's much more easier to design complex screens with Mattise(because of FreeForm layout).

I haven't tried Jigloo, but I would throw a fourth one in the mix.
JFormDesigner is the best Swing UI designer that I have ever used.
Like Matisse, it does create XML form files, but that is the only negative about this tool.
It supports all standard layout managers, plus some popular ones (such as JGoodies FormLayout). It has plugins for IntelliJ and eclipse and can also run as a standalone tool.
Here is the link
hth
Koen

What you can expect when you mess a file generated by a tool? Mess, isn't it?
This is a very very important always forgotten by developers.
Take Matisse as an example. It generates a XML file for you and a .java file for you.
Why on Earth developers start changing these classes?
Later they complain that everything is messed and they point out to Matisse as the guilt of it, because Matisse doesn't do A or doesn't do B. The only thing Matisse is guilty is not being able to fix the mess promoted by developers. This is problem in the domain of Artificial Inteligence and I personally do not expect any solution soon.
There's a more or less simple solution for it: OOP.
I explain: one of the most important concepts of OOP is 'responsibility', which means that a certain class has a limited and well defined responsibility in a broader and more complex problem domain.
So, Matisse generated the UI for you, which basically consists on UI elements, event handlers, etc.
Then you say: well... I need to add some logic to it otherwise the UI is innoperative. True. This is another responsibility, which cannot never be implemented in the same class generated by Matisse. Because either people is lazy or do not understand what 'responsibility' means in OOP, people implement whateber they need, add lots of variables and promote all sort of madness in a class which is definitely not responsible for business logic.
By a very simple thing like inheritance you can separate business logic in a extended class. The base class is the one produced by Matisse. The extended one is your class implemented by hand which contain implementation of event handlers, initialization of UI elements, etc.
Many developers are tempted to edit by hand the .java file produced by Matisse.
The golden rule is: never, never edit the .java file by hand. Matisse provides you means of defining whatever you need and call whatever you need. Never editing resources (both .xml and .java) produced by Matisse, you guarantee that it (Matisse) will be able to load it again in case you need to change the GUI in future. Probably you will find yourself tempted to edit the .java or even the .xml file directly. Please resist this temptation and educate yourself; you will thank yourself in future.
So... you can use whatever tool you wish or whatever provides the sexiest UI elements.
All tools will fail if you fail to separate UI from business logic.
All tools will succeed if you succeed in your main task as programmer which is: produce decent code.

Use WindowBuilder and be happy.
https://projects.eclipse.org/projects/tools.windowbuilder
Eclipse WindowBuilder is composed of Eclipse SWT Designer and Eclipse Swing Designer and makes it very easy to create Java GUI applications without spending a lot of time writing code. Use the WYSIWYG visual designer and layout tools to create simple forms to complex windows; the Java code will be generated for you. Easily add controls using drag-and-drop, add event handlers to your controls, change various properties of controls using a property editor, internationalize your app and much more.
Generated code doesn't require any additional custom libraries to compile and run: all of the generated code can be used without having WindowBuilder installed. WindowBuilder can read and write almost any format and reverse-engineer most hand-written Java GUI code. It also supports free-form code editing (make changes anywhere, not just in special areas) and most user refactorings (you can move, rename and subdivide methods without a problem).