Java Beans: What am I missing?

I’m wondering if I’m missing something about Java Beans. I like my objects to do as much initialization in the constructor as possible and have a minimum number of mutators. Beans seem to go directly against this and generally feel clunky. What capabilities am I missing out on by not building my objects as Beans?


It sounds like you are on the right track. It’s not you who’s missing the point of Java Beans, it is other programmers that are misusing them.

The Java Beans specification was designed to be used with visual tools. The idea was that an application designer would be able to configure an instance of an object interactively, then serialize (or generate code for) the configured bean, so that it could be reconstructed at runtime; the intent was that it would not be mutated at runtime.

Unfortunately, a lot of developers don’t understand that accessors violate encapsulation. They use structs instead of objects. They don’t see anything wrong with other classes, even other packages, having dependencies on a class’s data members.

Of course, you will in general have the need to configure instances of your objects. It’s just that this should be done through some sort of configuration feature. This might be a dependency injection container, a “BeanBox” style visual tool, or simply reading JSON, XML, or properties files that you wrote by hand. The key is that at runtime these objects are effectively immutable; clients just invoke their operations, they don’t access their properties.


JSF initialize application-scope bean when context initialized

I’m building a JSF+Facelets web app, one piece of which is a method that scans a directory every so often and indexes any changes. This method is part of a bean which is in application scope. I have built a subclass of TimerTask to call the method every X milliseconds. My problem is getting the bean initialized. I can reference the bean on a page, and when I go to the page, the bean is initialized, and works as directed; what I would like instead is for the bean to be initialized when the web context is initialized, so that it doesn’t require a page visit to start the indexing method. Google has shown a few people that want this functionality, but no real solutions outside of integrating with Spring, which I really don’t want to do just to get this piece of functionality.

I’ve tried playing around with both the servlets that have “load-on-startup” set, and a ServletContextListener to get things going, and haven’t been able to get the set up right, either because there isn’t a FacesContext available, or because I can’t reference the bean from the JSF environment.

Is there any way to get a JSF bean initialized on web app startup?


If your code calls FacesContext, it will not work outside a thread associated with a JSF request lifecycle. A FacesContext object is created for every request and disposed at the end of the request. The reason you can fetch it via a static call is because it is set to a ThreadLocal at the start of the request. The lifecycle of a FacesContext bears no relation to that of a ServletContext.

Maybe this isn’t enough (it sounds like you’ve already been down this route), but you should be able to use a ServletContextListener to do what you want. Just make sure that any calls to the FacesContext are kept in the JSP’s request thread.




public class MyApplicationContextListener implements ServletContextListener {

    private static final String FOO = "foo";

    public void contextInitialized(ServletContextEvent event) {
        MyObject myObject = new MyObject();
        event.getServletContext().setAttribute(FOO, myObject);

    public void contextDestroyed(ServletContextEvent event) {
        MyObject myObject = (MyObject) event.getServletContext().getAttribute(
        try {
        } finally {


You can address this object via the JSF application scope (or just directly if no other variable exists with the same name):

    <h:outputText value="#{}" />
    <h:outputText value="#{foo.value}" />

If you wish to retrieve the object in a JSF managed bean, you can get it from the ExternalContext:


Java post-mortem debugging?

Is it possible to have a post-mortem ( or post-exception ) debugging session in Java ? What would the workarounds be ( if there isn’t a solution for this already ) ?


You can attach the debugger to a java process and set a breakpoint when a specific exception is received. Is this what you need?


When an exception occurs for which there isn’t a catch statement anywhere up a Java program’s stack, the Java runtime normally dumps an exception trace and exits. When running under jdb, however, that exception is treated as a non-recoverable breakpoint, and jdb stops at the offending instruction. If that class was compiled with the -g option, instance and local variables can be printed to determine the cause of the exception.

This type of breakpoints can be set with any IDE, such as Eclipse. Using eclipse you can also set a breakpoint on a specific exception type, even if it is caught in the normal code.

If you have something like a multi-threaded server running, and one of the threads servicing a client throws an unhandled exception, then you would be able to check the debugger and see what happens. I don’t think this is something for production, but definitively helps when testing.

The application does not have to run from the debugger, but it can be launched with the debug options as arguments:


The application runs normally, but switches into “interpreted” mode when a breakpoint is hit, at least in more modern versions of the JVM. So the performance is not affected.

Check the section about full-speed debugging for HotSpot VM

Full Speed Debugging

The Java HotSpot VM now uses full-speed debugging. In previous version of the VM, when debugging was enabled, the program executed using only the interpreter. Now, the full performance advantage of HotSpot technology is available to programs, even with compiled code. The improved performance allows long-running programs to be more easily debugged. It also allows testing to proceed at full speed. Once there is an exception, the debugger launches with full visibility to code sources.


When are API methods marked “deprecated” actually going to go away?

I’m code reviewing a change one of my co-workers just did, and he added a bunch of calls to Date.toMonth(), Date.toYear() and other deprecated Date methods. All these methods were deprecated in JDK 1.1, but he insists that it’s ok to use them because they haven’t gone away yet (we’re using JDK 1.5) and I’m saying they might go away any day now and he should use Calendar methods.

Has Sun/Oracle actually said when these things are going away, or does @deprecated just mean you lose style points?


Regarding the APIs, … it is not specified they will be removed anytime soon.

Incompatibilities in J2SE 5.0 (since 1.4.2):

Source Compatibility

In general, the policy is as follows, except for any incompatibilities listed further below:

Deprecated APIs are interfaces that are supported only for backwards compatibility. The javac compiler generates a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated APIs, though there are no current plans to remove such APIs – with the exception of JVMDI and JVMPI – entirely from the system.

Even in its How and When To Deprecate APIs, nothing is being said about a policy regarding actually removing the deprected APIs…

Update 10 years later, the new JDK9+ Enhanced Deprecation clarifies the depreciation policy.
See Jens Bannmann‘s answer for more details.
This is also detailed in this blog post by Vojtěch Růžička, following criticisms on JEP 277.

The convention for JDK is that once a JDK API is marked as forRemoval=true in a certain Java version, it will be removed in the directly following major Java release.
That means – when something is marked as forRemoval=true in Java 9, it is supposed to be completely removed in Java 10.
Keep that in mind when using API marked for removal.

Note that this convention applies only to JDK itself and third-party libraries are free to choose any convention they see fit.


Is a good idea to enable jmx (lambda probe) on a production server?

We are experiencing some slowdowns on our web-app deployed on a Tomcat 5.5.17 running on a Sun VM 1.5.0_06-b05 and our hosting company doesn’t gives enough data to find the problem.

We are considering installing lambda probe on the production server but it requires to enable JMX ( in order to obtain memory and CPU statistics.

Does enabling JMX incur a serious performance penalty?

If we enable JMX, are we opening any security flaw? Do I need to setup secure authentication if we are only enabling local access to JMX?

Is anyone using the same (tomcat + lambda probe) without problems on production?


Looking at the answers it seems that enabling JMX alone doesn’t incur significant overhead to the VM. The extra work may come if the monitoring application attached to the VM, be it JConsole, lambda probe or any other, is polling with excessive dedication.


You can cross out security flaws by using secure authentication. Just keeping the JMX service ready does not incur any significant overhead and is generally a good idea. There’s a benchmark here about this.

Source: stackoverflow
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Privacy Policy, and Copyright Policy. Content is available under CC BY-SA 3.0 unless otherwise noted. The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 © No Copyrights, All Questions are retrived from public domain..