I try to learn about RPackageTags:
It seems RPackageTags are just something like sub-packages?
Unlike let’s say tags in OS X, one item (here one class) cannot have more than one tag?
A tag is always specific to an RPackage? The tags in Package1-Tag1 and Package2-Tag1 are not the same, i.e. are two different instances of RPackageTag?
There is the possibilty that Package1-Tag1 is just an RPackage and also the possibility that Package1-Tag1 is the combination of RPackage Package1 and RPackageTag Tag1?
Is that right? What is the idea behind the introduction of RPackageTags?
How are RPackageTags related to Monticello packages?
Some answers:
Yes, they are like subpackages
For now, yes. This is because we needed to keep some compatibility between RPackages and System Categories and we decided (for now), that the scheme would be: RPackage+Tag = SystemCategory. This will change in the future, by removing system categories and allowing tags to be like OSX tags.
For now, yes... see point (2) :)
No, you cannot. This is because of organisation issues derived also from the attach RPackage+Tag to a SystemCategory: If you have a package A-B and a Package A with tag B, both would share the SystemCategory A-B... which is seriously bad for the organization of the system.
Of course, as you can see, the real problem here is to have an ancient way of organisation still in system. This will change, in Pharo4 or (most probably) in Pharo5, and for now we need to live with this convenience solution.
Ring package structure was adopted in Pharo 3. Approximately what was known to be an MC package became RPachage, pure-smalltalk categories disappeared and were replaced by RPackageTags. You can think about it as a way to create categorise classes inside your MC package. I don't know what Pharo board will decide in future, but for now you can have only 1 tag per class.
Related
I'm trying to update a software system to JDK-11 using modules, and everything was going just fine right up until I slammed head-on into the aforementioned issue.
I have a legacy signed JAR that I need to incorporate for interaction with legacy systems. There's no way to update the JAR and no way to get a new version. The JAR must be signed in order to be usable (the whole "trusted code" deal and whatnot). The problem is that the JAR contains classes in the unnamed (root) package. Yeah. Stupid. Bad practice. Blablabla. It's still there, and I still need to use it.
I've not found any documentation or answers anywhere that would remotely suggest that what I need is possible. In fact, the opposite is true: everyone is adamant that in the "new"(ish) module system, no class may reside in the unnamed package.
Needless to say I'm unable to both modify the contents of the JAR, or get at the sources to render a new one - that's without even considering the issue of the signature...
That said: I refuse to believe the folks at Oracle would leave such a glaring oversight with regards to legacy code. As we all know, a lot of the time we have no choice but to use it for legitimate reasons, and we can't do anything to fix/update/refactor/etc... I would have hoped there was a mechanism added to the module system to support this, albeit for extreme cases only, etc...etc...
Disclaimer: I do fully understand why this isn't meant to be supported. What I'm having a hard time with is the lack of a workaround...
Thanks!
I've already tried:
creating a facade module that transitively adds the offending module (obviously no dice, same problem)
unpacking-and-repacking the module while temporarily disabling signature validation in a test env (fails because the class is apparently referenced within many other, properly-organized classes)
finding an updated module (no luck here, either)
beheading a chicken and roasting it over a pentagram while invoking the aid of ancient pagan gods (tasty, but didn't fix it)
curling up in a ball under my desk and weeping until execution succeeds (that's where I'm typing this from)...
I am writing code on top an established Enterprise application. I see that the application has 4 modules as shown below.
-Srk
-SrkEJB
-SrkUtils
-SrkWeb
I have gone through the code and I see that some modules are tiny for example: SrkEJB module has got just 2 EJBS. I don't see any reason to create a separate module for 2 Java classes.
I have simplified the above approach and is shown below.
Srk
- com.srk.utils
- com.srk.ejb
- com.srk.web
How is the first module based architecture different from the second from an architectural stand point? Generally, which is the followed mostly, when creating an application from scratch? If not, What could be the trade-offs of each of the approaches? I believe this is a not specific to Java alone.
I don't see any reason to create a separate module for 2 Java classes.
I believe this is an invalid chain of reasoning. You should create a separate module whenever you discover classes, related to the same subject. The number of classes is irrelevant here. You may have a module containing only one class, if the purpose of that class is really different from others.
The name of the package / module should clearly speak its purpose. So, module name "Srk" seems bad to me (I suppose "srk" is some kind of abbreviated company name and is not related to architecture).
The same may be related to "utils", which sounds very generic to me. It is impossible to tell, what are those utils about.
A few years back i worked in a company where i could press CTRL+T and a TODO-comment was generated - say my ID to be identified by other developers was xy45 then the generated comment was:
//TODO (xy45):
Is something available from within Intellij 14 Ultimate or did they write their own plugin for it?
What i tried: Webreserach, Jetbrais documentations - it looks like its not possible out of the box (i however ask before i write a plugin for it) or masked by the various search results regarding the TODO-view (due to bad research skills of mine).
There is no built-in feature in IntelliJ IDEA to generate such comments, so it looks like they did write their own plugin.
Found something that works quite similar but is not boundable to a shortcut:
File -> Settings -> Live Templates
I guess the picture says enoth to allow customization (consult the Jetbrains documentation for more possibilities). E.g. browse to the Live Template section within the settings, add a new Live Template (small green cross, upper right corner in the above picture) and set the context where this Live Template is applicable.
Note: Once you defined the Live Template to be applicable within Java (...Change in the above image where the red exclamation marks are shown) context you can just type "t", "todo" and hit CTRL+Space (or the shortcut you defined for code completion).
I suggest to reconsider using that practice at all. Generally you should not include redundant information which is easily and more reliably accessible through your Version Control System (easily available in Idea directly in editor using Annotate feature). It is similiar to not using javadoc tag #author as the information provided with it is often outdated inaccurate and redundant. Additionaly, I don´t think author of TODO is that much valuable information. Person who will solve the issue will often be completly different person and the TODO should be well documented and descriptive anyway. When you find your own old TODO, which is poorly documented, you often don't remember all the required information even if you were the author.
However, instead of adding author's name, a good practice is to create a task in you issue management system and add identifier of this task to the description of the todo. This way you have all your todos in evidence at one place, you can add additional information to the task, track progress, assign it etc. My experience is that if you don´t use this, todos tend to stay in the code forever and after some time no one remembers clearly the details of the problem. Additionaly, author mentioned in the todo is often already gone working for a different company.
Annotated TODO with issue ID
I have a patch for vanila linux kernel which includes new files as well as changes in original Kernel SourceTree files too.
I want to make this patch a Loadable Kernel Module so that I can avoid any rebuild of basic kernel.
As this patch has changes in header files as well as .c and data file of org kernel source, I have a doubt whether this can be made a Kernel Module?
Please ask for any more details you want to clarify the issue.
Thanks,
Sapan
The simple answer is no.
A more nuanced answer: Yes, it's theoretically possible to do something like what you're envisioning. However, it's enormously complex -- every detail has got to be exactly right -- and not something you could hope to do in an ad-hoc manner. For example, every data structure that increases in size might cause huge areas of memory to need to be reallocated and relocated, and every pointer pointing to one of those pieces of data would then need to be adjusted, and there is a potential cascade of further dependent adjustments. There's simply no way to track all those details.
But see https://www.ksplice.com/, which actually patches a kernel at runtime. I don't know many details about ksplice, but I'm fairly certain it's only possible to do this with very tight constraints on what exactly changes due to the concerns I outlined above, among others.
I mean, can I use the com.sun.org.apache (all subpackages) classes as I use they from org.apache (in any Apache lib)?
Will the OpenJDK maintain this package up to date with apache updates?
And the JDK7 will maintain this package?
Where can I find information about that?
It is a very bad idea to use it. Once upon a time, Sun took a copy of Xerces, chock full of bugs. They made some changes. Perhaps they subtracted some bugs. We know that there are many very serious bugs that they did not subtract.
And they renamed it to com.sun.... for one reason: to tell you not to use it. At any time, in any point release, in any patch, they can change those classes incompatibly or remove them.
Further, these classes may not be in IBM's copy of the JRE, or Apple's, or (haha) Microsoft's, or JRocket.
If you want Xerces, use Xerces. To find information about this, read the Xerces-j mailing list archive for many stern warnings from the Xerces developers about the version forked by Sun.
The fact that the classes are formally 'public' means nothing except that Sun needed to be able to new them from some other package.
Err I wouldn't, just based on the fact that they're internal classes and there is a risk of them changing over time. Use the org.apache classes instead.
No idea about the intentions with keeping them up to date, maybe try posting a message on the openjdk forum:
http://mail.openjdk.java.net/mailman/listinfo
My understanding is that this is a fork of the apache code. At one point they were the same, but no more. So you can't count on the same bug fixes being present in both versions.
If documentation for this package says that it is public, then it's OK to use.
Otherwise they can pool a floor underneath you when they decide not to support it in the future.
Usually, you should not rely on anything other than java and javax in JDK.