You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the class file does not contain any debugging information (if it was compiled with -g:none, or if it was stripped later), the normalization changes because BCEL replaces the source file name with <Unknown>. I think this is not desirable at all. javac code generation might change in corner cases depending on whether debugging information is generated or not (I haven't checked this), but this direct dependency on the debugging information is unnecessary.
The text was updated successfully, but these errors were encountered:
fweimer
changed the title
Normalization changes when class is compiled with -g:none
Normalization changes when class is compiled with -g:none
Aug 4, 2014
@abn, not yet. Until the next great hashing bump, is probably best to create an artificial value for the SourceFile attribute if it is missing, derived from the class name, i.e. for a class named org/example/Toplevel$Nested, the SourceFile attribute value would be "Toplevel.java". This will be the correct file name almost all the time, except when a single .java file defines multiple top-level classes.
If the class file does not contain any debugging information (if it was compiled with
-g:none
, or if it was stripped later), the normalization changes because BCEL replaces the source file name with<Unknown>
. I think this is not desirable at all.javac
code generation might change in corner cases depending on whether debugging information is generated or not (I haven't checked this), but this direct dependency on the debugging information is unnecessary.The text was updated successfully, but these errors were encountered: