Why is my plsql code missing in the datadictionary in Oracle 12c?

Question

Can anyone please shed some light on what might be wrong with my 12c laptop-installation to cause the following problem?

In short: All the code I create in my schema is there and can be executed, but can not be viewed or edited in any IDE, or via dba_source.

First of all: I'm not a DBA, nor will I ever be, although I have some DBA-understanding.
I'm an Oracle- developer. So I could have done all sorts of stupid things while installing 12c.

I have installed Oracle Database 12c Enterprise Edition 12.1.0.1.0 64bit on my laptop.
1 Container database.
1 Plugable database.

When I log in to my plugable database in any IDE (pl/sql developer. sql developer, ...) all my objects are visible in the 'browser' of the IDE of choice.
However, when I try to open (view the source of) a plsql-based object like packages / procedures / functions / types, I can not.
An exception is triggers. They CAN be viewed and edited.
plsql developer (10.0.5.1710) tells me (for example): "/* Source of PACKAGE ERO$UTL is not available */"
sql developer (4.0.3.16) just shows me: "create or replace ".

The objects can however be used normally.

At first I thought "plsql developer just isn't ready for 12c yet"
But then I saw sqldev does the same, so....

I checked the database/datadictionary itself.

I create a simple procedure:

ERO@EVROCS>CREATE OR REPLACE PROCEDURE hi_there  
  2  AS  
  3  BEGIN  
  4    dbms_output.put_line ('Hello World');  
  5  END;  
  6  /  

Procedure created.  

So far so good.
Does it exist, and work?

ERO@EVROCS>exec hi_there  
Hello World  

PL/SQL procedure successfully completed.  

Apparently it does.

Now, does user_objects know of its existence?

ERO@EVROCS>SELECT object_name||' - '||object_type   object  
  2  FROM   user_objects  
  3  WHERE  object_name = 'HI_THERE';  

OBJECT  
-----------------------------------------------------------  

HI_THERE - PROCEDURE  

1 row selected.  

Yep! Great!
Now, show me its source

ERO@EVROCS>SELECT *  
  2  FROM   user_source  
  3  WHERE  name = 'HI_THERE'  
  4  ;  

no rows selected  

Excuse me? Did I miss-spell the name?

ERO@EVROCS>SELECT *  
  2  FROM   user_source  
  3  ;  

no rows selected  

No.

dba_source doesn't show ANY of my source either:

ERO@EVROCS>SELECT DISTINCT  
  2         owner  
  3  FROM   dba_source  
  4  order by owner  
  5  ;  

OWNER  
-------------------------------  

APEX_040200  
CTXSYS  
DBSNMP  
DVF  
DVSYS  
FLOWS_FILES  
GSMADMIN_INTERNAL  
LBACSYS  
MDSYS  
OLAPSYS  
ORACLE_OCM  
ORDPLUGINS  
ORDSYS  
OUTLN  
SYS  
SYSTEM  
WMSYS  
XDB  

18 rows selected.  

I'm lost

---

New information:

I don't think it's related to the problem, but I should have mentioned it anyway:
It's running on a Windows laptop.
Windows 8.1 to be more precise.

@Lalit
You seem to have a point here.
dbms_metadata correctly produces the code of all my objects.

ERO@EVROCS>SELECT dbms_metadata.get_ddl ('PROCEDURE'  
  2                               ,'HI_THERE'  
  3                               ,'ERO'  
  4                               )         statement  
  5  FROM dual;  

STATEMENT  
---------------------------------------------------------------  
  CREATE OR REPLACE EDITIONABLE PROCEDURE "ERO"."HI_THERE"  
AS  
BEGIN  
  dbms_output.put_line ('Hello World');  
END;  

1 row selected.  

1But somehow the datadictionary views do not see my code.

@all
Investigating the views, it gets weirder all the time.
Summary of the below: dba_source does NOT know of the existence of my code, but the sourcecode that makes up dba_source DOES!!
Larry moves in mysterious ways!

The source of dba_source is:

CREATE OR REPLACE  
VIEW dba_source  
AS  
SELECT OWNER, NAME, TYPE, LINE, TEXT, ORIGIN_CON_ID  
FROM   INT$DBA_SOURCE  
;  

pretty straight forward: just select every row from view INT$DBA_SOURCE.
So, if anything is wrong with the views, it must be in this one (or deeper).

Let's query that view, logged in as SYSTEM AS SYSDBA on the PDB (because obviously my ERO account can't query these kind of views directly)
I know, I know, I should never log in as such, but, the database started ;-) So, I guess this is never

SYS@EVROCS>SELECT s.text  
  2  FROM   INT$DBA_SOURCE  s  
  3  WHERE  s.name  = 'HI_THERE'  
  4  ORDER BY s.line  
  5  ;  

no rows selected  

Ok, as expected. Because this basically is the same thing as dba_source.
What does the INT$DBA_SOURCE view do?

CREATE OR REPLACE  
VIEW int$dba_source  
     (owner  
     ,name  
     ,type  
     ,type#  
     ,line  
     ,text  
     ,sharing  
     ,origin_con_id  
     )  
AS  
SELECT u.name  
,      o.name  
,      DECODE(o.type#  
             , 7, 'PROCEDURE'  
             , 8, 'FUNCTION'  
             , 9, 'PACKAGE'  
             ,11, 'PACKAGE BODY'  
             ,12, 'TRIGGER'  
             ,13, 'TYPE'  
             ,14, 'TYPE BODY'  
             ,22, 'LIBRARY'  
             ,87, 'ASSEMBLY'  
             ,'UNDEFINED'  
             )  
,      o.type#  
,      s.line  
,      s.source  
,      DECODE(bitand(o.flags, 196608)  
             ,65536 , 1  
             ,131072, 1  
             ,0  
             )  
,      TO_NUMBER(sys_context('USERENV', 'CON_ID'))  
FROM   sys."_CURRENT_EDITION_OBJ"     o  
,      sys.source$                    s  
,      sys.user$                      u  
WHERE  o.obj#               = s.obj#  
  AND  o.owner#             = u.user#  
  AND  (   o.type#         IN (7, 8, 9, 11, 12, 14, 22)  
        OR (    o.type#     = 13  
            AND o.subname  IS NULL  
           )  
       )  
UNION ALL  
SELECT u.name  
,      o.name  
,      'JAVA SOURCE'  
,      o.type#  
,      s.joxftlno  
,      s.joxftsrc  
,      DECODE(bitand(o.flags, 196608)  
             ,65536 , 1  
             ,131072, 1  
             ,0  
             )  
,      TO_NUMBER(sys_context('USERENV', 'CON_ID'))  
FROM   sys."_CURRENT_EDITION_OBJ"     o  
,      x$joxscd                       s  
,      sys.user$                      u  
WHERE  o.obj#       = s.joxftobn  
  AND  o.owner#     = u.user#  
  AND  o.type#      = 28  
;  

Ok!
I get this. So basically a join from users to objects and from there to source.
And then the object needs to be of some type.
Maybe the 'type' of my objects is wrong?
First question what is my user#

SYS@EVROCS>SELECT u.user#  
  2  FROM   sys.user$  u  
  3  WHERE  u.name = 'ERO'  
  4  ;  

          USER#  
---------------  
            111  

1 row selected.  

I've got a usernumber, therefore I am...
Now does the object exist, and if so, what is its obj#, type and subname (stuff in the where-clause)?

SYS@EVROCS>SELECT o.obj#  
  2  ,      o.name  
  3  ,      o.type#  
  4  ,      NVL(o.subname,'<<NULL>>')  subname  
  5  FROM   sys."_CURRENT_EDITION_OBJ" o  
  6  WHERE  o.owner# = 111  
  7    AND  o.name   = 'HI_THERE'  
  8  ;  

  OBJ# NAME      TYPE# SUBNAME  
------ --------- ----- ---------  
 97193 HI_THERE      7 <<NULL>>  

1 row selected.  

Yes, it exists.
And the type/subname combination is one that is excepted by the where-clause.
So the problem must be in sys.source$.
Obviously that one does not deliver the source....

SYS@EVROCS>SELECT s.source  
  2  FROM   sys.source$   s  
  3  WHERE  s.obj#  = 97193  
  4  ORDER BY s.line  
  5  ;  

SOURCE  
---------------------------------------------  
PROCEDURE hi_there  
AS  
BEGIN  
  dbms_output.put_line ('Hello World');  
END;  

5 rows selected.  

What????
The source is there.
I've just checked every single part of the view-source. And it checks out OK.
So the select statement of the view should produce the source of my procedure.
But if it does, selecting from the view should too.

So, although I know it can't give me my sourcecode (because the view doen't), I'll check what happens if I select from the select statement that is the source of the view

SYS@EVROCS>SELECT SOURCE  
  2  FROM   (  
  3  SELECT u.name       u_name  
  4  ,      o.name       o_name  
  5  ,      DECODE(o.type#  
  6               , 7, 'PROCEDURE'  
  7               , 8, 'FUNCTION'  
  8               , 9, 'PACKAGE'  
  9               ,11, 'PACKAGE BODY'  
 10               ,12, 'TRIGGER'  
 11               ,13, 'TYPE'  
 12               ,14, 'TYPE BODY'  
 13               ,22, 'LIBRARY'  
 14               ,87, 'ASSEMBLY'  
 15               ,'UNDEFINED'  
 16               )  
 17  ,      o.type#  
 18  ,      s.line  
 19  ,      s.source  
 20  ,      DECODE(bitand(o.flags, 196608)  
 21               ,65536 , 1  
 22               ,131072, 1  
 23               ,0  
 24               )  
 25  ,      TO_NUMBER(sys_context('USERENV', 'CON_ID'))    u_env  
 26  FROM   sys."_CURRENT_EDITION_OBJ"     o  
 27  ,      sys.source$                    s  
 28  ,      sys.user$                      u  
 29  WHERE  o.obj#               = s.obj#  
 30    AND  o.owner#             = u.user#  
 31    AND  (   o.type#         IN (7, 8, 9, 11, 12, 14, 22)  
 32          OR (    o.type#     = 13  
 33              AND o.subname  IS NULL  
 34             )  
 35         )  
 36  UNION ALL  
 37  SELECT u.name  
 38  ,      o.name  
 39  ,      'JAVA SOURCE'  
 40  ,      o.type#  
 41  ,      s.joxftlno  
 42  ,      s.joxftsrc  
 43  ,      DECODE(bitand(o.flags, 196608)  
 44               ,65536 , 1  
 45               ,131072, 1  
 46               ,0  
 47               )  
 48  ,      TO_NUMBER(sys_context('USERENV', 'CON_ID'))  
 49  FROM   sys."_CURRENT_EDITION_OBJ"     o  
 50  ,      x$joxscd                       s  
 51  ,      sys.user$                      u  
 52  WHERE  o.obj#       = s.joxftobn  
 53    AND  o.owner#     = u.user#  
 54    AND  o.type#      = 28  
 55  )  
 56  WHERE o_name = 'HI_THERE'  
 57  ORDER BY line  
 58  ;  

SOURCE  
----------------------------------------------------------------------  

PROCEDURE hi_there  
AS  
BEGIN  
  dbms_output.put_line ('Hello World');  
END;  

5 rows selected.  

There is something rotten in the state of The Netherlands :-(

Answer 1

Last week I was fortunate enough to have the opportunity to speak with Tom Kyte. And since he is the Tom from AskTom, I did just that: I asked him about this problem. I explained what I wrote above and asked him: "what did I do wrong?"

And his answer was plain and simple: "Probably nothing". He explained that 12.1.0.1 had a couple of bugs in the datadictionary views because suddenly they had to get a part of their data from the container database and a part from the plugged-in database. So, it Tom concluded I probably ran into one of hose bugs.

Still, since nobody could confirm this behaviour, and since I can not imagine being the only one ever using a 12.1.0.1 database, I feel that there must be something I did that triggered this bug to be noticeable.

Anyway, now that I am assured that the problem probably lies within the product, I will stop investigating it further and upgrade to 12.1.0.2. Now, if the upgrade makes the problem disappear, I will be confident that it will not reappear a week later after me repeating my 12.1.0.1 stupidity.

Edit 25/02:

Last weekend deinstalled 12.1.0.1 and installed 12.1.0.2 following the exact same steps I used for 12.1.0.1. Problem is gone. So it looks like Tom was right (once again).