Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

Manifest Specification

 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For a long time, I've thought that the only way to specify the main class attribute in a jar manifest is like this:
Main-Class: mypackage.MyMainClass
However, someone suggested that it can also be
Main-Class: mypackage/MyMainClass
And it turned out that both versions work. I looked at Sun's Jar File Specification, but couldn't find and references as to how exactly the main class attribute should be delimited. The only thing that it says is "Main-Class :
The value of this attribute defines the relative path of the main application class which the launcher will load at startup time. The value must not have the .class extension appended to the class name.
".
Does anyone know if there is a difference between the two different way of delimiting the "Main-Class" attribute?
Thanks,
Eugene.
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Eugene,
i guess both works fine as we use the jar file.
1. the package access via "."
this works as java class loader parses the fully qualified class name and "resolves" all "." and replaces them with "/".
then the class loader tries to find that directory path in the CLASSPATH and if it finds it then loades the class from directory : packagename. so essentially, if my package is,
"earth.myhome" then after "resolving" it will be,
earth/myhome and if the class is "myTV" then it will look for , earth/myhome/myTV.class in the Jar...

now, in Jar file (that follows the standard zip format if i'm not mistaken), we have the directory based storage , right? so, now when the class loader encounters the packaged class, it "resolves" the packagename for the class and then looks for that package directory in the Jar. it works if the directory is Jarred in there.

2. for the "/" operator in Main-Class,
here also it works due to the "resolve" mechanism as the "."s gets converted into "/" ...
so i guess both works...
regards
maulin
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi
sorry..i miswrote in 2nd option explanation..
it works in 2nd case ("/") as ultimately everything is resolved via "/" (as u notice in 1st option, "." are converted to "/")...
so its like,
1st option is a extension to the 2nd option where we are also allowed to put "." and follow the standard java package convention instead of using "/" ...
regards
maulin
 
Cob is sand, clay and sometimes straw. This tiny ad is made of cob:
Garden Master Course kickstarter
https://coderanch.com/t/754577/Garden-Master-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic