ClassNotLoadedException.java revision 13430:5e8370fb3ed9 
1/*
2 * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved.
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4 *
5 * This code is free software; you can redistribute it and/or modify it
6 * under the terms of the GNU General Public License version 2 only, as
7 * published by the Free Software Foundation.  Oracle designates this
8 * particular file as subject to the "Classpath" exception as provided
9 * by Oracle in the LICENSE file that accompanied this code.
10 *
11 * This code is distributed in the hope that it will be useful, but WITHOUT
12 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
13 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
14 * version 2 for more details (a copy is included in the LICENSE file that
15 * accompanied this code).
16 *
17 * You should have received a copy of the GNU General Public License version
18 * 2 along with this work; if not, write to the Free Software Foundation,
19 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
20 *
21 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
22 * or visit www.oracle.com if you need additional information or have any
23 * questions.
24 */
25
26package com.sun.jdi;
27
28/**
29 * Thrown to indicate that the requested class has
30 * not yet been loaded through the appropriate class loader.
31 * <p>
32 * Due to the lazy class linking performed by many VMs, it is
33 * possible for a field or variable to be visible in a program
34 * before the associated class is loaded. Until the class is loaded
35 * all that is available is a signature string. If an attempt is made to
36 * set the value of such a field or variable from JDI, the appropriate
37 * type checking cannot be done because the destination class has not been
38 * loaded. The same is true for the element class of array elements.
39 * <p>
40 * It is not advisable to solve this problem by attempting a class load on
41 * the fly in this case. There are two problems in having the debugger load
42 * a class instead of waiting for it to load over the normal course
43 * of events.
44 * <ul>
45 * <li>There can be no guarantee that running the appropriate class
46 * loader won't cause a deadlock in loading the
47 * class. Class loaders can consist of arbitrary
48 * Java&trade; programming language code and the
49 * class loading methods are usually synchronized. Most of the work
50 * done by a debugger happens when threads are suspended. If another
51 * application thread is suspended within the same class loader,
52 *  a deadlock is very possible.
53 * <li>Changing the order in which classes are normally loaded may either mask
54 * or reveal bugs in the application. An unintrusive debugger should strive
55 * to leave unchanged the behavior of the application being debugged.
56 * </ul>
57 * To avoid these potential problems, this exception is thrown.
58 * <p>
59 * Note that this exception will be thrown until the class in question
60 * is visible to the class loader of enclosing class. (That is, the
61 * class loader of the enclosing class must be an <i>initiating</i> class
62 * loader for the class in question.)
63 * See
64 * <cite>The Java&trade; Virtual Machine Specification</cite>
65 * for more details.
66 *
67 * @author Gordon Hirsch
68 * @since  1.3
69 */
70public class ClassNotLoadedException extends Exception
71{
72    private static final long serialVersionUID = -6242978768444298722L;
73    private String className;
74
75    public ClassNotLoadedException(String className) {
76        super();
77        this.className = className;
78    }
79
80    public ClassNotLoadedException(String className, String message) {
81        super(message);
82        this.className = className;
83    }
84
85    public String className() {
86        return className;
87    }
88}
89