I'm a seasoned Java dev who needs to port a Java app for web use and I've been considering using Typescript to do this. For the time being, I'd like to keep the traditional Java style of packages being a hierarchy of folders and a single class per "leaf" file.
I've been looking at the Typescript docs and I see things like ../path/to/module. Are all includes relative like that? Is there some kind of base directory option where I can get something akin to import com.ancient.java.MyType;?
Also, is declaring a package com.ancient.java; something to be done in Typescript?
I've looked over the docs but I'm not finding them easy to read with all the talk about internal and external namespaces and exporting, etc.
Can someone boil this down to something that'll feel like Java for me to start out with? I'm sure I'll baby step into all the complex stuff later as needed. What does this look like in code?
Organizing your typescript classes into 1-class per file and an organized folder hierarchy is perfectly acceptable and even encouraged in typescript.
If using typescript 2.0 or above your paths do not need to be relative. You can use the baseUrl: property to specify where non-relative (i.e. no . or ..) paths are rooted. For example of you had:
tsconfig.json
src/
foo/
foo.ts
bar/
bar.ts
you could set "baseUrl": "./src" and then you could import 'foo/foo' and import 'bar/bar' without using relative path navigation.
I would discourage you from trying to declare packages/namespace/internal modules and the like in typescript. These types of things are mostly relics of the past, and not something I would venture to use in a new project.
What I would recommend is to stick to file-based modules, as this is the modern recommended approach for composing your application.
A file that has import or export statements is considered a "file module". Everything defined within it is private to the file and does not pollute the global namespace. Things that should be shared need to be exported and imported from other files.
For example you could write the MyType class in a file structure like this:
src/
com/
ancient/
my-type.ts
my-type.ts Would look like:
export class MyType{
constructor(){
console.log('Hello World');
}
}
and then you could import it in other files like:
import {MyType} from 'com/ancient/my-type'
You should not need to use the keywords namespace or module. These are mostly things that will only be found in type declaration files.
Related
I've got a common project and small projects which act such as connectors in the common project.
I want to create a common project such that when a new connector is developed I don’t have to modify code in the common project. Is it possible to dynamically load the structures in Go, only knowing the path (by putting this path in a file in common project and at runtime load that struct) of the struct and its folders?
connector1
connector1.go
/util
/domain
connectorN
connectorN.go
/domain
commonProject
main.go
config.ini
Structure config.ini
Conector
name = connector1
path = ..../connector1/connector1.go
Conector
name = connectorN
path = ..../connectorN/connectorN.go
I know that this is possible to do this in Java with code like this, but I am trying to do this in Go. Any ideas?
Class.forName(String)
or
ClassLoader.loadClass(String):
I can see two ways to achieve what you describe, but keep in mind, as #icza pointed out, that go produces static binaries, so you can't load external libraries dynamically.
You can, however:
use cgo to interface with C code, and load external libraries that
way.
use the net/rpc package to have several binaries communicate
with each other, and load those on demand.
In Java classes are loaded dynamically, on demand, when they are used/referred to.
Go produces statically linked native binaries without external dependencies, so you can't load new "types" or "functions" in a way you can do in Java with the Class.forName() (at least not code written in Go).
Today I started learning Java.
I saw that package automatic gets included in .Java file.
I was wondering if it always need to be included?
Consider specify a common package for all the types within a same project.
In Java is common to start a project with a specific package setting. A package creates a namespace to disambiguate the types that it includes, to play nicelly with other projects that may or may not be in the same classpath. Normally, the package is bound to a URL of the project.
Think of Java packages like C++ namespaces.
A huge project/product written in Java can depend on lots and lots of projects, each described in a different package.
Organizations like Apache have lots of projects, organized under a common package pattern: org.apache.<<name_of_the_project>>.
Consider starting your project with a package named: com.user3552670; or something like your personal site, so persons that will consume your project can relate to the creator.
Yes and no.
It's used to specify the package of the class, read more here.
You could create a class without a package, but your code will look bad..
They exists to avoid conflicts, example between your code and default java package.
If packages doesn't exists, you can't create a class named ArrayList because already exists in Java.
Some IDEs force the fact that, if your .java file is in com/a/b/c folder his package should be com/a/b/c (If i don't remember wrong, IntellIJ IDEA do that)
Yes and no.
It must be there, but the IDE takes care of it (I don't use Netbeans, but I'd bet that it can do it, too). When moving files between packages, it has to be updated, but again, the IDE does it all.
I found this question -> Import custom libraries in Java
And #Andy Thomas-Cramer said that the classes in "stdlib.jar" from "An introduction to programming in Java" have no packages, so they are in the default package.
Isn't this a bad practice? If you have something with no package the IDEs' auto-completion is quite slower. And also this means that we could not use any of the classes, in that jar, from classes with packages different then the default?
Can someone please tell me how we could deal with this?
EDIT:
I have 2 jars and I put them in Referenced libraries, they both have a bunch of classes in default package. When I create class in different package then the default - lets say org.myquestion I can't access the classes from the jars anymore.
This is something that really bugs me... First I can't create my own package and use anything from the jars. Second my IDE's (I use eclipse) auto-complete goes terrible - I guess it searches to meany classes at once... What I want to do is to put somehow the jars in some namespace... and to be able to access them like org.someones.libs.SomeClass
It certainly is bad practice to use the default package. A package groups classes and provides them with access protection (protected, package private) and functions as a unique namespace.
You can always use classes from every package, them being default or not, you can always mix.
Download the jar source code, And built it to jar by yourself and added the package name whatever your like.That's will solve your problem.
Importing classes inside JAR files that are in the default package
I ran into the exactly same problem as you did. The problem is the jar file "stdln.jar" has no named package, say, only with default package.
You cannot import a class from a default package, basically, since the import operation needs the package name:
import packagename.*;
So there are only two way to fix this problem:
the easier one: Do not create a package in your src folder and use default package two! Every class in stdln.jar would be imported to your src automatically.
Like this:
enter image description here
try to create your own jar file with a named package and copy all the class file into your newly-created jar file.
Since the stdln.jar is only used for education, so which you are gonna choose does not really matter. In real development, we never use default named package since it's not really a good practice, always leading to some confusing stuff.
Hope this would help you!
I have a massive, unfamiliar Java codebase that I need to use in one of my projects, and unfortunately it's one of those situations where almost nothing is documented, and the very few things that are documented are of the "setFoo(Foo foo) - sets the foo." variety. So the documentation generated with javadoc is not as helpful as it could be.
I'm more of a Lisp and Python guy myself, so my first thought was that I could learn a lot by interactively playing with some of the relevant classes. Enter the Jython REPL. The problem is that I can't figure out how to set the...the whatever (classpath?) to use them. Assume that I have two directories containing the subdirectories containing the .java files: ~/project/foo/src/ and ~/project/bar/src/.
Thanks in advance.
It sounds like you first need to compile those Java classes (you've referenced src directories in your question).
Once you have classes compiled, you can reference them via the classpath.
e.g.
>>> import sys
>>> sys.path.append(r'C:\temp\sample.jar')
>>> from org.my.package import MyClass
More info in this document
In Eclipse 3.5, say I have a package structure like this:
tom.package1
tom.package1.packageA
tom.package1.packageB
if I right click on an the tom.package1 package and go to Refactor->Rename, an option "Rename subpackages" appears as a checkbox. If I select it, and then rename tom.package1 to tom.red my package structure ends up like this:
tom.red
tom.red.packageA
tom.red.packageB
Yet I hear that Java's packages are not hierarchical. The Java Tutorials back that up (see the section on Apparent Hierarchies of Packages). It certainly seems like Eclipse is treating packages as hierarchical in this case.
I was curious why access specifiers couldn't allow/restrict access to "sub-packages" in a previous question because I KNEW I had seen "sub-packages" referenced somewhere before.
So are Eclipse's refactoring tools intentionally misleading impressionable young minds by furthering the "sub-package" myth? Or am I misinterpreting something here?
Eclipse can't possibly violate the JLS in this case, because it has nothing to do with compiling or running Java source or bytecode.
The refactoring tools behave as they do because that behaviour is useful to developers. The behaviour is useful to developers because, for many intents and purposes, we do treat packages as hierarchal (a.b.c has some kind of relationship with a.b, even if that relationship is not consistent from project to project). That doesn't mean Java treats them as hierarchal intrinsically.
One example where people treat packages as very hierarchal is in configuring a logging framework such as log4j. Again, it's not intrinsic to log4j, but that's how people use it in practice.
Java packages are not hierarchical in the sense that importing everything from package A does not import everything from package A.B.
However, Java packages do correspond directly to the directory structure on the file system, and directories are hierarchical. So Eclipse is doing the correct thing - it is renaming the directory, which automatically changes the name of the parent directory of the renamed directory's children (to state the very obvious).
even java itself has the concept of subpackage:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
java -ea[:<package name>"..." | :<class name> ]
Enable assertions. Assertions are disabled by default.
With no arguments, enableassertions or -ea enables assertions. With one argument ending in "...", the switch enables assertions in the specified package and any subpackages. If the argument is simply "...", the switch enables assertions in the unnamed package in the current working directory. With one argument not ending in "...", the switch enables assertions in the specified class.
If a single command line contains multiple instances of these switches, they are processed in order before loading any classes. So, for example, to run a program with assertions enabled only in package com.wombat.fruitbat (and any subpackages), the following command could be used:
java -ea:com.wombat.fruitbat... <Main Class>
Java's packages are not hierarchical, but Eclipse stores packages on your system's file structure.
tom.package1.packageA is represented on a Windows file system as tom/package1/packageA.
When you ask Eclipse to refactor a package name, you're asking Eclipse to change the name of the file system directory structure.
You can have packages in Eclipse like:
tom.package1.packageA
tom.package2.packageB
tom.package3.packageC
You'll just have different 2nd level file system directories.